C++ PATCH: PR 20599 (1/3)
Mon Sep 25 12:43:00 GMT 2006
On Sep 25, 2006, at 7:30 AM, Gabriel Dos Reis wrote:
> "Peter Dimov" <firstname.lastname@example.org> 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
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
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
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++