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>