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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-24 09:58:27

>>> Regarding Exception Handeling.
>>>.  Is it a big deal that "hard core" C++ libraries aren't acceptable to C programmers?

Its a pretty big deal to some developers.  To some, its the first
thing the look for when they consider a C++ library.

In my view, its not that big of a deal.  Just wrap the damn call into
a try-catch block, be done with it.

The issue has more to do with considering the needs of preferences of
the prevailing style of development of those developers that are more
"C" orientated.

Of course, Boost is a C++ library, and boost developers should
consider the needs of C++ developers first when they develop their
api's.

Of course, I'm not suggesting boost converts to be a "C" library.

But what I am trying to say, albeit not very well, is that boost and
C++ in general should try be a little more "C" friendly.  (When I say
boost, what I really mean is boost/C++).

In my view, for the most part, its rather simple to make C++ code,
"somewhat" C friendly.  (I'll try to detail some ways that C++
developers can do this in a latter post).

The easy one is "printf", which we endlessly discussed.

Yes, printf style API's have issues, although GCC and ICC, have
practically eliminated  most of the worst of them.   Not sure about
other compilers.

Sure printf has warts, however, for the most they are considered to be
good enough.  Iostream also warts, but for the most part it is good
enough.

Thats not really my point.

Its more that it would go along way towards lessening the animosity
that "C" developers have towards "C++" if at least some small effort
was made.

Supporting at least of some of the eaiser to implement "C" friendly
style API's, such as printf, would make it seem like at least your
trying and then maybe, just maybe, I could generate some support on my
teams for using those boost C++ libraries again.

A small effort would go along way.

On Wed, Mar 24, 2010 at 5:25 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Tom Brinkman wrote:
>>
>> > 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.
>
> My point was that it is very hard to avoid exceptions in C++.  Two-phase construction is untenable for the same reasons that C APIs are a pain to use: you have to remember to check the error state(s).  Without two-phase construction, you have to decrease performance by checking object validity in every member function or else throw an exception to indicate improper construction.  Exceptions look pretty good in that light.
>
>> In any event, my point is that c++ exception handeling should
>> be optional.  Boost libraries need to be updated to reflect this.
>
> I already agreed that more could be done in that direction and suggested that you should try to push those ideas into the existing and future libraries.
>
>> 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.
>
> Is it a big deal that "hard core" C++ libraries aren't acceptable to C programmers?
>
>> > >> 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.
>
> Which Boost library produces output using IOStreams that is causing the problem?
>
>> Boost.format is not a replacement for Printf -- they have different
>> syntaxes.
>
> The syntax is quite similar.  My goodness, cannot C programmers acknowledge the benefits of type safety and extensibility to learn a slightly different syntax?
>
>> Printf style arguments are the prevailing api style.   No one
>> is asking for printf style arguments to be replaced.
>
> Untrue.  Many dislike printf()-style I/O because of the lack of safety and extensibility.
>
>>  Why replace something that is the standard and works just fine.
>
> It doesn't work "just fine."  There are many problems with printf().  Here's a question: how much of that wonderful code that uses printf() actually checks the return code and handles the errors reported by 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.
>
> This is just flat wrong.  Boost is relevant to a very large number of "day to day" C++ programmers.  I really don't care much about C programmers and I don't think Boost should either.  I don't mean to suggest that we should be antagonistic towards their needs.  After all, making a C programmer happy, without making a C++ programmer unhappy, implies a straightforward, simplistic API.  Those are easy to understand.  However, when doing so is unduly inefficient or unsafe, then the C++ programmer wants more and the C programmer will probably be unhappy.
>
>> If boost developers want to create an alternative to printf,
>> that is fine.  However, it should be just that, an alternative,
>> not a replacement.
>
> Boost has alternatives that satisfy -- to some degree, anyway -- the concerns of C++ programmers.  Since printf() is not "just fine," this is a good thing.  Since printf() has problems, why should Boost, a group that seeks to advance C++ -- not C -- persist in using an I/O mechanism that has problems?  The alternatives may not be perfect, but they are attempts to correct the problems of printf().
>
>> Printf style api's are easy to implement.  There are reasons
>> not to do them.
>
> I'm glad you recognize that there are reasons to avoid them.  (You probably meant to write "there are no reasons not to do them," but I couldn't help myself.)  Clearly we have a problem.  You haven't identified any concrete examples where a printf()-style interface is lacking and I don't accept your generalization that printf() is clearly superior to the C++ alternatives.
>
>> > > 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.
>
> Boost doesn't have a clearly stated policy about exceptions which means, given that they are C++ libraries, exceptions are allowed at the library author's discretion.  There are many satisfied with exceptions in C++ libraries.  Obviously, you and those around you aren't.  That hardly generalizes to the majority.
>
>> > > 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.
>
> You haven't addressed my earlier question: why shouldn't Boost libraries reuse others?  If those dependencies aren't managed as nicely as they otherwise could be, make concrete suggestions.  However, asking Boost libraries to be independent of all the rest is a ridiculous imposition.
>
>> 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.
>
> Projects have different needs.  Many projects expect and program for exceptions.  Such projects will have no problem with this "scary" and "unspecified" aspect of Boost.
>
> Even combined C/C++ projects can wrap useful Boost functionality into a C API or use Boost in the C++ layers, catch and translate all exceptions into error codes, and provide something useful for the C programmers.  This is hardly news to most working with both languages.
>
> It seems that you want Boost to cater to C programmers' needs, which is antithetical to Boost's purpose.  It is reasonable to ask for specific changes to make throwing exceptions optional, but I don't find anything else concrete in what you're complaining about.
>
> _____
> Rob Stewart                           robert.stewart_at_[hidden]
> Software Engineer, Core Software      using std::disclaimer;
> Susquehanna International Group, LLP  http://www.sig.com
>
> IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>