Greg London writes: > > I would like a book that introduces c and c++ from the point of view of showing > the best practices first and comp-sci theory gets put in the second edition so I > don't have to buy it.
I would highly recommend 'The Design and Evolution of C++' by Stroustrup. It's an older book now, but still was written with a great deal of perspective on the use of C++ and does a good job of explaining why many things are the way they are -- which of those things are for the best and which are not. Probably better value, and with much more perspective, you could pick up 'Handbook of Programming Languages Vol I', which is the one covering C++. This is an excellent tome that covers the design of C++ in even more detail and includes more specific material about right-ways & wrong-ways to do things. It also covers other languages and is a great collection of such writing. While I can understand a (apparent) desire to avoid "Comp Sci" basics, I recommend always looking at the history of the design of a language -- or at least the design of that language -- in order to understand how to use it effectively. > For example, unless I'm missing something fundamental, I don't see any reason > to have parameters to a c++ function ever be a pointer. If I need an in/out, I > pass by reference. You might want to move that pointer without declaring yet another variable & asking the compiler to figure out another register mapping. That is, change the address the pointer itself contains. > There's also the various and many flavors of a sequence of characters in c++. > You could have an array of chars, a pointer to an array of chars, a std::string, a > sstream, and I'll be DAMNED if c++ isn't designed so that not one of them will > work in every situation. Yes, of course. This is much like how the C programmer on a UNIX system has a choice between using FILE handles or file descriptors -- neither is able to do everything the other does, and there are important reasons for that, even though one is implemented using the other -- each represents a set of tradeoffs and the more complicated FILE structure imposes certain burdens on the programmer. Similarly, std::string is a great way to get a very friendly interface to string data, but that friendliness is built upon certain requirements in terms of data content and access patterns. > So, really, if the way to move text around is with strings then I'd like a book that > starts out introducing strings and then later on, when some stupid exception to > the rule comes up, it goes into char* or streams and explains the difference at > that point. > > That was the sort of book I was looking for. > Probably doesn't exist because no one will agree on the best way to pass strings > around in c++. Using std::string is the "best" way to handle most strings most of the time -- for typical "business application" programming. _However_, using C++ is the "worst" way to write typical "business application" programs -- at least at this point in time. There are now two good reasons to use C++; one is to write "highly optimized" code which uses pointer manipulations, direct memory management, and other such techniques to produce "fast code" -- which one should then be calling from a more flexible and convenient language, such as Java or Perl; the other is to write for a platform which _only_ supports C++ (or C and C++), such as an embedded controller for some archaic hardware system -- in which case one is unlikely to be writing a typical "business application". _So_, the "best" way to use C++ strings is only the best way when you're writing code which is the least appropriate code to use C++ to write. YMMV. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
