CompuServe Messages

>If you restrict yourself to a subset of the C++ features, you can write very >efficient C++ code. There can be truth to this for a certain app, or combo of things, but this is somewhat pushing it to have to restrict yourself to the subset in most cases. >I avoid passing or returning classes by value, for example, so I sidestep the >whole issue of created and destroyed temporaries. I do use the concept of >member functions and even virtual member functions; these don't add much >overhead compared to well-written C code, but are easier to deal with. I use >function overloading and default parameters, but again these features don't >cost anything at run-time. I use templates very carefully to ensure that I >don't end up with 50 gazillion automatically generated template functions. I >don't use iostreams. I do use new/delete. Anyway, the point is that the C++ >language doesn't make it impossible to write high-performance code like some >other OO languages do (with their run-time class binding, etc.) but some of >its features do exact a run-time cost – and we must be aware of what each >language feature is actually DOING underneath, or we risk writing really slow >code. No problem with this list. The summary of it is that most of these do not have speed hit but that some will have a size hit, which I believe was my first response on this. The three "real" issues are: – the size of the iostream library (and of course in most apps, this is transparently absorbable with little problem) – temporaries: this is definitely surprising at best and so one definitely has to know about this – template functions: the problem is not the generation of the functions so much as the laying down of them. But yes, this can indeed be bloat. Definitely need smarter compilers and programmers wrt this.