[SG10] A view from CMake

Stephen Kelly steveire at gmail.com
Tue Jun 3 09:46:17 CEST 2014


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.


More information about the Features mailing list