Boost - good or bad?

[IndyStef]

Hi all,

This is an inquiry into the usability of the boost libraries.
We are a C++ shop, and have been using STL for some time now. When the
question about using boost came up, some developers in the team
reported bad past experiences with boost. Namely, the executable size
bloated, the compilation time increased dramatically, and debugging got
more difficult. I would like to find out if those negative effects do
in fact exist.
If you have any experiences with boost, and could tell me about the
possible side effects, please answer to this thread.

Thank you,

Stefan

[Gernot Frisch]

This is an inquiry into the usability of the boost libraries.
We are a C++ shop, and have been using STL for some time now. When
the
question about using boost came up, some developers in the team
reported bad past experiences with boost. Namely, the executable
size
bloated, the compilation time increased dramatically, and debugging
got
more difficult. I would like to find out if those negative effects
do
in fact exist.
If you have any experiences with boost, and could tell me about the
possible side effects, please answer to this thread.

Speaking of boost:spirit (a parser generator).
- code got bigger
- compile time was incredible
- execution speed is awesome
- writing with anything else but spirit would still
keep be busy today.

Resume: Parser = Spirit, period.

[loufoque]

IndyStef wrote:

Namely, the executable size
bloated,

That's the case with any "big" library.
When you add classes and functions, your executable gets bigger.

Moreover, instanciations of templates don't share code, so instanciating
a template for two types gives you twice as much code as instanciating
it for one.
This is, however, the same as if you actually wrote the code twice with
the two different types.

the compilation time increased dramatically,

That's the case with any complex stuff, especially when related to
templates.

There is not much you can do about this. You could use precompiled
headers or try with other possibly faster compilers.
Anyway such problems usually aren't considered very important.

and debugging got
more difficult.

That's the case with any complex stuff, especially when related to
templates.

I think there are some tools which make errors related to templates more
readable.

I would like to find out if those negative effects do
in fact exist.

They exist, but they're not related to boost.
They're related to how C++ works.

[Noah Roberts]

Gernot Frisch wrote:

This is an inquiry into the usability of the boost libraries.
We are a C++ shop, and have been using STL for some time now. When
the
question about using boost came up, some developers in the team
reported bad past experiences with boost. Namely, the executable
size
bloated, the compilation time increased dramatically, and debugging
got
more difficult. I would like to find out if those negative effects
do
in fact exist.
If you have any experiences with boost, and could tell me about the
possible side effects, please answer to this thread.

Speaking of boost:spirit (a parser generator).
- code got bigger
- compile time was incredible
- execution speed is awesome
- writing with anything else but spirit would still
keep be busy today.

Resume: Parser = Spirit, period.

Yes, Spirit is a work of art. I use it for anything that actually has
a correct parser implementation (there is an area where someone came up
with a "file format" but I see no way to write an accurate
parser...only a guesser). On the other hand, the other developers
can't be bothered to learn EBNF so I'm the only one that can work on
that code...I don't expect it to survive long after I'm gone. Sad
really....all the other parsers are written with std::stroke(), are
less reliable, harder to understand, fragile in response to changes in
the format, and full of monolithic functions; whereas the one I wrote
with Spirit for a rather complex file format is small, modularized, and
easy to understand.

[Earl Purple]

loufoque wrote:

and debugging got
more difficult.

That's the case with any complex stuff, especially when related to
templates.

I think there are some tools which make errors related to templates more
readable.

Yes, that is the purpose of static asserts. The error messages find
their way to a line in your own code sooner and the messages are more
related to the actual error.

I would like to find out if those negative effects do
in fact exist.

They exist, but they're not related to boost.
They're related to how C++ works.

They've done a lot of magic with boost but you could say that a lot of
it is workarounds to language features that don't exist directly but
have a solution with the language the way it is now.

In a future version it may well be that some of the boost libraries are
replaced with standard language code that does the same.

[mlimber]

IndyStef wrote:

This is an inquiry into the usability of the boost libraries.
We are a C++ shop, and have been using STL for some time now. When the
question about using boost came up, some developers in the team
reported bad past experiences with boost. Namely, the executable size
bloated, the compilation time increased dramatically, and debugging got
more difficult. I would like to find out if those negative effects do
in fact exist.
If you have any experiences with boost, and could tell me about the
possible side effects, please answer to this thread.

We use portions of boost (mainly the things that are part of TR1, e.g.,
smart pointers) to great effect. Compilation time, debugging, etc. all
depend on *which* parts you are using and how, as well as on your
team's abilities and development tools. I would say that our debugging
time overall has been reduced because smart pointers drastically reduce
the chance for memory leaks.

Cheers! --M

[David Harmon]

On 17 Oct 2006 09:12:45 -0700 in comp.lang.c++, "Noah Roberts"
<ro**********@gmail.comwrote,

>really....all the other parsers are written with std::stroke(), are

What the heck is std::stroke()?

[Paul M. Dubuc]

David Harmon wrote:

On 17 Oct 2006 09:12:45 -0700 in comp.lang.c++, "Noah Roberts"
<ro**********@gmail.comwrote,

>really....all the other parsers are written with std::stroke(), are

What the heck is std::stroke()?

He probably means std::strtok().

--
Paul M. Dubuc

[Kai-Uwe Bux]

David Harmon wrote:

On 17 Oct 2006 09:12:45 -0700 in comp.lang.c++, "Noah Roberts"
<ro**********@gmail.comwrote,

>>really....all the other parsers are written with std::stroke(), are

What the heck is std::stroke()?

My guess would be: misspelling of std::strtok() from <cstring>.
Best

Kai-Uwe Bux

[Jens Müller]

loufoque schrieb:

IndyStef wrote:

>Namely, the executable size
bloated,

That's the case with any "big" library.
When you add classes and functions, your executable gets bigger.

Moreover, instanciations of templates don't share code, so instanciating
a template for two types gives you twice as much code as instanciating
it for one.

"A common concern in template-based programs is code bloat, which
typically results from naive use of templates. Carefully designed
template components need not result in signiï¬cantly larger code size
than their inheritance-based counterparts. The main technique in
controlling the code size is to separate out the functionality that
depends on the template types and the functionality that is independent
of the template types. An example of how to do this can be seen in the
SGI STL implementation of std::list."

(from the BGL book)

[Gernot Frisch]

"Paul M. Dubuc" <pd****@cas.orgschrieb im Newsbeitrag
news:Ck******************@newssvr27.news.prodigy.n et...

David Harmon wrote:

>On 17 Oct 2006 09:12:45 -0700 in comp.lang.c++, "Noah Roberts"
<ro**********@gmail.comwrote,

>>really....all the other parsers are written with std::stroke(),
are

What the heck is std::stroke()?

He probably means std::strtok().

strtok is the worst! It's even better to write a splitter function
that returns a vector of strings, since strtok cannot be used nested.

[Michiel.Salters]

IndyStef wrote:

We are a C++ shop, and have been using STL for some time now. When the
question about using boost came up, some developers in the team
reported bad past experiences with boost. Namely, the executable size
bloated, the compilation time increased dramatically, and debugging got
more difficult.

This can be a good or bad sign. It's rather obvious why it can be a bad
sign.
It is a good sign, though, when these things happens as a result of
quickly
adding functionality. Your executable will also grow if you write all
the useful
Boost stuff yourself. However, since it will take a year, that growth
often won't
be noticed. The compilation time will increase if you write stuff
yourselves, for
the same reasons. The debugging effect is similar, but not entirely the
same.
If you write the stuff yourselves, instead of using boost, you'll spend
less time
understanding boost, but more on debugging the code you wrote instead.

So, with boost, the changes that will happen to a succesfull
application will
just happen faster.

Michiel.

[Noah Roberts]

Gernot Frisch wrote:

"Paul M. Dubuc" <pd****@cas.orgschrieb im Newsbeitrag
news:Ck******************@newssvr27.news.prodigy.n et...

David Harmon wrote:

On 17 Oct 2006 09:12:45 -0700 in comp.lang.c++, "Noah Roberts"
<ro**********@gmail.comwrote,
really....all the other parsers are written with std::stroke(),
are

What the heck is std::stroke()?

He probably means std::strtok().

strtok is the worst! It's even better to write a splitter function
that returns a vector of strings, since strtok cannot be used nested.

Hense the new name. I think it reflects its true purpose better.

[Jens Theisen]

Jens Müller <us************@tessarakt.dewrites:

"A common concern in template-based programs is code bloat, which
typically results from naive use of templates. Carefully designed
template components need not result in signiï¬cantly larger code size
than their inheritance-based counterparts. The main technique in
controlling the code size is to separate out the functionality that
depends on the template types and the functionality that is independent
of the template types. An example of how to do this can be seen in the
SGI STL implementation of std::list."

(from the BGL book)

I don't find this very convincing. I only have experience with g++ as
a platform, and there code bloat is a problem. My suspicion is that
other platforms have similar problems, though I'd like to hear from
people who know.

Template symbols are generally emmitted into any translation
unit. They are melted together during link time, but in the presence
of shared objects, you still get lots of duplicates accross those.

This would not happen if you craft the corresponding functions/classes
yourself, as you would emit their definitions into specific
compilation units.

In a debug build, you also get duplicated debugging information for
all of those. This can easily lead to ridiculous binary size such as
gigabytes for large project. Sometimes you want your production code
to be debuggable, then it is very sad you get such an excessive
overhead.

Maybe there are platforms that get around this.

--
Cheers, Jens

[loufoque]

Jens Theisen wrote:

Template symbols are generally emmitted into any translation
unit. They are melted together during link time, but in the presence
of shared objects, you still get lots of duplicates accross those.

Standard C++ doesn't know what shared libraries are.
Henceforth, it lacks the appropriate tools to handle such cases.