Boost logo

Boost :

Subject: Re: [boost] Proposal: Monotonic Containers
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-06-10 17:37:44

Christian Schladetsch skrev:
> Hi Peter,
> I much prefer using a standard template library container to any other, even
>> if it's the same thing but different. I would therefore much prefer the
>> std::map<int, float, std::less<int>, ...> approach to creating another
>> container; especially as this one can also take a different comparison
>> operator.
> Yes, but what about
> boost::monotonic::inline_storage<N> storage;
> std::map<int, float, std::less<int>, boost::monotonic::allocator<int> >
> v(boost::monotonic::allocator<int>(storage));
> versus:
> boost::monotonic::inline_storage<N> storage;
> boost::monotonic::map<int, float> v(storage);
> My rationale is that when I want a vector with a different allocation
>> scheme, I like to say "vector with a different allocation scheme" rather
>> than "differently-allocated not-quite-a-std::vector".
> I grok that; but boost::monotonic::container also is-a std::container with
> guranteed no extra junk. They are absolutely %100 type-compatible after
> creation.

I think it is slightly wrong of you to put so much emphaisis on
syntactical convinience. In general, such is nice, but your library
should offer some more real value. Especially since most containers end
up being typedefs so you can easily switch to another, and so nested
types are easy to type, and so that you can give better fitting names to
your types for a given task.

Locality of reference seems like an important problem to improve. I
don't agree with those that say high-performance applications usually
involves a single container; mine certainly doesn't.

Intrusive containers seems to give similar benefits w.r.t. locality of
reference. Similar for flat_set/flat_map.

It is not clear to me in which niche your library would fit. I hope you
can make that clear, and provide examples that show your library
performs better than otherwise.


Boost list run by bdawes at, gregod at, cpdaniel at, john at