Re: [Boost-users] Library Interface Design

From: Scott Meyers (usenet_at_[hidden])
Date: 2006-09-14 00:06:41

Brian Allison wrote:
>   As for the advice of the designers of an particular API.... it sounds 
> to me as if your description of their API indicates that you don't 
> consider their API very highly. It sounds (again, from your description) 
> to be hard to use, easy to user to create a bunch of badly working 
> objects, and hard to debug. I do hope that you've got an alternative to 
> that kind of suffering. Or perhaps I misread your description?

I find my intuitions and preferences in tension with advice from others 
who I believe are worth listening to.  This suggests that my intuitions 
and preferences need refining or that I've misunderstood or misevaluated 
the advice I find in tension.

I'm suspicious of a design for a EventLog that seems to require a stream 
to be useful, yet still allows a EventLog to be created without one, but 
this seems to be contrary to the advice of a book on how to design an 
application framework from the people who are responsible for designing 
one of the most used APIs in existence (.NET).  I respect the people in 
that position, and for those who care about Amazon ratings, it's been 
well received there 
(http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756/sr=8-1/qid=1158206783/ref=pd_bbs_1/104-6620534-4167149?ie=UTF8&s=books).

I'll note that C++ itself allows "uninitialized" objects with 
constructors to be created all the time:

   std::ofstream ofs;
   std::vector<int>::iterator i;
   std::string s;

In each case, there are a few operations that can legitimately be 
performed on such objects, but many operations lead to UB.  Is this 
fundamentally different from the EventLog example?  For example, replace 
EventLog in my example with ofstream, and you have

   std::ofstream ofs;
   ofs << "Hello World";

Trouble ensues, just as it did in the EventLog example.

Scott