Re: [Boost-users] Boost.Range fancify please

Subject: Re: [Boost-users] Boost.Range fancify please
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2009-12-27 20:29:31

anony wrote:
> The make_iterator_range() function sees only 2 pointers and these are
> all it cares about. Now, let's check the standard:
>
> ISO-IEC-14882 Section 8.3.4 Array, page 137:
>
> An object of array type contains a contiguously allocated non-
> empty set of N sub-objects of type T.
That's referring to a dimension 1 array explicitly, so doesn't have
much bearing on this.  In particular a two dimension array data[2][2]
is built by a compiler like this:

data[0] -=>[data[0][0]][data[0][1]]
data[1] -=>[data[1][0]][data[1][1]]

It's required by the standard, as you quoted, for data[0][0] and
data[0][1] to be contiguous, for data[1][0] and data[1][1] to be
contiguous, and also required for the pointers data[0] and data[1] to
be contiguous (although their existence might get optimized away), but
not AT ALL required for data[0][1] and data[1][0] (i.e. the two rows)
to be contiguous.  i.e. data[0] could point at one chunk of memory for
the first row, and data[1] can point at memory megabytes away and it
will meet the requirements of the standard.  The compiler you're using
chooses to allocate the memory for all the rows in one contiguous
chunk, (at least some of the time as you discovered), so you get lucky
at taking advantage of implementation defined behavior.  I wouldn't
depend on it if I were you.
> The pointers I provide point to the beginning and the end of the
> vertices multidimensional array. The array must be contiguously
> allocated, as specified in the standard, hence I don't see which aspect
> of what I am doing in undefined, if the functions boost::begin() and
> boost::end() work as expected (again, they return pointers, not fancy
> iterator objects).
>
> Did I mention the debugger shows everything is just perfect.
Yes, it shows what your compiler implements in this circumstance, but
tells you nothing about what will be done by other compilers, or by
your own compiler in all circumstances.   When you take advantage of
implementation defined behavior, you're gambling with no guarantees
except that if it fails it's your fault and you don't get to complain
to the compiler implementor. 
> > > > Why not just use BOOST_FOREACH correctly?
> > > >
> > > >    BOOST_FOREACH(float (&rgf)[3], vertices)
> > > >      BOOST_FOREACH(float&  f, rgf)
> > > >        f *= scale;
> > > >       
> > > Double loop, oops. Not fancy enough.
> > >     
> > Are you joking?
> >   
>
> I was looking for fancy (i.e. elegant) code, yours is too complicated.
It's pretty normal to use nested loops for nested elements, and
prettily enough, you are dealing with each element, scaling it, so this
is a perfect use of foreach.  I think it's quite elegant, both
generating minimal assembler and being clear and maintainable.

Patrick