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)


Gabriel Dos Reis wrote:
Daniel Jacobowitz <drow@false.org> writes:

On Mon, Sep 25, 2006 at 04:32:03AM +0200, Gabriel Dos Reis wrote:
Under the proposed plan, we're heading experimental route in the
hope of luring more users into using GCC because it would be the
first to implement some new features.  Such features come with
command-line options, which triggers hard error (current GCC
behaviour) when not supported.  Consequently, the additional macro
feature-test is unnecessary bloat and distraction: if the feature
is not supported, the compiler would not even get the chance to get
to the source code that test it.

Doesn't that miss the point? He mentioned libraries; the library may want to make some c++0x-only interfaces available, if the user requests them, along the same lines as GCC.

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. Something like


struct X
{
   X( X const & x ); // copy

#ifdef __RVALUE_REF

X( X && rx ); // move

#endif
};

So if I compile it with a plain C++98 compiler, I get no move support. If I compile it with a compiler that supports rvalue references (g++ --experimental-rvalue-ref), I get move support.


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