Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Jul 2017 21:42:51 +0200
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        toolchain@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org>
Subject:   Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build
Message-ID:  <20170731214251.0a5de99b@kalimero.tijl.coosemans.org>
In-Reply-To: <C6F2D60F-5FEC-4858-99B8-E3B04EB467A6@dsl-only.net>
References:  <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <F47E0976-759A-45A0-8421-8FD4402A9980@FreeBSD.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> <D780E949-FB27-4A84-8E10-75D1E7A8EA06@dsl-only.net> <20170729212706.33841c4c@kalimero.tijl.coosemans.org> <D4345C7E-29E1-42CC-B970-82EF6439237A@dsl-only.net> <20170729230641.6cecd29d@kalimero.tijl.coosemans.org> <3E4B30BB-A9E5-480E-835D-DA6797FC230C@dsl-only.net> <C6F2D60F-5FEC-4858-99B8-E3B04EB467A6@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard <markmi@dsl-only.net> wrote:
> On 2017-Jul-29, at 3:24 PM, Mark Millard <markmi at dsl-only.net> wrote:
>> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans <tijl at FreeBSD.org> wrote:
>>> - Adding -std=c++98 still fails to compile with the same errors.
>>> 
>>> - The compiler default is C++98:
>>> % c++ -x c++ -E -dM /dev/null | grep __cplusplus
>>> #define __cplusplus 199711L
>>> 
>>> - A quick look at the libc++ headers makes it immediately obvious they
>>> expose and use C++11 features in C++98 mode.
>>> 
>>> And of course these were the very first things I checked before writing
>>> my first email.  
>> 
>> Good to know.
>> 
>> Under C++03 (and before) the basic requirements for macro names
>> are different (and matching what you are attempting): 17.4.3.1.1
>> Macro Names says:
>> 
>> "A translation unit that includes a header shall not contain any macros
>> that define names declared or defined in that header."
>> 
>> This greatly narrows the range of potential conflicts.
>> 
>> (But my understanding is that the rule was changed in part
>> because headers implicitly including content from other
>> standard headers is classified as okay in the early standards
>> as well and so overall the early standards were not fully
>> consistent, given how macros are specified to operate.)
>> 
>> There is the issue that even for C++03 and before:
>> 
>> "Clauses 18 through 27 do not specify the representation of classes
>> . . . An implementation may define static or non-static class members,
>> or both, as needed to implement the semantics of the member functions
>> specified in clauses 18 through 27."
>> 
>> So far as I know (unlike C) C++ makes no requirements that imply
>> the "extra" names involved in such must not be valid names in
>> programs, although it allows for such. (Such as using __ prefixes
>> or _<upper-case-letter> prefixes. Or for the global namespace: _
>> prefixes. These are reserved but not required to be used by the
>> implementation from what I can tell.) So as far as I know
>> such "pollution" is an implementation quality issue but not a
>> standards conformance issue so long as the naming does not
>> mess up programs' use of the required naming from the standard.
>> 
>> So what you report about "type" being in use as an identifier
>> in the library of itself looks greatly unfortunate to me but also
>> does not seem to be a violation of the C++98, C++03, or other
>> standard versions. (Drat.)
>> 
>> I've also not found anything indicating that extra declarations
>> and definitions (such as from C++11 for compiles targeting C++98
>> or C++03) would be a violation of a standard, such as C++98 or
>> C++03. (At least for any addition that does not prevent programs'
>> use of required aspects of the library.)
>> 
>> This was a surprise to me. But so far I've not found anything to
>> point to for a "this is wrong by the rules of the standard"
>> submittal against libc++. That makes it less likely to change in
>> the future.  
> 
> I should have noted two contexts that do explicitly specify that
> "names reserved to the implementation" be used:
> 
> 17.4.4.7 Derived classes says both:
> 
> "It is unspecified whether a class in the C++ Standard Library it
> itself derived from other classes (with names reserved to the
> implementation)."
> 
> "It is unspecified whether a class described in the C++ Standard
> Library as derived from another class is derived from that class
> directly, or through other classes (with names reserved to the
> implementation) that are derived from the specified base class."
> 
> These quotes are from ISO/EIC 14882:2003. More modern ones
> that I've looked at also include a 3rd context:
> 
> "Implementations are permitted to provide addition predefined
> variables with names that are reserve to the implementation
> (5.10)."
> 
> Otherwise having extra names is not restricted to using
> "names reserved to the implementation", even in C++98
> and C++03 as far as I can tell.
> 
> (I do not have a copy of the C++98 standard with me so I'm using
> C++03's instead.)

You are arguing that all names are reserved to the implementation,
meaning no names are available to programmers and it is impossible
to write C++ code.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170731214251.0a5de99b>