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.