Re: [boost] Shared Map

From: Lassi Tuura (lassi.tuura_at_[hidden])
Date: 2007-08-12 13:31:25

Hi,

>>> Libraries that produce needless copies are simply ill-designed,  
>>> and thus it is true great parts of the standard library are),
>>
>> [...] I'd say there's something a bit more fundamental going on  
>> here than _just_ a library design issue :-)  No class can be all  
>> things to all users.
>
> This isn't even a design issue. Your standard library is just being  
> stupid (or overly pedantic) in its handling of operator==(string  
> const&, char const*). Let them know how you feel.

Sure, that's certainly a very important factor.  But I was going in a  
bit different direction.

I'm of course delighted when people have sat down and produced an  
elegant and robust class design.  I've had the pleasure to use a  
number of libraries with an excellent design.  But each library has a  
purpose and it may differ from that of the developer.  Of the  
libraries I have come across, the ones that tried to cover the whims  
of every turkey that walked by often had the most incomprehensible  
and bug-ridden interfaces and implementations.  It's healthy when  
developers know the purpose of their classes and know when to resist  
requests for significant deviations.  No class can nor needs to be  
all things to all users.

In a way of an example, I happen to find std::string a decent general  
string class.  It has some odd behaviours and maybe flaws, but  
overall it does a fine job and life is too short to sweat every  
detail.  If I have a huge pool of arbitrary-size read-only strings  
that I want to treat as highly efficient interned atom database, is  
std::string a good choice?  Nah.  If 75% of my strings are  
dynamically built but read-only after creation, and I want to pass  
them a lot between threads, is std::string optimal?  Naah.  If I need  
to efficiently shuffle a lot of string data over networks, is  
std::string optimal?  Nope.  But to pursue any of these into  
std::string interface?  Surely madness lies that way?  How about a  
very general string-like concept which would be able to cover all  
these bases with suitably clever parametrisation?  Why, when each can  
be satisfied by 50-500 lines of very straightforward code every  
dabbling developer will understand in hours?

On the other hand, there _are_ areas where suitable abstraction pays  
off _big_ time.

Lassi

PS. In my earlier example the best choice would have been to drop  
strings altogether.