Nelson, Clark wrote: > 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.
Any change made will certainly also require unit tests and probably also an update to a status page noting its completion. See for example https://github.com/llvm-mirror/libcxx/commit/ebd6c2b8 which has exactly that form. The goal of 'minimize the number of files a programmer must modify' is not useful and even not desirable because it encourages bad practice - good practice encourages creation of commit history like the above which introduces the feature and its tests (and documentation) in one commit. Anyone else reading the commit in the future (or like us now) can see the implementation, and the effect by reading the tests. That is good practice, so trying to allow confining commits to a single file is not a useful or desirable goal. >> 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. :-) My point was that programmers will not use the __cpp_foo defines directly, other than to set their own defines. Programmers will encounter problems such as: 1) Compiler x documents that feature y works, and defines __cpp_foo to 201404. However, the implementation is utterly broken (for our purposes at least), and so we can not rely on the __cpp_foo define. See http://thread.gmane.org/gmane.comp.lib.boost.devel/245202/focus=245221 http://thread.gmane.org/gmane.comp.lib.boost.devel/244986/focus=245333 http://connect.microsoft.com/VisualStudio/feedback/details/800364/initializer-list-calls-object-destructor-twice http://connect.microsoft.com/VisualStudio/feedback/details/802058/c-11-unified-initialization-fails-with-c-style-arrays 2) Compiler x documents that feature y works, but does not set the _cpp_foo macro appropriately. Users of compiler x expect the feature to be available as documented, so we can not rely on the __cpp_foo define and need to fall back to a version test. See http://llvm.org/bugs/show_bug.cgi?id=19698 http://llvm.org/bugs/show_bug.cgi?id=19674 3) Compiler x documents availability of feature y in version a.b.c, however, version a.a.a of compiler x seems to parse the code and the feature seems to work. It is likely that the feature is only partly implemented in version a.a.a, and it would not work in some important cases. The __cpp_foo macro may or may not be defined appropriately in this case. See the note about cxx_constexpr here: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#adding-compile-features In all of the above cases, the solution is for the programmer to maintain their own set of defines like BOOST_FOO or QT_FOO etc, implemented in terms of (ie, wrapping) __cpp_foo. That is a reality which might be worth reflecting in the document somehow (possibly). I really only mention it for completeness, but I also want to ensure that what I'm talking about is understood :). Thanks, Steve. _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
