|Subject:||Re: [Bug-apl] compile error location of malloc.h|
|Date:||Tue, 30 Aug 2016 20:35:52 -0500|
in principle you are right. However I have avoided to use the C++ counterparts of the standard C include files
so far because some of them produce compile errors like this:
0x_warning.h:32:2: error: #error This file requires compiler and library support
for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11
or -std=gnu++11 compiler options.
and I was afraid that this would negatively impact the portability of GNU APL without giving an advantage.
On 08/29/2016 11:21 PM, Xiao-Yong Jin wrote:
There is nothing wrong using <stdlib.h>, but in C++ the standard way is #include<cstdlib> and call std::malloc and its friends.On Aug 29, 2016, at 4:43 AM, Juergen Sauermann <address@hidden
de>wrote: Hi, thanks, fixed in SVN 794. I went for <stdlib.h> because that is what the malloc manpage says. Currently <stdlib.h> is aleady #included by Common.hh but that may change. Therefore I believe that it is cleaner to #include it again. /// Jürgen On 08/29/2016 07:21 AM, Elias Mårtenson wrote:They are, but if they are not found in the local directory, they are also searched for in the system directories. That said, in this case using the angle brackets is the correct thing to use. On 29 August 2016 at 13:08, Christian Robert <address@hidden> wrote: that should read: #include <malloc.h> or better #include <stdlib.h> things in double quotes are searched in local directory by default and not in system. Xtian. On 2016-08-28 23:42, Xiao-Yong Jin wrote: LApack.cc:21:20: fatal error: malloc.h: No such file or directory #include "malloc.h" ^ compilation terminated. Under OS X, it’s in /usr/include/malloc/malloc.h Is it actually needed? The code compiles fine without the #include. Best, Xiao-Yong
|[Prev in Thread]||Current Thread||[Next in Thread]|