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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-03-24 08:25:45

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.