Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: joaquin_at_[hidden]
Date: 2009-06-09 09:02:11

Christian Schladetsch escribió:
> Hi Joaquín,
>
> I concur. Also, replicating container classes for the sake of avoiding this
>   
>> little
>> boilerplate code is a maintenance bottleneck.
>>     
>
>
> STL isn't rapidly changed. I agree that my proposal is not complete with all
> forwarding construction parameters. But they are readily added if the
> underlying idea is accepted.
>   

I'm not saying the task is difficult (in fact it's trivial), but the 
idea of wrapping every container
in sight is (IMHO) a flawed one because:

* Not only will you want to wrap containers in the STL but also those in 
Boost, which
can be found in (off the top of my head), Boost.PtrContainer, 
Boost.MultiIndex, Boost.Intrusive,
Boost.Interprocess, Boost.MultiArray, Boost.Unordered. I'm sure I'm 
missing some, we are talking
about dozens of containers. And you'll have to keep track of new additions.
* At a more fundamental level, you're turning a constant-complexity task 
into a
linear-complexity task: if you leave it at the allocator level, your 
job's finished as soon
as you wrote the allocator. With your approach, you are coupling with 
developments on
the container arena, forcing yourself to track this indefinitely. That 
is the beauty, for instance,
of the iterator concept: By decoupling containers from algorithms via 
iterators, you
move from N*M possible combinations (N algorithms, M containers) to a M+N
scenario. Allocators (ill-designed as they admittedly are) decouple one 
aspect,
namely memory management, from the rest of aspects contributing to a 
container
implementation. One last illustration of the point: say another author 
wrote wrapped
containers simplifying the use of a template parameter other than the 
allocator, for instance:

  template<typename T,typename Allocator>
  struct greater_set:std::set<T,greater<T>,Allocator>
  {
    ...
  };

Now, how do you combine greater_set and mononotic::set?

> People will expect that a monotonic::foo<..> is like a foo<..>, and they
> will accept that it requires a storage argument. But they will find it
> harder to accept that it requires retooling from a type-argument level of
> the allocator.
>   

I can't say what people will expect, but I do know allocators are meant 
to be used
and that's why they're part of the template argument interface. That's 
not "retooling".

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo