This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PODs vs memset
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: 03 Apr 2007 18:40:14 -0500
- Subject: Re: PODs vs memset
- References: <4612DD38.3020204@suse.de>
Paolo Carlini <pcarlini@suse.de> writes:
| Hi everyone, hi Gaby,
|
| while quickly adapting valarray to use the front-end __is_pod instead
| of the library version (otherwise it didn't compile), I adjusted this
| code in valarray:
|
| template<typename _Tp>
| struct _Array_default_ctor<_Tp, true>
| {
| // For fundamental types, it suffices to say 'memset()'
| inline static void
| _S_do_it(_Tp* __restrict__ __b, _Tp* __restrict__ __e)
| { std::memset(__b, 0, (__e - __b) * sizeof(_Tp)); }
| };
|
| template<typename _Tp>
| inline void
| __valarray_default_construct(_Tp* __restrict__ __b, _Tp*
| __restrict__ __e)
| {
| _Array_default_ctor<_Tp, __is_pod(_Tp)>::_S_do_it(__b, __e);
| }
|
| I think you (Gaby) made sure the latter scheme worked fine with the message:
|
| http://gcc.gnu.org/ml/gcc/2005-12/msg00266.html
|
| Now however the problem is that __is_pod actually establishes
| POD-ness, not just a weak subset of it (basically only scalars),
| therefore wanted to double check with you that the positive result of
| that thread also holds for all POD types. Depending on the answer I
| will either:
|
| 1- To be safe, change valarray to use a library-based __is_scalar
| or whatelse you would suggest.
| 2- Do not further change valarray and instead think about
| improving stl_algobase.h / stl_uninitialized.h / maybe the containers
| (I have to see) consistently with the above, thus always using memset
| (zero) for default-construction of POD types.
valarray was intended to work with "numerical" types (a notion that is
fuzzily defined in the Standard), which roughly is what we used to
think of a POD. However, the notion of the POD has been improving and
we may get to the state where POD no longer ressembles what it used to
be. I don't know the actual state of the resolution but I was under
the impression that a pointer to member is now considered a POD. If
that is true, then we get into the situation where a null pointer
wrongly captured -- it is represented as -1, and not 0. That would
invalidate the "optimization". On the other hand, I very much feel
that if someone instantiates valarray with pointer to member type, he/she
gets what he/she deserves. But, I don't get to define the semantics
so I would suggest to just proceed with __is_scalar until we get a
better characterization -- for example, I would really love to have
valarray<complex<double>> be memset'ed (yes, I know I can use traits,
but it would be nice if we come up with a very simple characterization
in C++03 that is simply captured by those reifying functions.
-- Gaby