This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
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>(); }