Code center > Darwinbots Program Source Code
C++ refactoring
Numsgil:
I'm thinking of ending my Darwinbots coding sabatical and I'd like to see the C++ fork smoothed over and finished. The present code can be seen as a rough draft I think. Here are the changes (some major) I'd like to discuss:
1. Documentation is vital. An automatic documentation system like doxygen should be explored. Code documentation has always been my weak point, so I'd like thoughts from people more knowledgable about this than I.
2. Pure object oriented - I've slowly been won over on the maintainability and architectability of well designed object oriented code. An example: different shot types are inherited from a pure virtual base class. I'll have to explore the source before I know for sure what I'd like to do.
3. Engine DLL - The core engine is constructed to be a DLL that interfaces with a pure virtual GUI handler. This way, the GUI can be constructed seperately from the core engine. The idea is that I can build a pure console version, a C# GUI interface, and still remain potentially cross platform.
4. Boost library, specifically threads but maybe other things as well as I explore boost better. Problem is that it takes like 3 hours to set up the boost libraries on someone's computer, especially if they've never done it before.
5. An eye towards multithreading. This is especially important for things like a bot debugger in the program. Mutexes need to be interspersed properly to get everything working right.
6. Sysvars no longer read in from an external file, but stored as a hardcoded STL map. You could output a list of sysvars populated from this map. The idea is that you only need to distribute a single file.
Just looking for people's thoughts. Most of the code is fine as is, but the over-reaching architecture is a little weak.
EricL:
#5 is top priroity from my perspective. I think we will see 64 core chips in 2 years time available in machines for under $1k. Think of what we coudl do with that kind of horsepower... DB should parallalize extremely well and without the need for fancy threading libraries...
The importance of #2 is to a large extent a function of the number of developers on the project. Personally, I'm surprised more people arn't hacking away on the VB fork given how easy and approachable Vb6 is. Given this, I doubt we will have many code authors on the C++ fork. I'm all for strict object orientation and aherance to class inheritance rules, but there is a cost in terms of learning curve and speed of development. The fewer the authors, the less critical this is I think.
The same can be said for #1. If no one is going to read your code, why document it? But if you have a bunch of authors, it becomes critical and a matter of honor to document your work. I know I would be doing a better job on the VB fork if I thought anyone would ever look at the source...
#3 is not high on my list. It takes work to maintain portability. If someone really wants to run on Linix, let them join the club and maintain the portability of the code. Until then, focus on Windows.
#6 is a good idea. I may do this in the VB fork...
Numsgil:
This might be an issue with a sort of chicken and the egg though. If the code is more accessible to major changes, maybe more people would work on it. The VB source is open more to smaller changes (like adding a sysvar) but is(was, I haven't touched it in a while ) getting harder and harder to shoehorn major new features. This isn't really anyone's fault, it's just a product of the iterative development of the program.
Major changes are going to be easier with major refactoring. Major refactoring is alot of work.
Let me see what I can come up with...
Sprotiel:
Well, I guess the honest answer to this is: I'm glad you saw the light, at last!
More constructively, I agree completely with items #2 and #5. I would even say that #5 is an absolute requirement if we want a stable GUI app.
I also agree with the goal stated by #3, but I don't think it's really useful right now to actually make the core engine a DLL. Just keeping the possibility open by ensuring that it's possible to compile a console application with just the core engine should be enough for now, IMHO.
I agree with #1, but I don't think it's critical. Better than a thoroughly-documented code is a code that's clear enough to not require documentation.
As for #4, I'd say we shouldn't use boost unless we really need it, but it seems to have a lot of handy features, not just threading, so I don't know.
I disagree with #6: I agree that the way the sysvars file works now is rather silly, but the possibility to change the memory location associated with a sysvar would be interesting.
EricL:
--- Quote from: Sprotiel ---I disagree with #6: I agree that the way the sysvars file works now is rather silly, but the possibility to change the memory location associated with a sysvar would be interesting.
--- End quote ---
FYI, as of the next VB version, the sysvars file is no longer needed or used.
The code is not and from what I can tell, never has been set up to allow for the changing of the memory location associated with a sysvar simply by editing sysvars.txt. Doing so will certainly break things in current versions. There are many, many places in the code where the mem locations for specific sysvars are hard wired and changing this would be a major major work item. Sysvars.txt is not a sysvar mapping table that drives the code. All it allows (allowed) was the potential for sysvar synonyms, localized sysvar names for example. If you wanted to call .dn .down instead (or something in Italian perhaps) for your own bots on your own machine, you could change the sysvars.txt file entry or add additional entries and this would work. That is the only thing we loose when the sysvars go internal to the exe - the exe has to rev to add sysvar synonyms - but the gains in simplicity are well worth it IMHO, particularly once I complete the work for the exe to be self installing.
Navigation
[0] Message Index
[#] Next page
Go to full version