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: PODs vs memset


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


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