[boost] Re: Design discussion: easy i/o

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-07 11:13:40

> -----Original Message-----
> From: Dave Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Monday, March 06, 2000 5:58 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Design discussion: easy i/o
> 
> 
> on 3/6/00 10:13 AM, Mark Borgerding at mborgerding_at_[hidden] wrote:
> 
> 
> >> boost::format( "%1 chickens can be found in coop number %2")
> >> % chicken_cnt % coop_num;
> > 
> > This is safer than a printf, but could still be prone to an 
> error with
> > unintended formatting tags in the format string.  It does not employ
> > compile-time checking.
> 
> Sure it does. It employs compile-time _type_ checking. And 
> unlike printf, it
> is able to check the number of arguments used at runtime. I 
> think this is a
> good compromise.
> 

It cannot catch an invalid format string at compile time.  The main
advantage is that it can fail gracefully at run time rather than make an
access violation.  I'd prefer to have it fail gracefully at compile time.

> >> std::cout << x, y, z;
> > 
> > Well you can do
> > std::cout << (x, y, z);
> > But I don't think the results are what you would want. (It will
> > evaluate the expressions in left-to-right order and return z.
> 
> I realize that. Actually, that's what I would expect. 
> Parentheses induce
> strong visual grouping when I look at them. Anyway, I wasn't seriously
> proposing *exactly* that syntax. We'd have to do something more like
> 
> boost::print(std::cout) << x, y, z;
> 
> > I played around with overloading the comma operator. The 
> results were
> > pretty disasterous.  Way, way too error prone.  Throw a couple of
> > parens into the mix and the behavior is completely 
> different from what
> > you intended.  The worst part is the silence with which it compiles.
> > In this respect, it is no better than printf.
> 
> I disagree. Printf silently compiles things which crash. As 
> far as I can
> tell, the parens do exactly what I would expect them to. BTW, comma
> overloading is successfully used by the blitz++ numerics 
> library; I don't
> see why it should be feared.

A misuse of the comma operator will silently compile things which do
nothing.  This can be almost as bad as crashing.

Using commas is more error prone than other operators, because a comma can
separate anything.  The elements between the commans don't even need to be
the same type for it to compile.  For example, the << operator cannot be
applied to an object which does not have the operation defined.  A comma
operator simply causes things to be evaluated.  It can be applied anywhere,
whether intended or not.

I ran into some potentially serious problems when I tried to use it to
create a contained-within operator class.
I wanted to be able to say something like

if ( is_in_set(name) == "Larry" , "Curly" , "Moe" )
        cout << "stooge";

Where is_in_set created a temporary which overloaded the comma operator.

The problem I foresaw was that there could be a tendency to put parens
around the set, causing only the last element of the set to be used.  
if ( is_in_set(name) == ( "Larry", "Curly", "Moe" ) )
        cout << "stooge";

The worst part was that this would be compiled silently, and the error might
go unnoticed in code reviews.

Perhaps there are appropriate times for the comma operator.  I was soured on
the idea after the above experience.  I have not personally found a
situation where the benefits outweighed the risk.

I just looked at blitz++ and I think it might be prone (albeit less so) to
the type of error I describe above.
As I see it, the blitz++ usage is like this

Vector<int> myInts;
myInts = 1,2,3,4,5; 
// All ints are added into vector
// operator = returns a ListInitializationSwitch<Vector<int> >, which
overloads comma op

Which is completely different from 
myInts = (1,2,3,4,5);// only 5 is added to vector

I agree that the usage of the comma operator is more aesthetically pleasing
than using push_backs.  However, I feel this conciseness is not worth the
possibility of misuse.

When designing a class or framework that others will be using, I prefer to
make an interface goof-proof rather than aesthetically pleasing.  

Does anyone else have a strong opinion about commas?