Boost logo

Boost :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-05-31 18:59:32


"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
news:d7imf1$ka1$1_at_sea.gmane.org...
> christopher diggins wrote:
>> "Jonathan Turkanis" <technews_at_[hidden]> wrote in message
>> news:d7iigr$7tn$1_at_sea.gmane.org...
>>> boost::array is just supposed to give built-in arrays a container
>>> interface.
>>> Built-in arrays never have size 0, so I don't see why boost::arrays
>>> should.
>
> I forgot that array allows N = 0 as a special case. Anyway, it has a
> completely
> different meaning than "unitialized"
>
>> It would indicate that the array was not yet initialized and could
>> help prevent erroneous use of uninitialized arrays. This behaviour is
>> in fact implied by the fact that there exists an empty() function and
>> separate size() and max_size() functions. The documentation IMO
>> contradicts the intuitive interepretation of the class declaration.
>
> Those functions are for consistency with the STL containers, as you
> mentioned
> before. I'm don't see the contradiction.

But it isn't an STL container! This so-called consistency is a dangerous
illusion. Partial conformancy will lead to boost::array begin used in
contexts where an STL container is expected but will instead cause the code
to break silently because boost::array violates the container
postconditions. Just for example consider the following common idiom:

template<class Container_T>
void some_very_dangerous_code(Container_T& x) {
  x = Container_T();
  if (x.empty()} {
    SayHelloToAlphaCentauri();
  }
  else {
    SendNukesToAlphaCentauri();
  }
}

Obviously this will not work as expected. By explicitly *not* being
consistent you avoid these headaches. You also don't confuse an intelligent
yet inexpereienced programmer.

My point is that Boost.Array can easily be conformant, or else it can be
explicitly non-conformant, but somewhere in between is just asking for
trouble.

--
Christopher Diggins

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk