[Box Backup-dev] Getting trunk ready for release

[Ben Summers]

On 15 Dec 2005, at 17:11, Martin Ebourne wrote:

> Ben Summers <ben at fluffy.co.uk> wrote:
>> Wonderful. So some stupid example in a textbook just to  
>> demonstrate  that operator overloading can be used to do things  
>> other than the  operations that the operators imply (with all the  
>> potential for  confusion, bugs, etc that that entails) is now  
>> going to pollute this  project with it's idiocy?
>
> Ben,
>
> I'm not sure I exactly understand your position on streams. I  
> thought you meant you didn't want operator<< defined on box's own  
> objects, but now it sounds like you don't want << used at all in  
> the code for output.
>
> While I fully agree with you on most operator overloading (I've  
> worked on lots of C++ and seen a lot of evil operator abuse),  
> streams is one of the places where it really is useful. It's not a  
> stupid example in a textbook, it's the way the C++ libraries are  
> designed. Because it is so endemic to C++ and so common the  
> pitfalls are generally avoided. Everyone knows what it does, what  
> it means, and how it works. Those are the main disadvantages of bad  
> operator overloading.
>
> Finding bugs in streams use (related to the operator itself) is  
> extremely rare. About the only mistake is to forget that the  
> precedence of << is higher than of some other operators. In that  
> case it almost always fails to compile so there is no bug anyway.
>
> I don't think anyone is going to ostream box and fill it with uses  
> of << if you say no, but hopefully that isn't the case. Streams is  
> the only viable way of type safe output provided by C++.
>
> The current use of printf is a significant issue. I've ported box  
> to several platforms and making the format string match the  
> arguments is impossible on all platforms due to the different use  
> of types. For that reason we have a load of '#ifdef WIN32' code  
> just to provide alternate format specifiers for windows.
>
> Historically I've also seen more bugs with bad printf use than bad  
> stream use. It's very easy and common to get the format specifier  
> wrong, and almost nobody understands the implicit promotion rules  
> of values passed to a varargs function, which creates quite a few  
> bugs. There's no attempt at type safety with printf so a lot of  
> problems are only run time detectable.

Sorry, I have a cold and am feeling argumentative -- your position is  
the pragmatically correct one. As Chris points out, it's all Mr  
Stroustrup and the STL committees' fault, and too late to change now.

So if it's going to improve the code, then streams will have to go in  
as it would be silly to reinvent the wheel. I'm not quite sure how  
this fits in with the TRACEx() macros though. As they currently  
stand, they don't get compiled in release builds, but other methods  
may not be so easy to deal with.

Ben