This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 example:

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

class MyType
{
public:
    // ...
    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.

-Howard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]