Re: Which libraries in Boost are mature enough to be used in real applications?
Noah Roberts wrote:
You appear to be confusing visibility to the programmer with visibility
to the code. There is nothing about templates that break
encapsulation. The only qualm I have is compile time
dependencies...that's annoying but still doesn't break encapsulation
and there are ways to minimize it.
Actually there are encapsulation issues with templates. Even with
std::string. Let's see some issues:
- I cannot safely pass a std::string across libraries.
- Including string will usually pull in some stream functions even
though I don't intend to use them.
- Because string is a template class, I can't forwardly declare it. I
can't put in my header any of these:
class std::string;
namespace std { class string; }
typename doesn't work either, of course. It's not standard here. Whilst
you can forwardly declare it, doing so is complex. Even if my header
only uses const std::string & I can't forwardly declare it. Ok so you
get away wtih "but string is so standard that everything should know it
anyway" but it still breaks encapsulation.
You get a similar problem with shared_ptr, although here it obviously
does need to be a template. But you have to include its header, plus
all the other headers it uses in its implementation.
If you ever want to change from boost::shared_ptr to tr1::shared_ptr
(and eventually to std::shared_ptr?), how many changes will that
entail? How much will need to be recompiled (even if there's just one
code change)? All your source, I would imagine.
I, by the way, have 2 separate abstract interfaces and one that
multiply inherits from them that are implemented with std::map. One is
for writing, one for lookup. So I have been able to abstract away
(encapsulate) map from my client code.