"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d7imf1$ka1$1@sea.gmane.org...
christopher diggins wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d7iigr$7tn$1@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