Re: [boost] [Serialization] why operator &()?

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

>>>>> "Jim" == Jim Hyslop <jhyslop_at_[hidden]> writes:
    > Liu Jin <cpp <at> vip.163.com> 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? ;-)

Regards,
Liu Jin