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