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/12 19:55:30 UTC
RE: remove_reference
Hmm. So what's the benefit in providing internal type traits
at all? Seems to me that they only serve to slow down compile
times. Why not just break the public type traits into internal
headers and include them all from the <type_traits> header?
Or do we have some plans for the internal type traits that I'm
unaware of?
Brad.
P.S. Forwarded to stdcxx dev list.
> -----Original Message-----
> From: Travis Vitek
> Sent: Thursday, June 12, 2008 11:51 AM
> To: Eric Lemings
> Subject: RE: remove_reference
>
>
> Yes, and the internal ones don't inherit from
> integral_constant<T,V>, they inherit from
> __rw_integral_constant<T,V> [where applicable]
>
> Travis
>
> >-----Original Message-----
> >From: Eric Lemings
> >Sent: Thursday, June 12, 2008 10:48 AM
> >To: Travis Vitek
> >Subject: RE: remove_reference
> >
> >
> >So the only key difference is that they -- the internal type
> >traits -- can be included by group rather than the whole?
> >
> >Brad.
> >
> >> -----Original Message-----
> >> From: Travis Vitek
> >> Sent: Thursday, June 12, 2008 11:33 AM
> >> To: Eric Lemings
> >> Subject: RE: remove_reference
> >>
> >>
> >> They are intended to be exactly the same. They are used by
> >> the implementation of the public traits.
> >>
> >> >-----Original Message-----
> >> >From: Eric Lemings
> >> >Sent: Thursday, June 12, 2008 10:27 AM
> >> >To: Travis Vitek
> >> >Subject: RE: remove_reference
> >> >
> >> >
> >> >Anything especially that I need to be aware of when using the
> >> >internal type traits? Or are they virtually the same as the
> >> >public type traits?
> >> >
> >> >Brad.
> >> >
> >> >> -----Original Message-----
> >> >> From: Travis Vitek
> >> >> Sent: Thursday, June 12, 2008 10:59 AM
> >> >> To: Eric Lemings
> >> >> Subject: RE: remove_reference
> >> >>
> >> >>
> >> >> If you wanted std::remove_reference, you'd have to include
> >> >> <type_traits>. That is where all of the standard traits are
> >> >> defined. If you want the internal trait
> >> >> _RW::__rw_remove_reference, you could still include
> >> >> <type_traits> if you wanted, or you could include
> ><rw/_meta_ref.h>.
> >> >>
> >> >> I decided to break them down by their section in the
> >> >> standard. The remove_reference template is actually in
> >> >> meta.trans.ref, but that name would have been too long. I
> >> >> plan on submitting sometime this afternoon. I need to verify
> >> >> everything on gcc 4.3 again and that should be it.
> >> >>
> >> >> Travis
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Eric Lemings
> >> >> >Sent: Thursday, June 12, 2008 9:12 AM
> >> >> >To: Travis Vitek
> >> >> >Subject: remove_reference
> >> >> >
> >> >> >Travis,
> >> >> >
> >> >> >Based on your latest version, which header would I include if
> >> >> >I just wanted the std::remove_reference type modifier?
> >> >> >
> >> >> >Brad.
> >> >> >
> >> >> >
Re: remove_reference
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Martin Sebor wrote:
>>
>> Eric Lemings wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Travis Vitek
>>>> Sent: Thursday, June 12, 2008 4:18 PM
>>>> To: Eric Lemings
>>>> Subject: RE: remove_reference
>>>>
>>>>
>>>>
>>>>> Eric Lemings
>>>>>
>>> ...
>>>>> I think you sorta missed my point. My point is that if
>> the internal
>>>>> type traits do not provide any real added value, why bother with
>>>>> them? Say you have an internal class __rw_foo and a public class
>>>>> foo which derives from __rw_foo but is virtual identical, why have
>>>>> __rw_foo at all? Why not move everything in __rw_foo directly into
>>>>> foo?
>>>>>
>>>> Sorry, I understood what you were getting at, I just didn't
>>>> come right out and provide the answer you were looking for.
>>>> Yes, we intend to use traits in the library implementation
>>>> where we can take advantage of them for performance
>>>> improvements. The example I provided above is just one of
>>>> many situations that we may do so.
>>> Performance improvements...such as taking advantage of
>> built-in compiler
>>> type traits? If that were the case, I could see the
>> rationale for using
>>> internal type traits as a proxy for such optimization. So I
>> guess there
>>> is SOME value after all. :)
>> The original idea, IIRC, was to expose the implementation
>> of the traits in the form of _RWSTD_XXX() macros to be used
>> by the rest of our code, including the standard type traits
>> template. Each macro would expand into either the compiler
>> built-in for compilers that supported them or to our own
>> __rw_xxx trait otherwise. The reason for this was to avoid
>> paying a penalty in terms of increased compile times and
>> keep the <type_traits> header free of unnecessary clutter
>> when using the compiler-provided traits, as well as to avoid
>> namespace pollution when using the traits.
>>
>
> So I've managed to diverge from the original idea. This is almost funny
> considering all of the discussion that we had about the need for
> internal traits to inherit from __rw_integral_constant<>.
Yes. We both forgot what we had discussed. We need to write these
things down.
>
> Well, now that I've finally got the traits in subversion, I could go
> back and 'fix' this to compile out the implementation types when the
> necessary compiler support is not available. Something more like my
> original implementation.
>
> #ifndef _RWSTD_IS_POD
>
> template <class _TypeT>
> struct __rw_is_pod
> {
> enum { _C_value = _RWSTD_IS_TRIVIAL(_Type)
> && _RWSTD_IS_STANDARD_LAYOUT(_Type)
> };
> };
>
> # define _RWSTD_IS_POD(T) _RW::__rw_is_pod<T>::type
> #endif
FWIW, it might be worth waiting until it's been ported to other
compilers besides MSVC to see if it still makes sense and/or if
there is a better way to do it.
Martin
RE: remove_reference
Posted by Travis Vitek <Tr...@roguewave.com>.
>Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>>
>>> -----Original Message-----
>>> From: Travis Vitek
>>> Sent: Thursday, June 12, 2008 4:18 PM
>>> To: Eric Lemings
>>> Subject: RE: remove_reference
>>>
>>>
>>>
>>>> Eric Lemings
>>>>
>> ...
>>>> I think you sorta missed my point. My point is that if
>the internal
>>>> type traits do not provide any real added value, why bother with
>>>> them? Say you have an internal class __rw_foo and a public class
>>>> foo which derives from __rw_foo but is virtual identical, why have
>>>> __rw_foo at all? Why not move everything in __rw_foo directly into
>>>> foo?
>>>>
>>> Sorry, I understood what you were getting at, I just didn't
>>> come right out and provide the answer you were looking for.
>>> Yes, we intend to use traits in the library implementation
>>> where we can take advantage of them for performance
>>> improvements. The example I provided above is just one of
>>> many situations that we may do so.
>>
>> Performance improvements...such as taking advantage of
>built-in compiler
>> type traits? If that were the case, I could see the
>rationale for using
>> internal type traits as a proxy for such optimization. So I
>guess there
>> is SOME value after all. :)
>
>The original idea, IIRC, was to expose the implementation
>of the traits in the form of _RWSTD_XXX() macros to be used
>by the rest of our code, including the standard type traits
>template. Each macro would expand into either the compiler
>built-in for compilers that supported them or to our own
>__rw_xxx trait otherwise. The reason for this was to avoid
>paying a penalty in terms of increased compile times and
>keep the <type_traits> header free of unnecessary clutter
>when using the compiler-provided traits, as well as to avoid
>namespace pollution when using the traits.
>
So I've managed to diverge from the original idea. This is almost funny
considering all of the discussion that we had about the need for
internal traits to inherit from __rw_integral_constant<>.
Well, now that I've finally got the traits in subversion, I could go
back and 'fix' this to compile out the implementation types when the
necessary compiler support is not available. Something more like my
original implementation.
#ifndef _RWSTD_IS_POD
template <class _TypeT>
struct __rw_is_pod
{
enum { _C_value = _RWSTD_IS_TRIVIAL(_Type)
&& _RWSTD_IS_STANDARD_LAYOUT(_Type)
};
};
# define _RWSTD_IS_POD(T) _RW::__rw_is_pod<T>::type
#endif
>Martin
>
Re: remove_reference
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>
>> -----Original Message-----
>> From: Travis Vitek
>> Sent: Thursday, June 12, 2008 4:18 PM
>> To: Eric Lemings
>> Subject: RE: remove_reference
>>
>>
>>
>>> Eric Lemings
>>>
> ...
>>> I think you sorta missed my point. My point is that if the internal
>>> type traits do not provide any real added value, why bother with
>>> them? Say you have an internal class __rw_foo and a public class
>>> foo which derives from __rw_foo but is virtual identical, why have
>>> __rw_foo at all? Why not move everything in __rw_foo directly into
>>> foo?
>>>
>> Sorry, I understood what you were getting at, I just didn't
>> come right out and provide the answer you were looking for.
>> Yes, we intend to use traits in the library implementation
>> where we can take advantage of them for performance
>> improvements. The example I provided above is just one of
>> many situations that we may do so.
>
> Performance improvements...such as taking advantage of built-in compiler
> type traits? If that were the case, I could see the rationale for using
> internal type traits as a proxy for such optimization. So I guess there
> is SOME value after all. :)
The original idea, IIRC, was to expose the implementation
of the traits in the form of _RWSTD_XXX() macros to be used
by the rest of our code, including the standard type traits
template. Each macro would expand into either the compiler
built-in for compilers that supported them or to our own
__rw_xxx trait otherwise. The reason for this was to avoid
paying a penalty in terms of increased compile times and
keep the <type_traits> header free of unnecessary clutter
when using the compiler-provided traits, as well as to avoid
namespace pollution when using the traits.
Martin
RE: remove_reference
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Travis Vitek
> Sent: Thursday, June 12, 2008 4:18 PM
> To: Eric Lemings
> Subject: RE: remove_reference
>
>
>
> >Eric Lemings
> >
...
> >
> >I think you sorta missed my point. My point is that if the internal
> >type traits do not provide any real added value, why bother with
> >them? Say you have an internal class __rw_foo and a public class
> >foo which derives from __rw_foo but is virtual identical, why have
> >__rw_foo at all? Why not move everything in __rw_foo directly into
> >foo?
> >
>
> Sorry, I understood what you were getting at, I just didn't
> come right out and provide the answer you were looking for.
> Yes, we intend to use traits in the library implementation
> where we can take advantage of them for performance
> improvements. The example I provided above is just one of
> many situations that we may do so.
Performance improvements...such as taking advantage of built-in compiler
type traits? If that were the case, I could see the rationale for using
internal type traits as a proxy for such optimization. So I guess there
is SOME value after all. :)
Brad.
RE: remove_reference
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Travis Vitek
> Sent: Thursday, June 12, 2008 3:19 PM
> To: Eric Lemings
> Cc: 'dev@stdcxx.apache.org'
> Subject: RE: remove_reference
>
>
>
> Eric Lemings wrote:
> >
> >Hmm. So what's the benefit in providing internal type traits
> >at all? Seems to me that they only serve to slow down compile
> >times. Why not just break the public type traits into internal
> >headers and include them all from the <type_traits> header?
> >Or do we have some plans for the internal type traits that I'm
> >unaware of?
> >
>
> It is my understanding that the internal traits exist to
> avoid namespace pollution. Say we wanted to optimize
> std::uninitialized_fill<> for pod types. If we used
> std::is_pod<>, then the user would be able to use that type
> and possibly others without including <type_traits>.
>
> Honestly, I don't see this as a great benefit, but it is
> something that has been important to the implementation in the past.
>
> As for the argument of slowing down compile times, there has
> been some bickering about this in the past; should we put
> comments in the headers or should we be splitting up large
> headers into multiple small ones and should we coalesce
> multiple headers into one. I don't buy it unless someone has
> a reasonable testcase as evidence.
I think you sorta missed my point. My point is that if the internal
type traits do not provide any real added value, why bother with
them? Say you have an internal class __rw_foo and a public class
foo which derives from __rw_foo but is virtual identical, why have
__rw_foo at all? Why not move everything in __rw_foo directly into
foo?
That's why I was asking if there are some future plans for the internal
type traits that will provide some additional value. Otherwise, we
really don't need them and they're actually just polluting our internal
namespace.
Brad.
Re: remove_reference
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Friday, June 13, 2008 11:04 AM
>> To: dev@stdcxx.apache.org
>> Subject: Re: remove_reference
>>
>> Namespace pollution causes portability problems because of
>> the underspecified contents of standard library headers.
>> stdcxx goes to great lengths to avoid introducing symbols
>> into the std namespace unless required by the standard. For
>> example, while most other implementations expose the contents
>> of <cstdio> via <iostream>, stdcxx does not. Similarly, while
>> a number of other implementations expose the contents of (at
>> least) <ios> when <complex> or <string> are #included, stdcxx
>> goes to a lot of trouble to avoid it.
>
> This things are good in most cases, except one: the most
> implementations
> expose the contents of <ios> via <iomanip>, but stdcxx doesn't. So the
> users
> have to #include <ios> manually along with <iomanip. But many
> programmers
> assumes, that #include <iomanip> should be enough. In the result there
> are
> number or errors like "hex is not a member of std", for example when
> testing
> boost with stdcxx. Most of this errors are fixed in boost after I
> creating the issue
> ticket, but they are appearing in new code! The last one in file, added
> to the svn
> by 4 march 2008: http://svn.boost.org/trac/boost/ticket/2004.
Yes, this has been a common source of errors despite the standard
being quite clear on which header these manipulators are declared
in. There are also users who expect them to be declared in
<istream> and/or <ostream>. I am sympathetic to the first use
case but less so to the second. IMO, the right way to solve the
problem is to open an issue against the standard to require that
the manipulators be declared also in <iomanip>.
Martin
RE: remove_reference
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Friday, June 13, 2008 11:04 AM
> To: dev@stdcxx.apache.org
> Subject: Re: remove_reference
>
> Namespace pollution causes portability problems because of
> the underspecified contents of standard library headers.
> stdcxx goes to great lengths to avoid introducing symbols
> into the std namespace unless required by the standard. For
> example, while most other implementations expose the contents
> of <cstdio> via <iostream>, stdcxx does not. Similarly, while
> a number of other implementations expose the contents of (at
> least) <ios> when <complex> or <string> are #included, stdcxx
> goes to a lot of trouble to avoid it.
This things are good in most cases, except one: the most
implementations
expose the contents of <ios> via <iomanip>, but stdcxx doesn't. So the
users
have to #include <ios> manually along with <iomanip. But many
programmers
assumes, that #include <iomanip> should be enough. In the result there
are
number or errors like "hex is not a member of std", for example when
testing
boost with stdcxx. Most of this errors are fixed in boost after I
creating the issue
ticket, but they are appearing in new code! The last one in file, added
to the svn
by 4 march 2008: http://svn.boost.org/trac/boost/ticket/2004.
Farid.
Re: remove_reference
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Eric Lemings wrote:
>> Hmm. So what's the benefit in providing internal type traits
>> at all? Seems to me that they only serve to slow down compile
>> times. Why not just break the public type traits into internal
>> headers and include them all from the <type_traits> header?
>> Or do we have some plans for the internal type traits that I'm
>> unaware of?
>>
>
> It is my understanding that the internal traits exist to avoid namespace
> pollution. Say we wanted to optimize std::uninitialized_fill<> for pod
> types. If we used std::is_pod<>, then the user would be able to use that
> type and possibly others without including <type_traits>.
>
> Honestly, I don't see this as a great benefit, but it is something that
> has been important to the implementation in the past.
Namespace pollution causes portability problems because of
the underspecified contents of standard library headers.
stdcxx goes to great lengths to avoid introducing symbols
into the std namespace unless required by the standard. For
example, while most other implementations expose the contents
of <cstdio> via <iostream>, stdcxx does not. Similarly, while
a number of other implementations expose the contents of (at
least) <ios> when <complex> or <string> are #included, stdcxx
goes to a lot of trouble to avoid it. The benefit in this
in this is that software that uses stdcxx is more likely to
be readily portable to other implementations of other C++
standard library than would otherwise be the case.
>
> As for the argument of slowing down compile times, there has been some
> bickering about this in the past; should we put comments in the headers
> or should we be splitting up large headers into multiple small ones and
> should we coalesce multiple headers into one. I don't buy it unless
> someone has a reasonable testcase as evidence.
There is no doubt (and plenty of evidence exists) that template
metaprogramming puts much more stress on today's compilers that
the ordinary kind, and whole books have been written about the
costs of unrestrained header inclusion (e.g., Large Scale C++
Software Design by John Lakos). Compiler features such as
#pragma once have been implemented to deal with the header
problem. If we you believe these problems have been solved
I'd like to see evidence to that effect :)
Martin
RE: remove_reference
Posted by Travis Vitek <Tr...@roguewave.com>.
Eric Lemings wrote:
>
>Hmm. So what's the benefit in providing internal type traits
>at all? Seems to me that they only serve to slow down compile
>times. Why not just break the public type traits into internal
>headers and include them all from the <type_traits> header?
>Or do we have some plans for the internal type traits that I'm
>unaware of?
>
It is my understanding that the internal traits exist to avoid namespace
pollution. Say we wanted to optimize std::uninitialized_fill<> for pod
types. If we used std::is_pod<>, then the user would be able to use that
type and possibly others without including <type_traits>.
Honestly, I don't see this as a great benefit, but it is something that
has been important to the implementation in the past.
As for the argument of slowing down compile times, there has been some
bickering about this in the past; should we put comments in the headers
or should we be splitting up large headers into multiple small ones and
should we coalesce multiple headers into one. I don't buy it unless
someone has a reasonable testcase as evidence.
Travis
>Brad.
>
>
>
>> -----Original Message-----
>> From: Travis Vitek
>> Sent: Thursday, June 12, 2008 11:51 AM
>> To: Eric Lemings
>> Subject: RE: remove_reference
>>
>>
>> Yes, and the internal ones don't inherit from
>> integral_constant<T,V>, they inherit from
>> __rw_integral_constant<T,V> [where applicable]
>>
>> Travis
>>
>> >-----Original Message-----
>> >From: Eric Lemings
>> >Sent: Thursday, June 12, 2008 10:48 AM
>> >To: Travis Vitek
>> >Subject: RE: remove_reference
>> >
>> >
>> >So the only key difference is that they -- the internal type
>> >traits -- can be included by group rather than the whole?
>> >
>> >Brad.
>> >
>> >> -----Original Message-----
>> >> From: Travis Vitek
>> >> Sent: Thursday, June 12, 2008 11:33 AM
>> >> To: Eric Lemings
>> >> Subject: RE: remove_reference
>> >>
>> >>
>> >> They are intended to be exactly the same. They are used by
>> >> the implementation of the public traits.
>> >>
>> >> >-----Original Message-----
>> >> >From: Eric Lemings
>> >> >Sent: Thursday, June 12, 2008 10:27 AM
>> >> >To: Travis Vitek
>> >> >Subject: RE: remove_reference
>> >> >
>> >> >
>> >> >Anything especially that I need to be aware of when using the
>> >> >internal type traits? Or are they virtually the same as the
>> >> >public type traits?
>> >> >
>> >> >Brad.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Travis Vitek
>> >> >> Sent: Thursday, June 12, 2008 10:59 AM
>> >> >> To: Eric Lemings
>> >> >> Subject: RE: remove_reference
>> >> >>
>> >> >>
>> >> >> If you wanted std::remove_reference, you'd have to include
>> >> >> <type_traits>. That is where all of the standard traits are
>> >> >> defined. If you want the internal trait
>> >> >> _RW::__rw_remove_reference, you could still include
>> >> >> <type_traits> if you wanted, or you could include
>> ><rw/_meta_ref.h>.
>> >> >>
>> >> >> I decided to break them down by their section in the
>> >> >> standard. The remove_reference template is actually in
>> >> >> meta.trans.ref, but that name would have been too long. I
>> >> >> plan on submitting sometime this afternoon. I need to verify
>> >> >> everything on gcc 4.3 again and that should be it.
>> >> >>
>> >> >> Travis
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Eric Lemings
>> >> >> >Sent: Thursday, June 12, 2008 9:12 AM
>> >> >> >To: Travis Vitek
>> >> >> >Subject: remove_reference
>> >> >> >
>> >> >> >Travis,
>> >> >> >
>> >> >> >Based on your latest version, which header would I include if
>> >> >> >I just wanted the std::remove_reference type modifier?
>> >> >> >
>> >> >> >Brad.
>> >> >> >
>> >> >> >