CompuServe Messages

>I can see how C++ in general will result in larger and slower code I cannot. This is not to imply that certain features in C++ do not have performance or size tradeoffs: some unequivocally do. However, the issue on the table is not to compare features (but even at this, some C++ features do not have an issue even though "but they must") but to compare what happens when the same problem ends up being respectively coded in each (realizing a slight glitch because "C is C++" (almost)). The end result in general is that C++ code is just as fast, but larger. >(and C++ is becoming equivalent to BASIC) I'll put in my 2 cents: Eh? Or do you popularity-wise? >- Even though my code is bigger and generally slower, I think the benefits >of using C++ (or Object Oriented Languages) outway the performance >degradation. That might be a valid compromise for some other language since it is not slower, this conclusion is not valid. >- After writting your code, you can always find the areas that are >performance sensitive and write pieces of that code in assembly. If you >find yourself rewritting everything, then I think there is a problem in >the design. Both of these points have _always_ been true no matter what the language, so singling out C++ here is bogus. (And a nit: going to assembly is not the only course of action, but certain one that many should consider). >- You can right class specific 'new' and 'delete' operators to increase >performance in the creation and destruction of classes that do not need >the extras that come with 'new' and 'delete'. If that is deemed to be a problem for a specific app: absolutely.