Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-13 02:47:36

Hi Thorsten,

I have attempted to use boost::auto_buffer for monotonic::inline_storage.

If a resize is required and the inline_storage is used by a contiguous
container such as a std::vector, the resize breaks said container.

Just before a resize is required and the inline_storage is used by a node
container such as a std::map, the resize breaks said container (under MSVC
at least) as it thinks it has exhausted all of its memory :(

The code is at
https://svn.boost.org/svn/boost/sandbox/monotonic/libs/monotonic/test/main.cpp.
I have made reference to this in the documentation changes as well.

It would be nice to have the best of both worlds, as people have suggested
previously, but I coulnd't then and I can't now see a way for
inline_storage, which is used by containers, to use auto_buffer for its
allocation buffer.

Perhaps I am missing something?

Has anyone tried to use auto_buffer<> to provide memory for containers?

Regards,
Christian.

On Fri, Jun 12, 2009 at 2:25 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Christopher Jefferson skrev:
>
>>
>> On 11 Jun 2009, at 13:35, Thorsten Ottosen wrote:
>>
>
>  That doesn't do exactly what I want for two reasons, but most might be
>>>>> fixable.
>>>>>
>>>>> 1) I want run-time variable amounts of space (this does involve some
>>>>> alloca, and probably macro, hackery).
>>>>>
>>>>
>
>>>>> For (1) I use a macro something like:
>>>>>
>>>>> #define GET_ALLOCA_MEM(type, x) box<type>(x, alloca(x * sizeof(type))
>>>>>
>>>>> Because obviously you can't call alloca inside the auto_buffer
>>>>> constructor.
>>>>>
>>>> Replying to myself, passing an external buffer into auto_buffer isn't
>>>> completely trivial, because you would also have to disable to copy
>>>> constructor (at least, I can't think of anything else sensible to do).
>>>>
>>>
>>> As far as I know, alloca() is not portable. Am I wrong?
>>>
>>
>> It isn't standard I believe, but it exists on at least Mac OS X, FreeBSD,
>> linux and windows, and software I write uses it successfully on all these
>> platforms.
>>
>>>
>>> You might use variable lenght arrays (C99), but see "Imperfect C++" by
>>> Matthew Wilson on why they suck. His analysis is the reason he implements
>>> stlsoft::auto_buffer instead.
>>>
>>
>> stlsoft::auto_buffer seems to have exactly the same restriction as your
>> auto_buffer, you must declare the amount of space (or at least an upper
>> bound) as a compile-time constant. I haven't got a copy of Imperfect C++,
>> but I have to say my personal experience is alloca and VLA (I experimented
>> with using a VLA of chars instead of alloca, the two are basically
>> implemented the same underneath) work fine.
>>
>
> In his book he describes how differently the VLA implemetations behave, and
> how they have serious problems with recursion. I don't know if
> implementations have improved snice then.
>
> Anyway, I don't see an easy way to get rid of the restruction.
>
> Maybe it is possible to use a custom dummy allocator with auto_buffer.
> Then pass an allocator instance (which has been initialized somehow with
> alloca()) to the constructor of auto_buffer.
>
> Then you can say
>
> boost::alloca_allocator<T> alloc( n, alloca(sizeof(T)*n ) );
> boost::auto_buffer<T,boost::store_n_objects<0>,boost::bounded_grow_policy,boost::alloca_allocator<T>>
> buffer( alloc );
>
> I wish we had template alias :-)
>
> As for disabling the copy-constructor, then it would be nice, but I think
> you can smiply make the allocator non-copyable to do that.
>
>
> -Thorsten
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>