On 29 Jul 2017, at 01:59, Tijl Coosemans <t...@freebsd.org> wrote:
>
> On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric <d...@freebsd.org> wrote:
>> On 28 Jul 2017, at 13:55, Tijl Coosemans <t...@freebsd.org> wrote:
>>>
>>> On Thu, 27 Jul 2017 21:42:01 +0000 pkg-fall...@freebsd.org wrote:
>> ...
>>>> In file included from squirrel/squirrel/sqvm.cc:5:
>>>> In file included from /usr/include/c++/v1/math.h:310:
>>>> /usr/include/c++/v1/limits:149:85: error: expected expression
>>>> _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT
>>>> {return type();}
>>>>
>>>> ^
>>>> squirrel/squirrel/sqobject.h:131:24: note: expanded from macro 'type'
>>>> #define type(obj) ((obj)._type)
>>>> ^
>>>
>>> Simutrans code defines 'type' as a macro. Shouldn't libc++ headers use
>>> _type or __type or something?
>>
>> No, the member name 'type' is used in many classes in the C++ standard
>> library, for example all the traits in <type_traits>. Programs should
>> not attempt to redefine this, at least not as a macro.
>>
>> Note that this also doesn't work with libstdc++, e.g.:
>>
>> $ cat boom.cpp
>> #define type "nope, this will not work"
>> #include <type_traits>
>>
>> and then:
>>
>> $ g++ -c boom.cpp
>> boom.cpp:1:14: error: expected unqualified-id before string constant
>> #define type "nope, this will not work"
>> ^
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>> ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>> ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>> ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>> ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected unqualified-id before string constant
>> #define type "nope, this will not work"
>> ^
>> In file included from boom.cpp:3:0:
>> /usr/local/lib/gcc6/include/c++/type_traits:212:60: error: template argument
>> 1 is invalid
>> : public __is_void_helper<typename remove_cv<_Tp>::type>::type
>> ^
>> /usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected '{'
>> before '::' token
>> : public __is_void_helper<typename remove_cv<_Tp>::type>::type
>> ^~
>> [...and lots more errors like this...]
>
> The code does not include <type_traits> or any of that C++11 stuff. It
> includes <math.h>. This works with libstdc++ because it doesn't have
> <math.h>, but it would also work when <cmath> was included, because
> libstdc++ uses __type everywhere (and __enable_if and __is_arithmetic,
> etc. where libc++ headers use enable_if and is_arithmetic). The
> libstdc++ way makes more sense. You cannot expect C++98 code to know
> about reserved identifiers in C++11 or C++11 code to know about reserved
> identifiers in later standards.The usage of "type" as a name has been in libc++ since it was first imported upstream about 7 years ago, and the failure you showed is the first instance of such a name clash I have ever heard of. Therefore, I don't think it is too much trouble to change one older program to use a slightly different define. -Dimitry
signature.asc
Description: Message signed with OpenPGP
