TITLE: extraction operator musings (Newsgroups: comp.lang.c++, 23 Oct 96) CORBIT: "Dann Corbit" > Well, I'll agree that: > > cout arg1, arg2, arg3, arg4, endl; > > would have been a lot more natural to me than: > > cout << arg1 << arg2 << arg3 << arg4 << endl; BJARNE: bs@research.att.com (Bjarne Stroustrup) "Natural" is very much in the eyes of the beholder. I tried several alternatives (on several people): cout = "Hello, " = "World!\n"; cout < "Hello, " < "World!\n"; cout , "Hello, " , "World!\n"; cout << "Hello, " << "World!\n"; cout <- "Hello, " <- "World!\n"; ... From my (limited) sample of responses, << was the best. It indicated a direction of information (in the same way as << for bitshift does), it had a dual for input, it didn't invite mistyping to the extent < did, it bound the right way in the C grammar (as opposed to =), etc. CORBIT: > but every standard library has warts. > Look at how strtok() hacks up one of your input parameters. > And you call it differently the second to the nth time. > Bletch! > WOODING: Mark Wooding wrote in article > ... > > Chris Engebretson wrote: > > > > > Operator overloading is not inherently bad. > > > > OK, I'll agree with this. However, C++'s particular brand of operator > > overloading doesn't get off to a terribly good start: the first trivial > > C++ program that most people write (myself included) contorts `shift > > left' to mean `write to'. BJARNE: The use of << for shifting bits was a novelty in C. I sort of like it, but unless you are doing a lot of low-level coding bit-shifts are terribly obscure and << an even more obscure notation for it. For most C++ programmers << means `put to a stream' and is also very occationally used for pushing bits around in an int. The use of << may offend people who feel that shifting bits is a very important and fundamental activity for programmers. However, I suspect it is more an obvious target for people who objects to overloading in general (apparantly not this poster) or C++'s use of it in extending C in particular. Given the set of operators available, I think << was the best choice. Given a completely free choice of operator symbols, I think that << and >> are still pretty good choices. Finally, given the design alternatives for extensible, type-safe I/O, I still think that the use of operators is a very reasonable approach. I encourage people to look at the choice of << and >> for I/O in the context of C++ and its design aims and alternatives, rather than as an excuse for a boring C vs C++ flamewar. I documented a lot of the reasons in "The Design and Evolution of C++" and "The C++ Programming Language" (see my home page). WOODING: > > As well as providing useful services, a standard library ought to > > provide an example of the `philosophy' of a language. C's library does > > this well, in my opinion. C++'s says it's all right to contort the > > meaning of operators. BJARNE: No. C++ doesn't say anything. It is a language not a person. I don't recommend "the contortion of the meaning of operators," and neither does any C++ teacher I know of. The choice of << and >> for I/O was deliberate, backed with experiment, and reasons behind it were documented. The standard C library served C well, and the lack of a proper C++ standard library of string, vector, list, map, etc. classes was a major (and acknowledged) problem for C++ Users. To this day, it drags far too many C++ novices down to an unnecessarily low-level of programming. The draft ISO standard C++ library now provides good examples of what can be done with C++ and supports native C++ styles of programming.