Roland said:
A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users? Superior
in exploiting the most complex template meta-programming techniques?
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming. The (implicit) Boost motto is
"Look what we can do with templates!". The criteria for real-world
libraries and applications point in the opposite direction. For the
latter the goal is to provide large functionality with small,
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.
I live in the real-world, developing software for real people. Up to
date I've found boosts interface ("if you use documentation") very
clean. If you need to write software to meet all needs, complexity is
often necessary. As long as it is not complex to use, and most often it
is not.
I've been able to use the following classes in the boost lib
successfully without any trouble whatsoever.
All the smart pointers (shared, weak, scoped and their array variants).
I find the array variants necessary and superior to vector in some
situations. The reason for this is that is slotted in with certain code
with less change. vector required interface changes whilst I could
manage resources at scope level without interface changes.
Amongst others I've seen handy uses for optional, type_traits, ref,
utils - especially base-from-member, array and others. The only reason
why I haven't used it even more often, is that I've only started using
it recently. Also, having implemented libs that others used, I come to
realise that having the convenience of templates, and especially
specialisation some things would be far more difficult to implement
(generically) without templates - even impossible. The combination of
run-time and compile-time polymorphism is very powerful. This said, as
long as the code is well tested and reviewed (which I'm currently
assuming is the case with boost). I, BTW, have made mistakes in the
past - like uninitialised vars, that boost has help me find with their
defensive style of programming.
Sad that following how they implement their magic is quite hard due to
yes, complexity. But complexity in implementation is orthogonal to
complexity in interface. The former being necessary in some
circumstances, the latter preferably as simple as possible - that said,
the latter should only be simple enough of domain users to understand.
If I write a lib for use by mathematicians, I can't expect chemists to
know how to use it, as they are not necessarily familiar with the
domain concepts.
Regards,
Werner