Which libraries in Boost are mature enough to be used in real applications?

[werasm]

Templates provide no separation between interface and implementation.
The template interface is the template implementation (and vice
versa). A template-only (almost) library cannot hide the "complexity
in implementation". This is an insurmountable problem for all template
libraries, not only Boost.

I don't entirely agree with this. Whilst templates don't promote
compilation dependency, interface is not determined by compilation
dependency, but by what is publicly usable. True that there is no
physical seperation between interface and implementation (but interface
still exists and is concise). Apart from that, seperation can often be
established by using combination of dynamic and static polymorpishm.
The command pattern and Alexandrescu's functors are example of this.

Furthemore, most of the idioms implemented in boost are so well
established, with narrow concise interfaces that never change (e.g.
they promote single responsibility), therefore the strong dependency is
irrelevant, this being the case for the STL as well. If an interface is
cast in concrete, it no longer requires to be seperated from
implementation. Many idioms in boost are so narrow that they are cast
in concrete.

Kind regards,

Werner

 

[werasm]

Is Boost a meritocracy?

If I were a bum with no credentials, and I write a better library than a
current Boost library, could I submit it? Would it replace the current
version?

If it would pass the peer reviews, I think you might stand a chance.

Some bums become that because the current world they live in are too
shortcited to perceive their intelligence. Their work are sometimes
acknowledged by following generations. Other bums are simply lazy, and
others are depressed.

If you are the first kind, then some boosters may just acknowledge
that. I don't think all boosters have credentials. I may be wrong but
that is the impression I get (POP).

(Note that several Boost libraries have been replaced, and several have
alternate implementations...)

Yes, inhouse libs too, STD too, MS libs too. Java libs and C# libs too
(deprecated). Sadly, less C libs - or maybe I'm lacking experience
their, because their are alternatives for me.

Retrospect is a wonderful thing. Why did they not just start out with
the ideal lib/language . Why was assembler ever required, and C, and
C++, and all those languages that have not yet been borne from
retrospect.

BTW. I hope the boosters are less short cited than to consider
credentials. Original creativity and genius does not necessarily sprout
from credentials, but I gather you know this already.

Kind regards,

W

 

[Mirek Fidler]

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.

Well, I think you have not understood my post. Your posts in this area
seem to "disagree", but not to show any alternative...

The (implicit) Boost motto is
"Look what we can do with templates!".

Well, I would rather say "Look how we can enhance STL"

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.

This will just bring a dozens of posts about usability of Boost in real
world applications (and how smart pointers allow you to store stuff in
containers

Mirek

 

[Mirek Fidler]

possible cases, it is a good design. If an implementation results in

Maybe you should stop using the C++ standard library then.

Actually, a very good idea

Boost takes what already exists in the standard library and extends it
or improve it.

Yes, that is the problem....

Mirek

 

[Roland Pibinger]

Well, I think you have not understood my post. Your posts in this area
seem to "disagree", but not to show any alternative...

Probably I still don't understand your question. You mean heavy
templatezation and template meta-programming combined with creative
operator overloading is the only way to design C++ libraries? I beg to
differ. If you want names of C++ libraries targeted at the real world
programmers then you must first take a look at commercial offerings.
I've worked with libraries from Rogue Wave in the late nineties (then
known as Tools.h and DbTools.h) and found them convenient and well
designed. Probably also the libraries from Qt fall into the same
category (albeit I havn't used them). If you search the internet (or
eg. www.koders.com) you find many (parts of) fundation libraries,
mostly as part of some project or as one-man show.

Best regards,
Roland Pibinger

 

[Mirek Fidler]

Probably I still don't understand your question

That was not question, but a hint...

> differ. If you want names of C++ libraries targeted at the real world
> programmers then you must first take a look at commercial offerings.
> I've worked with libraries from Rogue Wave in the late nineties (then
> known as Tools.h and DbTools.h) and found them convenient and well
> designed.

Actually, this is what I was suggesting... To show some alternative...
Or at least to point to unnecessary problems associated with STL which
most C++ gurus seems to silently ignore (like the copying obsession

Probably also the libraries from Qt fall into the same
category (albeit I havn't used them).

Yes, actually, it is quite funny that in 4.x version they completely
abandoned STL iterator syntax

> If you search the internet (or
eg. www.koders.com) you find many (parts of) fundation libraries,
mostly as part of some project or as one-man show.

A good hint. We have not posted to www.koders.com yet

Mirek

 

[loufoque]

Mirek Fidler wrote :

This will just bring a dozens of posts about usability of Boost in real
world applications (and how smart pointers allow you to store stuff in
containers

It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

The biggest use of pointers is for polymorphism, and for that you have
auto_ptr.
Unfortunetely, you can't have a container of auto_ptrs as the STL uses
copying to move stuff (that will be fixed in C++0x hopefully), and while
it would be trivial to move an auto_ptr it can't be copied.
For that you can indeed use a container of shared_ptr, but there are
better alternatives, like the pointer containers in boost.

shared_ptr is actually meant to be used when the object can be owned by
multiple objects at the same time.
If you just need to store pointers in a container, using shared_ptr
doesn't seem to be a good idea to me.

 

[Alex Buell]

Probably also the libraries from Qt fall into the same
category (albeit I havn't used them).

I wouldn't bother using QT C++ libs, they abuse the C++ language to
get what they want. They have this preprocessor, called moc, FFS.

Gtkmm is /much/ better and is very much like STL i.e. uses things like
iterators etc.

 

[werasm]

Mirek Fidler wrote :


It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

I've seen examples where things without the use of smart pointers get
very difficult. Smart pointers are especially handy when binding
clients to servers polymorphically, when the clients lifetime has the
potential to surpass that of the server by small periods of time. Often
this sort of thing takes tedious programming to prevent. Making use of
smart pointers this becomes trivial.

Another almost impossible example that I can make mention of, is the
passing of pointers over queues for execution of RPC's in another
thread/task/context. When the RPC/aka. command is executed in the
context of arrival, the server of the command (of course a pointer) may
not be available anymore (no possibility of removing it from the queue
- FIFO), using a weak_ptr in this case is ideal, as it becomes invalid
when it's source is destroyed. Using a raw pointer on the other hand,
well... impossible. Using a reference, also not possible because who's
the say the sender context stack is still around.

Your rarely may sprout from lack of experience.

Regards,

W

 

[Mirek Fidler]

Mirek Fidler wrote :



It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

The biggest use of pointers is for polymorphism, and for that you have
auto_ptr.
Unfortunetely, you can't have a container of auto_ptrs as the STL uses
copying to move stuff (that will be fixed in C++0x hopefully), and while

Yes, exactly. Right to the spot!

See:

http://upp.sourceforge.net/srcdoc$Core$NTL$en-us.html

BTW, fix in C++ 0x will not solve that completely, it will just
suplement copying with moving, but there will still be a lot to be desired.

shared_ptr is actually meant to be used when the object can be owned by
multiple objects at the same time.

Which is quite stupid idea anyway. Shared ownership always leads to hard
to maintain code and is quite easily avoidable (in C++, I mean).

If you just need to store pointers in a container, using shared_ptr
doesn't seem to be a good idea to me.

Agree.

Mirek

 

[Earl Purple]

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 disagree with you on the whole but agree with you in part,
particularly with regard to bind and lambdas .I think this was an
attempt to improve on the STL binders, but then I generally don't use
those either. Why? Because they make the code unreadable. And with
boost it introduces these funny _1 and _2 symbols, which I'm not even
sure are thread-safe (they are globals aren't they?). Wouldn't be easy
to debug into and if you dare to get the syntax slightly wrong, you'll
have your work cut-out interpreting the error messages.

Plus there is are two simple alternatives. One is to write a simple
functor - that's all the bind templates are anyway, but at least with
your own it will be comprehensible if you debug into it. The other is
(shock horror) to use a loop. But sometimes, when the algorithms don't
quite do what you want them to do, it's easier to implement a loop than
to start working out how to make them fit anyway. (At one point I was
writing my own algorithms and ended up with an enormous number of these
- later I decided loops were often a simpler solution).

 

[Noah Roberts]

Templates provide no separation between interface and implementation.
The template interface is the template implementation (and vice
versa). A template-only (almost) library cannot hide the "complexity
in implementation". This is an insurmountable problem for all template
libraries, not only Boost.

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.

 

[Earl Purple]

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.

 

[Noah Roberts]

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.
Huh?

- Including string will usually pull in some stream functions even
though I don't intend to use them.

Yes, including the definition of a class often includes things you
don't intend to use.

- Because string is a template class, I can't forwardly declare it. I
can't put in my header any of these:

None of these issues has anything to do with encapsulation.

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.

Yes, I mentioned the problem of compile time dependencies. This still
doesn't break encapsulation. You can make very similar arguments you
have about regular classes:

class X { Y private_y; }; // Now you also have to include the
definition of Y even though Y is only used privately by X.

I'll grant you that compile time depenencies to internal data between
classes that don't know about each other's insides is a language
weakness, and that weakness is worse in templates by their nature of
having everything they do in a header file that is included where it is
used. But again, as with classes this does not break encapsulation and
there are ways to minimize both.

Encapsulation, or information hiding more accurately, is about hiding
design decisions from the rest of your code. Altering the internals of
one class should not cause another to need to change. This doesn't
mean you won't have to recompile as the clients now have to access
something that is different (that is a language weakness) but you won't
have to edit them to account for changes. Only when the interface is
altered do you have to do this. You guys are confusing compile time
dependencies and programmer visibility with information hiding.

 

[Earl Purple]

class X { Y private_y; }; // Now you also have to include the
definition of Y even though Y is only used privately by X.

And that does break "encapsulation" if that is defined as hiding the
implementation from the user. Using a pointer to Y (scoped_ptr if you
prefer) you can forwardly declare the Y and that hides the
implementation detail better. Particularly if there is only one such
pointer (a pointer to the implementation).

You can always say "this is a black box, don't look inside" and
generally we do adopt that approach when using, for example,
std::string and std::vector. That is fine on the whole.

But as I mentioned, std::string is not portable across libraries. And I
will explain what I mean.

I have, say, a library that I have written and compiled using GCC
compiler 3.2.1 that sits on the system and has an interface that takes,
for example, a const std::string & or even worse, a function that
returns a std::string.

Your application is being compiled with Solaris Forte 8 compiler with
Roguewave STL and tries to interact with my library. Although we are
both using a standard string class with the same interface, they are
possibly implemented differently and when you pass yours by reference
to mine, it may compile fine but may seg-fault when run.