Boost logo

Boost :

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-23 18:02:26

----- Original Message -----
From: "Tom Brinkman" <reportbase2007_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, March 23, 2010 10:43 PM
Subject: Re: [boost] 5 Observations - My experience with the boost libraries

>> The prevailing view on projects that I have worked on is that
>> C++ exception handling should optional and not required.
>>> Exceptions are a fact of C++ life. You can't avoid them if for no other
> reason than std::bad_alloc, unless you don't allocate from the free store.
> Not true, there are no-throw versions of std::new.
> In any event, my point is that c++ exception handeling should be optional.
> Boost libraries need to be updated to reflect this.
> One of the first thing that comes up when a mixed language C/C++ project
> uses a C++ library is: Does this library throw exceptions?
> Generally and unfortunately, if the answer is yes, that library will be
> ignored out of hand.

>> 2) Printf versus Iostream. Most developers still prefer "printf" over
>> > "iostream" style "api's". Unfortunately, Boost libraries have long ago
>> > adopted "iostream", as the preferred API style.
>> >> Boost.Format provides what you want. There's relatively little output
>> from the various libraries, so I don't see where this issue arises in real
>> use cases.
> This is a real issue.
> Boost.format is not a replacement for Printf -- they have different
> syntaxes.
> Printf style arguments are the prevailing api style. No one is asking for
> printf style
> arguments to be replaced. Why replace something that is the standard and
> works just fine.

No body forbids you to use printf.

> This is just symptomatic of my larger point that boost is a research project
> and not relevent to day to day C/C++ programmers. Why replace something
> that is universally adopted and works just fine.

Just don't use it if you don't like it.
> If boost developers want to create an alternative to printf, that is fine.
> However, it should be just that, an alternative, not a replacement.

It is not a replacement but an alternative.
> Printf style api's are easy to implement. There are reasons not to do them.

Have you some examples of Boost library API that should provide a printf like function?
>> > 3) Dependencies.
>> >
>> > Everyone has a few favourite boost libraries. Unfortunately,
>> > because of confusing dependencies between them, its practically
>> > impossible to isolate the ones you want from from the ones you
>> > don't.
>> >> >> The dependencies aren't confusing so much as complex. Would you have
>> each library in Boost reinvent rather than reuse other Boost functionality?
>> Isn't that the point of Boost libraries: reuse functionality written by
>> others?
> It can absolutely be an issue if one of the dependent libraries throws
> exceptions for example. Because boost does not have clearly stated policy
> about exceptions, who knows what changes occured between versions.

Could you propose an alternative that solve this issue?
>> > What does this mean?
>> >
>> > Well, it requires the leads of a given project to create a
>> > policy about which
>> > boost libraries are approved and which ones aren't.
>> >
>> > Because of the difficulty of doing this, after a while, its can become
>> > eaiser to just say "screw it". We won't use boost at all.
>> >> I don't see why dependencies among Boost libraries would lead to picking
>> and choosing which are approved.
> This is a key issue. Because boost does not allow you to choose only select
> libraries,
> you must use all of boost.

Ther is bcp.

> And because there are no clear guidlines
> regarding exceptions and policies, it can be scarey to know what exactly is
> going on.

Please make a proposal.
> Project prefer safety to features. If the risks of using boost are unclear
> without is clear policies about exceptions and depencies, its easier to not
> use boost at all so its abandoned in its entirety, no matter how much you
> want to use a specific library.

It is a shame people abandon Boost without trying before to improve it.


Boost list run by bdawes at, gregod at, cpdaniel at, john at