Boost logo

Boost :

From: Liu Jin (cpp_at_[hidden])
Date: 2005-10-14 23:22:12

>>>>> "Jim" == Jim Hyslop <jhyslop_at_[hidden]> writes:
> Liu Jin <cpp <at>> writes:
>> Then how does bitwise-shift relate to I/O (iostream), or
>> arithmetic addition relate to string concatenation (string),
> I was waiting for someone to bring these up.

> They don't. The aforementioned coding guidelines often use these
> two overloads as prime examples of how *NOT* to overload
> operators. But, they have been in the language for so long that
> they are now part of the language's idiom.

Despite what those guidelines say, the two overloadings are easily
received by newcomers. ( I know because I'm a teaching assistant in
freshman's C++ course. ) People are not surprised by cout<<i or
str1+str2, expecting those to mean shifting cout i bits left, or doing
arithmetic addition on two strings. They just recognize it as
something alien, and the moment you explained the new meaning, there's
no further confusion.

> However, that does not make it "right" to perpetuate further operator overloads

Correct. But they are in the same category of operator overloading:
overloading an operator in a completely different context, to have a
completely different meaning, regarding the built-in one. The
rationale behind this kind of overloading is similar.

>> What's wrong when two irrelevant domains accidentally choose
>> the same notation?

> Let me turn this back at you: what's wrong with using a word
> instead of a symbol? Sure, using a symbol may save a few
> keystrokes of typing. But, code is _read_ far more often than it
> is written, so the few seconds you save in typing are more than
> offset by the several seconds' confusion experienced by each and
> every programmer the first time they see this new and unusual
> usage (my first thought, actually, was that it was a
> declaration, then I thought "address-of", and then finally
> clicked in to operator overloading).

Nothing wrong. Just a little more readable to those new to the code,
and a little less readable to those familiar with it (long words
require more mental power to process, exactly the reason 1+2*3 is more
readable than one plus two multiply three). I guess code is read far
more often by those who know it than not.

So after all it's just a minor design issue. Had Robert chosen the
other path, say, serialize(ar, obj), I'd raise no objection. BTW,
`serialize' is not the perfect choice here. It kinda makes me
wondering: where's the corresponding deserialize calls? ;-)

Liu Jin

Boost list run by bdawes at, gregod at, cpdaniel at, john at