question: boost::array does not have compile time checked access
Dear all, I was wondering why boost::array did not offer compile time checked access to its contents, something like a.get<1>(), a similar interface like tuple. Otherwise I see not much enhancement compared to an ordinary std::vector. Wkr, me
On 03/08/05, gast128
Dear all,
I was wondering why boost::array did not offer compile time checked access to its contents, something like a.get<1>(), a similar interface like tuple. Otherwise I see not much enhancement compared to an ordinary std::vector.
Wkr, me
boost::array is allocated on the stack like a normal array, while a std::vector needs to use an allocator, usually putting it on the heap. Also, the normal usage pattern for arrays ( dynamic or otherwise ) is looping through them, the accesses in which cannot be compile-time checked. Note, however, that operator[] does assert that the index is valid--which quickly caught me a bug a little while back. - Scott McMurray
me22
On 03/08/05, gast128
wrote: Dear all,
I was wondering why boost::array did not offer compile time checked access
to
its contents, something like a.get<1>(), a similar interface like tuple. Otherwise I see not much enhancement compared to an ordinary std::vector.
Wkr, me
boost::array is allocated on the stack like a normal array, while a std::vector needs to use an allocator, usually putting it on the heap.
Also, the normal usage pattern for arrays ( dynamic or otherwise ) is looping through them, the accesses in which cannot be compile-time checked. Note, however, that operator[] does assert that the index is valid--which quickly caught me a bug a little while back.
- Scott McMurray
Yes I can see for myself that there are differences between boost::array and the vector. My point is only that one can add a compile time safe accessor to this array. This does not invalidate the need for a run time accessor like operator[]. Also this would create a big advantage over the vector. This heap and stack allocation stough could just be seen as implementation details. Wkr, me
On Aug 4, 2005, at 3:51 AM, gast128 wrote:
me22
writes: On 03/08/05, gast128
wrote: Dear all,
I was wondering why boost::array did not offer compile time checked access
to
its contents, something like a.get<1>(), a similar interface like tuple. Otherwise I see not much enhancement compared to an ordinary std::vector.
Wkr, me
boost::array is allocated on the stack like a normal array, while a std::vector needs to use an allocator, usually putting it on the heap.
Also, the normal usage pattern for arrays ( dynamic or otherwise ) is looping through them, the accesses in which cannot be compile-time checked. Note, however, that operator[] does assert that the index is valid--which quickly caught me a bug a little while back.
- Scott McMurray
Yes I can see for myself that there are differences between boost::array and the vector. My point is only that one can add a compile time safe accessor to this array. This does not invalidate the need for a run time accessor like operator[]. Also this would create a big advantage over the vector. This heap and stack allocation stough could just be seen as implementation details.
Fwiw, the tuple interface has been added to std::tr1::array: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf Section 6.2.2.5. -Howard
Howard Hinnant
Fwiw, the tuple interface has been added to std::tr1::array:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
Section 6.2.2.5.
-Howard
Ok that's better.
Howard Hinnant
Fwiw, the tuple interface has been added to std::tr1::array:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
Section 6.2.2.5.
FWIW, that's ultimately the wrong generic interface for access to fixed-length structures. It's okay for array, but for most tuple implementations it generates O(N^2) template instantiations for a traversal of N elements. I hope the Boost Fusion library and related work will give us something better to propose soon. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
gast128 -
Howard Hinnant -
me22