CompuServe Messages

Hani – A couple of comments: SAS/C++ is *not* a port of cfront 2.1. It is a C++ translator developed from scratch in-house at SAS Institute. Even if SAS/C++ is not as efficient as SAS/C, that won't prove anything about the C++ *language* in general, just our implementation. In point of fact, I would expect SAS/C++ to be marginally slower (5%, say) on the same program compiled in both modes (after all, C code is C++ code, so it is possible to compare apples to apples.) Some C++ features could be used without adding to the execution-time cost – for example, function overloading is a practically free feature of C++. Others could be used without added cost if certain conditions are met – for example, member functions are free if your C functions all work with passed-in structures instead of updating lots and lots of global variables. The global variables are faster, but harder to extend and maintain. Basically access to member variables is by an indirection, so if you're going to have the indirection anyway, it doesn't hurt you to use C++. It is possible to write object-oriented code in C, with enough PROGRAMMER discipline. The language doesn't help you much, but it's possible. I believe that the same object-oriented design in C and C++ will be very close to the same speed. Much of C++'s bad rep for size/speed comes from the iostream library and the basic startup overhead for very simple programs. These are not good real-world test cases for size and speed. It doesn't really matter to me whether there is 1k or 40 bytes of startup overhead in a 100k program, since if I don't have it, I'll probably end up reinventing most of it anyway. –Doug