Code center > Darwinbots Program Source Code
C++ refactoring
Numsgil:
--- Quote from: Sprotiel ---Well, I guess the honest answer to this is: I'm glad you saw the light, at last!
--- End quote ---
I've seen alot of very poor "OO" code. Alot of very poor OO code. I have/had some prejudices. Of course, I've seen some even worse code used for various research papers written in C or FORTRAN, so there's something to be said about bad programming practices all around I think.
While I'm on the topic, at the moment I'm exploring a data driven design architecture. Which basically means the data and the algorithms to operate on the data are entirely seperated. So when I say "OO", it might be a little different from what you're used to if you've been doing the more standard approach of data + implementation in the same data object. This is a good collection of articles and thesises (thesi?) about data driven design. Basically it allows the data to be shared between the GUI and the engine and the parts of the engine, without various modules needing to know how the others work.
Also, the Engine DLL should be fairly trivial to handle. The main reason I think it needs to be seperate is that I'd like to use ANSI C++ for the main engine to allow portability issues. But I'm really enjoying C# for GUI creation. A WSYSISYG GUI creator and IDE is really about the greatest thing since sliced bread. I could move the entire engine to C#, but that would mean alot of rewriting code and abandoning portability. Having the two seperate and working in different languages should allow both to play to their strengths, and helps physically enforce proper abstraction between the two.
I'd be willing to use another library than boost for threading. Basically I just need a portable threading library, preferably stand alone without other cruff. The more features the threading library has, the better.
Sprotiel:
--- Quote from: Numsgil ---While I'm on the topic, at the moment I'm exploring a data driven design architecture. Which basically means the data and the algorithms to operate on the data are entirely seperated. So when I say "OO", it might be a little different from what you're used to if you've been doing the more standard approach of data + implementation in the same data object. This is a good collection of articles and thesises (thesi?) about data driven design. Basically it allows the data to be shared between the GUI and the engine and the parts of the engine, without various modules needing to know how the others work.
--- End quote ---
A Google search on "data driven design" reveals that it's mostly understood as a way to pretend doing OOP, while doing anything but it. I'm not sure you're referring to the exact same thing, but I've read the thesis you linked to and I'm not convinced. Modularity is certainly a good thing, but I don't see why the approach described in there would be the only way, or the best one, to achieve it.
--- Quote ---Also, the Engine DLL should be fairly trivial to handle. The main reason I think it needs to be seperate is that I'd like to use ANSI C++ for the main engine to allow portability issues. But I'm really enjoying C# for GUI creation. A WSYSISYG GUI creator and IDE is really about the greatest thing since sliced bread. I could move the entire engine to C#, but that would mean alot of rewriting code and abandoning portability. Having the two seperate and working in different languages should allow both to play to their strengths, and helps physically enforce proper abstraction between the two.
--- End quote ---
I'm not too sure of the wisdom of using two different languages, since it requires proficiency in two instead of one languages. Besides, portability is one thing, but actually being ported is the real goal. We have much more chances of attracting Linux or Mac users if they have a GUI (almost) up and running than if they have to build it from scratch before using the program. I really think the whole program, not just the engine, should be portable.
--- Quote ---I'd be willing to use another library than boost for threading. Basically I just need a portable threading library, preferably stand alone without other cruff. The more features the threading library has, the better.
--- End quote ---
The more I look at boost, the more useful I think it could be (serialization, smart pointers, ...) but having too many dependencies should be avoided and FOX already handles threading.
Anyway, you should take a look at my version of the code. I believe I made significant progress wrt. goals 2, 3 and 5.
Numsgil:
Googling this probably isn't a good idea. It's a loaded concept that means different things to different people.
For Darwinbots, basically, all the data is physically stored in various singleton managers in the engine. Data is passed into algorithm singletons that modify and change it.
Pros:
Additional non core modules can easily be worked in (GUI, stats tests, etc.) without core modules worrying about them. The core engine can be entirely ripped from the GUI, and vice versa, enforcing strictly bound problem domains.
Cons:
If the data representation changes, all of the modules need to be changed that deal with that data. Different files need to be maintained between C# struct definitions and C++ definitions. Const correctness is difficult (and in some ways unnecesary).
It's basically identical to more proper OO designs, except you're splitting the implementation and data apart. The idea is that you can rip out certain modules (say, physics), replace modules (again, say physics), or add modules without modifying other modules. This isn't as true for OO design, which follows a more hierarchial approach.
--- Quote ---I'm not too sure of the wisdom of using two different languages, since it requires proficiency in two instead of one languages. Besides, portability is one thing, but actually being ported is the real goal. We have much more chances of attracting Linux or Mac users if they have a GUI (almost) up and running than if they have to build it from scratch before using the program. I really think the whole program, not just the engine, should be portable.
--- End quote ---
Have you done any programming with .NET? It's absolutely spectacular. Between GUI building, database support, internet controls, and other features I'm still discovering, it takes alot of the head scratching out of some of the features I'd like to add to Darwinbots.
There are also .NET exports to linux such as Mono, that probably will let you run Darwinbots on other platforms. I say probably because I've heard reports that some of the more abstract features are missing.
I could program it all in C#, but I'm more familiar with C++ and there's already a 13K line code base that's written in C++. Moving it all to C# is a question worth discussing, but I'm not sure the time required to do so would be worth it. I'm not sure I can think of a good reason not to move it to C# beyond my lack of knowledge, the time it would take, and portability issues.
If someone wants to take the time to refactor the current code into C#, that would be cool. Or if anyone can think of other valid reasons to maintain the code in C++. My experience with C# is still intermediary.
--- Quote ---Anyway, you should take a look at my version of the code. I believe I made significant progress wrt. goals 2, 3 and 5.
--- End quote ---
I did like the idea of loading the DNA and copying it to instances of a species insetad of reloading it for every individual. What really needs to happen is that the Robot class needs to be split up into like 6 different core ideas. Major refactoring work. I'm still working on what sorts of splitting need to be performed.
frankle:
Ok, after reading this thread I have a few comments.
The idea about making an engine dll is just common sense with a project like this. Having the guts be independent from the GUI should be a core priority. This has more implications than just cross-compatibility. It also makes things like server/client architecture easier for one, and the ability to use the C# GUI development tools is essential as well.
For extensibility and scripting, I'd suggest looking into lua (http://www.lua.org), which is a lightweight programming language developed specifically for extending programs.
I'm curious at this point why the VB fork hasn't been feature frozen? It seems counter-productive to me to be actively extending the feature set of one codebase while rebuilding in another language. I understand reluctance to learn another language, but wouldn't it be more productive to have all hands on deck on the new codebase? Let the VB 6 codebase die with VB 6.
As far as multithreading goes, I think that having 'an eye' to MT is a bit underpowered. Ideally every procedure that can benefit from multithreading should be designed to make use of it. The real trick is knowing if a routine actually benefits from MT.
Lastly, documentation is ABSOLUTELY ESSENTIAL to fostering community involvement. Code without documentation is like coca cola without sugar. It just sucks. I can't emphasize how important documentation is to community support for a project.
Anyway, I'm certainly a newb to this project, and I don't mean to ruffle any feathers. Just my $0.02
Numsgil:
--- Quote from: frankle ---The idea about making an engine dll is just common sense with a project like this. Having the guts be independent from the GUI should be a core priority. This has more implications than just cross-compatibility. It also makes things like server/client architecture easier for one, and the ability to use the C# GUI development tools is essential as well.
--- End quote ---
At the moment I'm leaning more towards implementing all of it in C# (it's won me over ). This would still allow for a core engine DLL, I think. I have played around with having multiple solutions for the same project, since custom GUI controls need to be in their own DLL.
--- Quote ---For extensibility and scripting, I'd suggest looking into lua (http://www.lua.org), which is a lightweight programming language developed specifically for extending programs.
--- End quote ---
I had the same idea. Lua seems the best choice to me.
--- Quote ---I'm curious at this point why the VB fork hasn't been feature frozen? It seems counter-productive to me to be actively extending the feature set of one codebase while rebuilding in another language. I understand reluctance to learn another language, but wouldn't it be more productive to have all hands on deck on the new codebase? Let the VB 6 codebase die with VB 6.
--- End quote ---
It was feature frozen for a long time. But after about the 6 month mark and no shiny new C++ version forthcoming, Eric joined the forum and started tinkering with the old VB source to fix some longstanding problems. It's sort of rolled from there.
--- Quote ---As far as multithreading goes, I think that having 'an eye' to MT is a bit underpowered. Ideally every procedure that can benefit from multithreading should be designed to make use of it. The real trick is knowing if a routine actually benefits from MT.
--- End quote ---
I'm pretty well versed in the "theory" of MT, but I haven't done alot of work on anything as large as Darwinbots. Which means I'm pretty sure I know when and where to MT, and I know what pitfalls to look for and identify (race conditions, deadlock, etc.) but I'm not as well versed in the best practices to control these issues.
--- Quote ---Lastly, documentation is ABSOLUTELY ESSENTIAL to fostering community involvement. Code without documentation is like coca cola without sugar. It just sucks. I can't emphasize how important documentation is to community support for a project.
--- End quote ---
This is alot of why I'm really liking C# at the moment. Alot of documentation is done automatically if you provide the appropriate tags.
--- Quote ---Anyway, I'm certainly a newb to this project, and I don't mean to ruffle any feathers. Just my $0.02
--- End quote ---
Feel free to ruffle away Pretty soon I'm going to be placing the VB and C# code into SVNs along with the C++ code (which already is), so all the code will be in the same place. Then it should be pretty easy to look at changes to any of the code.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version