You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Eric Lemings <Er...@roguewave.com> on 2008/06/11 00:45:44 UTC
Empty member initializers
>From $TOPDIR/include/rw/_pair.h:
64 // 20.2.2, p2
65 pair ()
66 #ifndef _RWSTD_NO_EMPTY_MEM_INITIALIZER
67 : first (/* lwg issue 265 */), second () { }
68 #else
69 // assumes types satisfy the CopyConstructible
requirements
70 : first (first_type ()), second (second_type ()) { }
71 #endif // _RWSTD_NO_EMPTY_MEM_INITIALIZER
Are empty member initializers something we still need to concern
ourselves with? Is LWG issue 265 still pertinent?
Thanks,
Brad.
RE: Empty member initializers
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Sunday, June 29, 2008 2:13 AM
> To: dev@stdcxx.apache.org
> Subject: Re: Empty member initializers
>
> > From below...
> >
> > _RWSTD_NO_INLINE_MEMBER_TEMPLATES /* not used at all */
>
> This macro shouldn't exist anymore:
> http://issues.apache.org/jira/browse/STDCXX-339
>
> Looks like Farid forgot to remove the config test (and the
> text from the README).
Yes, it's my fault. Fixed in 4.2.x thus
http://svn.apache.org/viewvc?rev=673060&view=rev
and will be merged into 4.3.x and trunk shortly.
Farid.
Re: Empty member initializers
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> 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 */
This macro shouldn't exist anymore:
http://issues.apache.org/jira/browse/STDCXX-339
Looks like Farid forgot to remove the config test (and the text
from the README).
Martin
>
> 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.
>>>>>
>>>
Re: Empty member initializers
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Eric Lemings wrote:
>>
>>> Travis Vitek wrote:
>>>
>>>> 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 */
>> Well there's an INLINE_MEMBER_TEMPLATES.cpp check and then there's a
>> separate MEMBER_TEMPLATES.cpp check. I assume they check different
>> things. :)
>
> Yes, I realize this. The former checks that inline member templates are
> supported. The latter checks that member templates can be defined
> outside the body of the class.
>
> AFAICT, inline member templates are used in library code without guards,
> so you can safely assume support for 4.2.x and later.
>
> If you want anything further than that [i.e. member templates defined
> outside the body of the class, member template overloads, ...], you have
> to look to see what all of the supported compilers allow. If one or more
> of the currently supported compilers defines _RWSTD_NO_MEMBER_TEMPLATES,
> then you will likely have to work around the issue in any new code. If
> none of them define it, then some decision will have to be made if it is
> safe to assume support for other compilers or not.
Starting with 4.3.0, I think we can safely assume full support for
member templates and remove all workarounds involving the macros
as well as the macros (and the config test) themselves. The only
thing I'd double-check before doing this cleanup is string when
using HP aCC 3 because of an extern template bug.
I don't even think there is a compiler that we target with 4.2.x
that doesn't support member templates in any form. IIRC, the last
one that had trouble with member templates (their out-of-line
definitions) was MSVC 6.
Martin
RE: Empty member initializers
Posted by Travis Vitek <Tr...@roguewave.com>.
>Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> >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 */
>
>Well there's an INLINE_MEMBER_TEMPLATES.cpp check and then there's a
>separate MEMBER_TEMPLATES.cpp check. I assume they check different
>things. :)
Yes, I realize this. The former checks that inline member templates are
supported. The latter checks that member templates can be defined
outside the body of the class.
AFAICT, inline member templates are used in library code without guards,
so you can safely assume support for 4.2.x and later.
If you want anything further than that [i.e. member templates defined
outside the body of the class, member template overloads, ...], you have
to look to see what all of the supported compilers allow. If one or more
of the currently supported compilers defines _RWSTD_NO_MEMBER_TEMPLATES,
then you will likely have to work around the issue in any new code. If
none of them define it, then some decision will have to be made if it is
safe to assume support for other compilers or not.
Travis
>
>Brad.
>
RE: Empty member initializers
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
> Sent: Monday, June 16, 2008 3:34 PM
> To: dev@stdcxx.apache.org
> Subject: RE: Empty member initializers
>
>
>
> >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 */
Well there's an INLINE_MEMBER_TEMPLATES.cpp check and then there's a
separate MEMBER_TEMPLATES.cpp check. I assume they check different
things. :)
Brad.
RE: Empty member initializers
Posted by Travis Vitek <Tr...@roguewave.com>.
>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.
>> >>
>>
>>
>
RE: Empty member initializers
Posted by Eric Lemings <Er...@roguewave.com>.
How about member templates? Are these unilaterally supported by all
compilers now?
Brad.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Thursday, June 12, 2008 6:01 AM
> To: dev@stdcxx.apache.org
> Subject: Re: Empty member initializers
>
> 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.
> >>
>
>
Re: Empty member initializers
Posted by Martin Sebor <se...@roguewave.com>.
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.
>>
RE: Empty member initializers
Posted by Travis Vitek <Tr...@roguewave.com>.
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.
_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
_RWSTD_NO_LONG_DOUBLE
_RWSTD_NO_LONG_LONG
_RWSTD_NO_WCHAR_T
_RWSTD_NO_NATIVE_WCHAR_T
>Brad.
>
RE: Empty member initializers
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
> Sent: Tuesday, June 10, 2008 5:14 PM
> To: dev@stdcxx.apache.org
> Subject: RE: Empty member initializers
>
>
>
> Eric Lemings wrote:
> >
> >
> >From $TOPDIR/include/rw/_pair.h:
> >
> > 64 // 20.2.2, p2
> > 65 pair ()
> > 66 #ifndef _RWSTD_NO_EMPTY_MEM_INITIALIZER
> > 67 : first (/* lwg issue 265 */), second () { }
> > 68 #else
> > 69 // assumes types satisfy the CopyConstructible
> requirements
> > 70 : first (first_type ()), second (second_type ()) { }
> > 71 #endif // _RWSTD_NO_EMPTY_MEM_INITIALIZER
> >
> >Are empty member initializers something we still need to concern
> >ourselves with? Is LWG issue 265 still pertinent?
> >
>
> According to the defect, the resolution is in the current
> working paper,
> so I don't think you need to worry about it changing. I don't know of
> any modern compilers for which the EMPTY_MEM_INITIALIZER.cpp
> test would
> fail.
>
> 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?
Brad.
RE: Empty member initializers
Posted by Travis Vitek <Tr...@roguewave.com>.
Eric Lemings wrote:
>
>
>>From $TOPDIR/include/rw/_pair.h:
>
> 64 // 20.2.2, p2
> 65 pair ()
> 66 #ifndef _RWSTD_NO_EMPTY_MEM_INITIALIZER
> 67 : first (/* lwg issue 265 */), second () { }
> 68 #else
> 69 // assumes types satisfy the CopyConstructible
requirements
> 70 : first (first_type ()), second (second_type ()) { }
> 71 #endif // _RWSTD_NO_EMPTY_MEM_INITIALIZER
>
>Are empty member initializers something we still need to concern
>ourselves with? Is LWG issue 265 still pertinent?
>
According to the defect, the resolution is in the current working paper,
so I don't think you need to worry about it changing. I don't know of
any modern compilers for which the EMPTY_MEM_INITIALIZER.cpp test would
fail.
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.
>Thanks,
>Brad.
>