Author: Ratko V Tomic
Date: 13:27:33 03/28/02
Go up one level in this thread
>You can do this "tailoring" with C++ almost the same way you do it with C. Just >have a sort of object pool, the same way you can have a thread pool. It's not >like allocating a heap is free in C, either. The C heap isn't free, but if you know in advance that the item size is fixed and that the alloc/free will follow particular discipline, such as FIFO or LIFO, you can have the custom sub-allocator operating within the pre-allocated memory (e.g. obtained using VirtualAlloc, so that you don't commit physical pages unless actually needed, while retaining single contiguous block property for an easy FIFO/LIFO implementation). Taking advantage of the one or both properties you can get a speedup factor 5-8 on alloc/free operations compared to the built in C libraries or the automatic C++ object creation. >Not really. By compiling with the C++ compiler, you're not losing any >performance and you're gaining the ability to pick and choose between C++ >features. I don't have any problem with that. That's mostly how I use C++. >It makes perfect sense to me to write a chess program in C, then take >the engine code, put it in a class, and start multiple threads with multiple >instances of the class (to make the program multithreaded). This keeps the code >clean: you don't have to pass and reference "board" pointers all over, and >there's hardly any performance penalty. The problem I run into with this is that by the time I come around rewriting the existent code (this is not chess related), I have had time to learn from the old code and I have many new ideas how it should be done this time, so I am back in the prototyping and exploring mode rather than just cleaning up the old code. At that point C with its minimal up-front commitment to decisions about something I am still trying to find out, works much better than the conventional C++, where once you lay out the classes and build upon them, it becomes harder (than in C) to back-off and change drastically the initial decisions. (The 'object', however important and general, is still just one modelling tool/building block, not always the best one for every task or algorithm or domain.) The approach you suggest I have found useful for things like utility libraries, where one works on a fairly settled, stable functionality and known algorithms. > Just because a program isn't designed to be super object-oriented > from the ground up doesn't mean C++ is worthless. I would never say C++ is 'worthless'. I think for the corporate assembly line punch-card programming, using cheap, low skill, low trust, high turnaround labor, where the managment wishes to maximize the replacebility, control and oversight over the programmers, C++ is far superior to C. But for the high performance cretive work where you are trying to discover how to do something better than anything that is currently out there, C is a more sutable tool. (But, as you suggest, if you're not an OOP (or C) puritan, there is no sharp boundary between the two and one can easily shift the balance as the project evolves.)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.