C++ PATCH: PR 20599 (1/3)

Howard Hinnant hhinnant@apple.com
Mon Sep 25 12:43:00 GMT 2006

On Sep 25, 2006, at 7:30 AM, Gabriel Dos Reis wrote:

> "Peter Dimov" <pdimov@mmltd.net> writes:
> [...]
> | > you can use that library code only if GCC gets to the point of
> | > compiling it -- which can't happen when the compiler does not
> | > understand the option. Concretely, the feature-test is illusory
> | > unless you also change how
> | > GCC handls unrecognized command-line options.
> |
> | But the library could support both modes, with or without the
> | option.
> I do not disagree with that.  However, it could be  practically used
> in the extended mode only if you know in advance that the compiler
> supports it (because you have to explicit ask for it), which means
> you're actually in the position of supplying the guarding macro.

Without a feature-test macro, the library author will have to supply  
two separate implementations, and tell their clients:  Use this  
version over here if you enable this feature, else use that version  
over there.  This is true even if the two versions share 99% of their  
source base.

With a feature-test macro, one version of the library can adapt  
itself at compile time to serve both modes.  The client may even be  
completely unaware that such adaptation is taking place.  A prime  

#include <vector>
#include <map>
#include <string>

class MyType
     // ...
     MyType(MyType&& m);
     // ...

int main()
     std::vector<std::map<std::string, std::string> > dictionaries;
     // ... fill, manipulate and use dictionaries ...

The client may enable rvalue references for reasons other than  
optimizing the std::lib.  But if rvalue references are enabled for  
whatever reason (and the std::lib can detect that fact), the above  
code dealing with vectors of maps might mysteriously start running  
several times faster than before.

Doug's example with tuples and variadic templates is another such  
prime example.  You can use tuple with or without variadic  
templates.  Enable this language feature and your compile times  
significantly drop.

And then there are the synergistic combinations of language features  
to deal with.  A tuple taking advantage of both rvalue refs and  
variadic templates will be really sweet!  And I imagine we do not  
want four distinct versions of tuple:

1.  tuple without variadic templates and without rvalue references
2.  tuple without variadic templates and with    rvalue references
3.  tuple with    variadic templates and without rvalue references
4.  tuple with    variadic templates and with    rvalue references

One version of tuple which can automatically detect and react to the  
enabling/disabling of various language features would be far simpler  
for our customers to deal with.


More information about the Libstdc++ mailing list