incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: Empty member initializers
Date Mon, 16 Jun 2008 21:34:27 GMT
 

>Eric Lemings wrote:
> 
>How about member templates?  Are these unilaterally supported by all
>compilers now?
>

>From below...

  _RWSTD_NO_INLINE_MEMBER_TEMPLATES /* not used at all */

As long as you provide a definition of the template inside the body of
the class, it seems all of the compilers we support are happy. If you
move the definition out, then all bets are off.

>Brad.
>
>Martin Sebor wrote:
>> 
>> Travis Vitek wrote:
>> >  
>> > Eric Lemings wrote:
>> >>
>> >> Travis Vitek wrote:
>> >>>  
>> >>>
>> >>> This all gets back to the discussion we were having a few 
>> weeks ago
>> >>> about which compiler features we should expect the compiler 
>> >>> support for
>> >>> 4.3.x.
>> >> I'm adding a Wiki page listing these compiler requirements 
>> but I can
>> >> only think of one or two ATM.  What else should be on this list?
>> >>
>> > 
>> > Well, I'd like to think that we could eliminate all of 
>> these. Without
>> > some of them them it becomes much more difficult or impossible to
>> > implement some of meta classes.
>> 
>> I agree with this list with a couple of exceptions:
>> 
>> > 
>> >   _RWSTD_NO_CLASS_PARTIAL_SPEC
>> >   _RWSTD_NO_BOOL
>> > 
>> > I can live with keeping the following, but a modern compiler should
>> > really support these
>> > 
>> >   _RWSTD_NO_TYPENAME
>> >   _RWSTD_NO_EXPLICIT
>> >   _RWSTD_NO_EXPLICIT_ARG
>> >   _RWSTD_NO_FRIEND_TEMPLATE
>> >   _RWSTD_NO_FUNC_PARTIAL_SPEC
>> >   _RWSTD_NO_NEW_FUNC_TEMPLATE_SYNTAX
>> >   _RWSTD_NO_NEW_CLASS_TEMPLATE_SYNTAX
>> >   _RWSTD_NO_INLINE_MEMBER_TEMPLATES /* not used att all */
>> >   _RWSTD_NO_NAMESPACE
>> 
>> The macro can probably go but we might need to continue
>> to support _RWSTD_NAMESPACE() and add namespace renaming
>> (including std).
>> 
>> >   _RWSTD_NO_LONG_DOUBLE
>> >   _RWSTD_NO_LONG_LONG
>> 
>> This one can't go until the next standard has been ratified
>> and EDG eccp supports long long in strict mode.
>> 
>> In general, my feeling is that starting perhaps as early as
>> 4.3 but certainly 5.0 we should feel free to assume a C++ 03
>> conforming compiler unless there is some value in doing
>> otherwise (e.g., supporting users who wish to compile with
>> exceptions disabled).
>> 
>> Martin
>> 
>> >   _RWSTD_NO_WCHAR_T
>> >   _RWSTD_NO_NATIVE_WCHAR_T
>> > 
>> >> Brad.
>> >>
>> 
>> 
>

Mime
View raw message