Actually, putting all the code in headers helps with function inlining more than anything. The virtual function stuff is very complicated because usually code can be linked in at runtime that adds new functionality (i.e. a new derived class).
Make no mistake, virtual functions are VERY expensive. I'm just saying there are instances where they are a faster than function pointers. The reverse is also true sometimes as well. My point was only that adding new features to a language that don't incur overhead when they aren't used can't possibly make a language slower which is why C++ is not a slower language than C. As far as the assembler stuff. I have written assembly code before. There are several reasons why compilers are better at it in my opinion: 1) They know the rules of the chip much better than people. 2) The rules change, all that is required is a recompile to optimize for the new chip. If you are using direct assembly and you optimized it well for one chip, it won't be best for the next. 3) Correct optimizing at the machine code level can be calculated very precisely. There is much less of an art in organizing instructions and selecting specific ones. The reasons why one choice is better than another are very easy to see, but are extremely computationally intensive. Computers excel at these types of computations. That said, there are times when I am programming and I know that my compiler won't know "the fastest way" to implement something in machine code. If there was a good way to implement inline assembly into code, it would be worth it. Sadly, inline assembly breaks up the optimization of the code around it enough that it usually isn't worth it. Just my thoughts, Nick On Nov 22, 2007 9:41 PM, Heikki Levanto <[EMAIL PROTECTED]> wrote: > On Wed, Nov 21, 2007 at 09:29:42PM +0000, Stuart A. Yeates wrote: > > A C++ compiler can make those kinds of assumptions if the object is > > created within the current compilation unit and can not be overwritten > > from outside it. There are a whole class of optimizations in Java, C > > and C++ which can only be applied under these circumstances, which > > rely on concepts of scope. Whether or not a particular compiler uses > > these optimizations in a particular case is another matter. > > Aha - that must be why LibEGO includes all source files from the mail > file, > instead of compiling each one separately. > > -H > > -- > Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
