> Over the last few months I implemented 'compile feature' support > in the > CMake buildsystem tool. > > This is somewhat related to the work of SG10, in that the macros > recommended here can be used by this CMake functionality in the > future. > These use cases may not be obvious, so I thought I'd list them > here for > information and feedback and relate some of the experience.
This is very interesting; thanks for sharing it. > It appears that if following SD6, code such as > > static_assert(__has_include(${header_name}), "header not found") > > is not allowed, right? Right. SD-6 recommends only that __has_include be usable in preprocessor-if. > The names of some features known to CMake are not the same as > those used > by Clang/SD6. For example: > > 1) I don't know what the 'nsdmi' part of __cpp_aggregate_nsdmi > means, so > I named that feature 'cxx_aggregate_default_initializers' as it is > for > mortal consumption. "NSDMI" stands for "non-static data member initializer" -- which is an accurate and adequately-qualified term, but pretty unwieldy. > 2) cxx_init_captures seemed too generically named, so I added a > 'lambda' > to the name: cxx_lambda_init_captures. Lambdas are the only things that do capturing, at least today. Yes, SG10's choice will look unfortunate if we ever invent something else that also captures. > Consider recommending definition of the __cpp_lib macros in a > single > file instead of in multiple files. Well, I am very, very far from a C++ library implementer, so everything I say about this should be taken with a kilo of salt. But I certainly imagined that, when an implementer implemented some small library feature, he might want to modify only the single file containing the code that actually needs to be modified to provide the feature, and that he might add the macro definition to the same file at the same time. Of course it's possible to imagine some purpose for which that's not the best way to make the change, but I'd rather it be possible to do the implementation of simple things simply. > There are problems with bugs in implementations which I don't > think I > have a good solution for. There's clearly no good solution to bugs, from the perspective of the specification. (No, wait: "An implementation shall not have bugs." That was easy. :-) Clark _______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features