Re: [boost] 5 Observations - My experience with the boost libraries

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.

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

Best,
Vicente