> Looks problem number 2 has another bug: the hard-coded 256
> and 288 values should be 255 and 287 respectively (except
> when used as width and height). It looks to me like the
> program will be trying to write off the screen on the
> right and bottom by a pixel.

Good point -- this may indeed be a source of confusion. However, the convention used here is the usual C/C++ one of one-past-the-end values. That is to say, a Rectangle empty(0, 0, 0, 0); contains zero pixels and Rectangle tiny(0, 0, 1, 1); contains just one pixel.

> I've always liked the idea of passing a structure when
> many parameters are required, because in addition to
> reducing the odds of mistakes when it is written, it also
> produces self-documenting code. The boost named
> parameters stuff is also cool.

It's certainly cool. I haven't tried it in anger, so I can't give it an unreserved recommendation. There was some interesting discussion on the Boost reflector when it faced the Boost peer review process.

> There are other points of weakness in the C/C++ type
> system. Enumerated values and booleans get mistaken for
> integral types all too easily. And what's worse, in a
> mixed language system, such as the one deployed on the
> Talk-To-Me, they can change size and alignment when
> passing from C to C++.
> Why do people still do this? What is the value? Are
> there really still some places where you have have a C
> compiler, but no C++ compiler? Maybe that is the case
> with this Talk-To-Me gadget?

Sometimes third party libraries come pre-built. Sometimes they're delivered as source, but with a fiddly build system which is hard-wired to C. And sometimes they don't get through a C++ compiler.

I very much take your point here though: stick to a C++ compiler and avoid this problem.

> Um, am I missing something obvious? It seems to me that
> problem 1 was extremely contrived. If the check had been
> implemented correctly and more clearly in the first place,
> none of this trouble would arise:
>
>

bool signalsDifferent(Signal s1, Signal s2, int
> tol)
> {
>    return abs( s1 - s2 ) > tol;
> }
> 

You're right, we should use the standard library as far as possible. I can assure you, though, that the example is not contrived. You really will find code like the code I presented in the article without having to look too hard.

> Or was this the usual C++ coding gaffe of trying to save a
> couple of nanoseconds by not calling abs()?

> The top-left/bottom-right combination is only 'the most
> sensible' because of what you've been used to. If you were
> a native speaker/reader/writer of other languages, such as
> Hebrew, Chinese or Arabic, you might have a different idea
> of what is sensible.

Right. And as stated in the article, we're in a situtation where there's no single established convention.

> Of course, it probably makes sense to
> tie it in with how the hardware addresses the screen :-)

This is something I failed to mention. A system of any size may well have a few different rectangle implementations: the C struct used in the display driver, the C++ rectangle class in the middleware graphics routines, another C++ rectangle class which accidentally got re-invented. If these rectangles all use different conventions we may hit problems converting between them.

I resort to signed ints everywhere as well but I do find it tedious to work with *::size_type in the standard library. Why on Earth did they use unsigned types?

A quick update. This article, dated June 2005, references the up-and-coming "Boost Parameters Library" which at the time had yet to be formally released.

Boost 1.33.0 has now been now released and the "Boost Parameter Library" is indeed there:

http://boost.org/libs/parameter/doc/html/index.html

> I actually like unsigned types. Without them, you waste a
> lot of memory for unbounded integers that can grow beyond
> the normal 32 or 64 bits (or rather beyond the size
> allowed by the compiler). You need unsigned ints to
> represent larger signed ints.

If you really need that most significant bit of an unsigned number, you're dangerously close to wrapping.

> This results in infinite
> amounts of frustration with Java where you waste twice as
> much memory for nothing.

On the other hand, a guarantee over size and a guaranteed 8 byte long can be of use. For example, you don't really need to worry about timer wrap in Java code. Not in the lifetime of this planet, anyway.

A 4 byte unsigned milliseconds timer wraps quite often.

> They're also necessary if you
> want to right shift without setting the high bit if you're
> manipulating bits and not numbers per se.

I hope its clear that bit shifting should always be done on unsigned values.

Scott Meyers wrote an interesting article promoting the use of signed ints in interfaces.

http://www.aristeia.com/publications_frames.html
"Signed and Unsigned Types in Interfaces"

> Overall, I found all the examples to be lack of experience
> or knowledge.

Nonetheless, I hope some readers may benefit. FWIW, these are true stories, and experienced programmers really were caught out.

> Yes, they happen to the best of us and
> there should be better ways. I don't think there's any
> argument there. But if you use a non-saturated integer
> type, you have to expect some problems if you don't check
> your math.
>
> When I saw the width, height example, I was thinking
> that's got to be reversal of x and y. Happens all the
> time to anyone that's done any kind of graphics.

Yes, I agree. My point is that what appeared to be a type-related problem did not get caught by the compiler. Only careful system testing caught the error. There are techniques enabling you to lean harder on the type system and catch this problem.

> I didn't see anything in this article that isn't part of
> any normal programmer's learning curve. BTW, the type
> safety you mention is a little odd. In C++/C, the type
> mechanism is only there to help you use the same type.
> What you do with those types is up to you. An int or
> r unsigned int is not a saturated type or bounded in any
> way. That's your choice to use them and so you have to
> accept the errors you encounter if you don't use something
> safer.
>
> Nice examples and good for any learning programmer.

Thanks.

> But
> if you don't watch what the properties of the types you
> use are, then there's nothing any language or technique is
> gonna be able to do to help you.

Testing can still help.