Subject: Re: [boost] Abstract STL Container Adaptors
From: Andy Jost (Andrew.Jost_at_[hidden])
Date: 2013-03-14 17:10:39
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Nevin Liber
>> On 14 March 2013 12:20, Andy Jost <Andrew.Jost_at_[hidden]> wrote:
>> In some cases, particularly when compile times are more critical than
>> execution times, it would be preferable to let the caller choose the
>> set implementation without losing the advantages of separate compilation.
> Do you have any benchmarks to show this isn't in the noise?
What isn't in the noise? Compile times?
>> It seems the implementation of this would be a straightforward
>> application of type erasure. It seems too easy, in fact, which makes
>> me wonder whether I'm missing something.
>*Every* operation becomes slow. Algorithms become really slow, if callable at all.
I don't see how this is justified. The virtual call certainly adds overhead, but compared to a normal inlined function it's not a huge amount. Algorithms should become slower by a small constant factor.
> For instance, if you had a "wrapper" that models a sequence >container, what iterator category do you pick for it?
The iterator category would exactly match that of the underlying container. The goal is *not* to abstract away the differences between different containers; it is to abstract away the differences between different implementations of the same container. So std::std and tr1::unordered_set and std::set<...,MyAllocator> can be used interchangeably, but not std::set and std::vector.
>> In any case, is this a good idea?
> I can't think of a case I've ever had for choosing the container at run time.
That's not the point. The aim is to compile the algorithm only once. As a real-world example (not to far from my scenario) say your project takes five minutes on 20 CPUs to compile, and the algorithm in question consumes less than 0.0001% of the overall execution time. Wouldn't you take a 10x hit in algorithm performance to improve the compile time?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk