"Jim" == Jim Hyslop <jhyslop@dreampossible.ca> 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