Thorsten Ottosen wrote:

What do tou mean by "it's too late"?

Since the "construction" of boost::array is a no-op, you can just initialize it in the body my_array's contructors.

It is probably a no-op if the array is holding types with trivial constructors. On the other hand an array of std::string will certainly do more than no-op. -- AlisdairM

On 5/25/06, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:

I have been thinking this over all day, and think another class is the most sensible solution - even if it means duplicating the implementation. The extra boolean value in the type is just too ugly! Open to suggestions on a name though, other than array2 or arrayex <g>

Brainstorm: constructible_array static_vector ??? If we look forwards to C++0x and the new initialization syntax Bjarne

proposed in Berlin, I think we can see a way to implement an array template with constructors, as the new sequence constructor should remove the limits of aggregate compatibility from us. The data() member will still allow us to pass the internal array as a POD to C APIs.

Of course, once we allow for an array with constructors, we need to decide which constructors are most appropriate. Eg construction from an iterator range? Construction from a generator function? N copies of a give value?

I personnally want: -default constructor -copy constructor -range constructor -single value constructor (assigns the value to all the elements) -constructor with N parameters (N being the size of the array)

On 5/25/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:

Boost.Array don't have a maintainer. So I think there is an open spot.

-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

If really Nicolai Josuttis is not maintaining this lib anymore... I guess I can continue the work. But Boost.Array didn't change since 2004, is it by lack of maintainer or by lack of change needs? ;-) Anyway, if you people would like to see a constructible_array or fixed_vector or whatever the name of that thing can be, I will do it and update the doc.

On 5/26/06, Paul A Bristow <pbristow@hetp.u-net.com> wrote:

Sounds good to me, though I am not quite happy with the name - a bit long?

Other ideas?

Paul

I agree this is a long name. However, I must admit I don't have any better idea for now... constructible_array fixed_vector static_vector array_wrapper ya_array, array2 or arrayex ;-) The choice for a name is not easy because it is really an array. The only difference with the old one being that it provides constructors... so it is "constructible". Maybe an English speaking contributor will give us a better term. In fact this is one of the reasons I implemented this as a template specialization in my original proposition. However, I guess there is enough smart people here to think about a nice name. other ideas anyone?

On 5/26/06, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:

Actually, I agreed to take on the maintenance around 6 months back <g>

:-) no problem with that, I will help you if you want.

I would certainly look into a parallel class with ctors, or it could be submitted to review separately.

In this case, just call me if you need help again. Vincent

Daniel James wrote:

In that case, I've got a patch for you. The new draft standard adds cbegin(), cend(), crbegin() and crend() member functions, which return const iterators regardless of whether the container is const or not.

The patch is good, but I'm sitting on it for a little while. I will add it to the 'to-do' list. The main issue here is that cbegin et. al. are not part of TR1. and I don't want to mess up the new TR1 implementation going into 1.34. Once that ships, I will take a look at the appropriate config macros to allow const iterator functions in the boost namespace implementation, and add a small set of test cases. So current to-do list: i/ Fix outstanding TR1 issues -> Formal support for Zero size arrays -> Tuple interface ii/ const iterator functions in namespace boost only. iii/ checked iterators in a debug mode. I would be interested in maintainers of other Boost container libraries thoughts on checked iterators. Do we want to agree a Boost-wide interface to enable/disable them? -- AlisdairM