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: empty slices: defined?


> The way *I* see it is that slices are implementation detail helper
> function/classes for selecting subsets of value arrays.  *My* view is that
> the default constructors are allowed so that one can put them in
> vectors or arrays, e.g.
>     
> 
>     std::slices ix[N];
> 
> and assign to them.

Right, but consider... there are two types of slices (slice and
gslice).  *One* of them says that you can only use the default
constructor for the above case.  The *other* one does not.  "There
must be a reason why they're documented differently."

> For (2), I'm open to anything that does not introduce more checks.

The two patches would be trivial, but both add some overhead:

For slice, just initialize all three fields to zero:

  inline
  slice::slice() { _M_off = _M_sz = _M_st = 0; }

For gslice, the problem line is this one (and the one after it):

  template<typename _Tp>
    inline _Expr<_GClos<_ValArray,_Tp>, _Tp>
    valarray<_Tp>::operator[](const gslice& __gs) const
    {
      typedef _GClos<_ValArray,_Tp> _Closure;
      return _Expr<_Closure, _Tp>
	(_Closure(_Array<_Tp>(_M_data), __gs._M_index->_M_index));	<<<<<<<
    }

We're passing a reference, so the NULL pointer isn't dereferenced
yet... we end up with a pointer which is the XtOffset() of _M_index,
and later on you dereference *that* and it faults.

Everywhere else we check it:

  inline valarray<size_t>
  gslice::stride () const
  { return _M_index ? _M_index->_M_stride : valarray<size_t>(); }


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