[I quote C++03's material about standard headers including each other: what is allowed and what is required.]
On 2017-Jul-31, at 1:31 PM, Mark Millard <markmi at dsl-only.net> wrote: > On 2017-Jul-31, at 12:42 PM, Tijl Coosemans <tijl at FreeBSD.org> wrote: > >> On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard <mar...@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. > > [If you find something in the standard that I've missed in my > searches, please let me know.] > > [It is possible to write some C++ code without defining any > macros. Macros are a bigger issue because they do not > have/respect scope rules that limit where conflicts can > occur.] > > No. Names local to classes (for example) that are from the > standard library implementation do not constraint non-macro > names used outside those scopes (for example). To my surprise > those names are not required to be from the reserved naming > space. > > But the standards do indicate that macro naming must avoid > conflicts with such names, including those that are private > to the implementation. > > I wrote for C++03 (and before), in part quoting the standard: > >> "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.) > > > And for more modern contexts (quoting C++11's wording): > >> "A translation unit that include a standard library >> header shall not #define or #undef names declared >> in any standard library header." > > These make it a very good idea to avoid generic macro > names that are fairly likely to be fairly common. May be > here: > > #define sqobject_type(obj) ((obj)._type) > > This would be far less likely to end up with conflicts > (until the standard gets something called a "sqobject" > involved anyway). > > > You certainly can submit a bugzilla report at: > > https://bugs.llvm.org/enter_bug.cgi?product=libc%2B%2B > > since FreeBSD gets libc++ from there (upstream). Complaints > about quality issues that do not mean non-conformance are > a valid thing to report so even if they agree with me on > that point the submittal would be valid. llvm folks are just > less likely to act on such issues. Here is the core of what C++03 has to say about standard headers including each other. I'd not managed to quote it before. (I've been trying to avoid a "just my say so" status in what I've written.) ISO/IEC 14882:2003's 17.4 is "Library-wide requirements". 17.4.4.1 "Headers" (so: standard headers) says in part: "A C++ header may include other C++ headers." That text has a foot note 170 that says: "C++ headers must include a C++ header that contains any needed definition (3.2)." There is also a special rule for the .h form of C headers: "Header inclusion is limited as follows: -- The C headers ( .h form, described in Annex D, D.5) shall include only their corresponding C++ header, as described above (17.4.1.2)." Of course the C++ header (non-.h form) then can do more includes. Side note: It had been a long time since I'd been through this stuff --and I'd not been tracking recent C++ standard versions in much detail. It has been good for me to go through this subject area. It also has been good to see that some of the mis-matched material in earlier versions has been updated to cover things better. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
