Re: [boost] Re: Technical session at the October C++ meeting?

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-08-20 08:17:48

From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> > But such an animal cannot exist. There is no way
> > to allocate n elements of an array on the stack with n being
> > dynamically determined -- without using VLA's. That is the whole
> > point of VLA's.
> 
> But I said nothing about a stack or absence of compiler support. :-) I said
> 'as efficient as', period. There are several ways to meet this requirement,
> for example having a lightning fast heap, or having a separate stack from
> "the stack," or making std::vector magical.
> 
> In short the goal is a std::vector that doesn't give us any excuses to use
> _alloca, realloc, new[], VLAs, or even scoped_array.

Don't forget get_temporary_buffer. ;-)

I can envision a compiler making the allocation of vector just as fast as other forms of allocation, but what about the initialization semantics?  All elements of a vector need be initialized, whereas those in the other types of allocations do not.  For classes of problems where you need to allocate first and then fill randomly into the buffer, the initialization cost of a vector is a significant overhead, and I don't see how you could get rid of it without changing the interface.  (Of course, one could create lazy constructors and copy constructors for the contained objects, but that would be more horsing around than using, say, a VLA.)