boost::array fails ContainerConcept check in 1.32 [patch]

I hope I've got the right list here (first time poster), my apologies if I don't :-). boost::array fails a ContainerConcept check in 1.32 due to it's lack of a const_pointer typedef: #include <boost/array.hpp> #include <boost/concept_check.hpp> int main ( void ) { using namespace boost; function_requires< ContainerConcept< array< int , 5 > > >(); } Resulting errors using MinGW's GCC 3.4.2: boost/concept_check.hpp: In instantiation of `boost::ContainerConcept<boost::array<int, 5u> >': boost/concept_check.hpp:48: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::ContainerConcept<boost::array<int, 5u> >]' ../main.cc:7: instantiated from here boost/concept_check.hpp:683: error: no type named `const_pointer' in `class boost::array<int, 5u>' I noticed the BCCL links to SGI's documentation for the Contanier concept, which actually does not appear to list a const_pointer (see http://www.sgi.com/tech/stl/Container.html), although it does include pointer, which array is lacking. As allready mentioned, I tried this with 1.32 - I also tried the CVS head version, no idea if that's the latest that I should be checking or what (CVS newbie), but this wasn't fixed in there. In any case, adding const_pointer to array allows the simple example to compile - here's a patch which adds this and pointer (hopefully in an OK format - I'm a solo hobbyist, not used to working on large projects) which adds them... let me know if I can be of any other help :-). Index: array.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/array.hpp,v retrieving revision 1.23 diff -u -r1.23 array.hpp --- array.hpp 9 Sep 2004 13:59:00 -0000 1.23 +++ array.hpp 28 May 2005 00:58:03 -0000 @@ -50,6 +50,8 @@ typedef const T* const_iterator; typedef T& reference; typedef const T& const_reference; + typedef T* pointer; + typedef const T* const_pointer; typedef std::size_t size_type; typedef std::ptrdiff_t difference_type;

Michael B. Edwin Rickert wrote:
I hope I've got the right list here (first time poster), my apologies if I don't :-).
boost::array fails a ContainerConcept check in 1.32 due to it's lack of a const_pointer typedef:
Note that boost::array is not a (standard) conforming container anyway! Array, by design, has a fixed number of elements. The container concept requires the ability to add and remove elements. Likewise, the pointer and const_pointer requirements are part of allocator support. As boost::array does not support allocators, it should not need these elements and any tests requiring them is flawed. -- AlisdairM

AlisdairM wrote:
Michael B. Edwin Rickert wrote:
I hope I've got the right list here (first time poster), my apologies if I don't :-).
boost::array fails a ContainerConcept check in 1.32 due to it's lack of a const_pointer typedef:
Note that boost::array is not a (standard) conforming container anyway!
Array, by design, has a fixed number of elements. The container concept requires the ability to add and remove elements.
I wasn't aware of this, although I was aware of some of the other reasons it's not a standard conforming container from the documentation (although in retrospect, "size() is allways constant" did seem odd).
Likewise, the pointer and const_pointer requirements are part of allocator support. As boost::array does not support allocators, it should not need these elements and any tests requiring them is flawed.
True, I suppose I should implement my own concepts for this (e.g. IterateableConcept and HasASizeConcept for my instances). That said, one of the goals of Boost.Array to emulate (as close as possible without violating some of the other goals) a standard container... Then again, if one relies on such a ContainerConcept check and then proceeds to use an allocator with the type, I suppose adding this could ruin some perfectly good checks if one tried to pass a boost::array - although one could argue that's a missing feature in Boost's ContainerConcept... Oh well, I got to practice using some tools I have not used before, so no time wasted :-). Thanks, -Mike
participants (2)
-
AlisdairM
-
Michael B. Edwin Rickert