Garbage collection:
- Although it's always fun to mock people who fail due to memory leaks while using a garbage collected language...
- I think D simultaneously defeats C++ and Java/C# here...
- But, but, C++ has garbage collection libraries! Yea, in ten years of programming I haven't used a C++ garbage collection library. I have used Purify, Valgrind, and even overloading new and delete; looking for memory leaks (not to mention the NewStars code is loaded with memory leaks...)
- Java has garbage collection, and only garbage collection - unless you use Embedded Java, then you get no garbage collection! Enjoy!
- D "makes the easy case work". The default is garbage collection, with overrides for self-managed memory (of various forms).
- Doxygen ('///' and '/***/') works on C++ and Java (it's an extension of JavaDocs)
- However, it needs to run as a separate step of the build.
- This can be confusing. For example, I ran the debug build, and didn't see Doxygen (although it might be in there, with make spewing thousands of pages of output...). Some of the code uses it, some doesn't. So, I started converting everything to not use it (it's ugly and confusing, if you're not going to generate the docs). Until I discovered than there is a build that does use it (and the code not using it, needs it)
- Less ugly Doxygen style comments are built into the D spec. There is a compiler switch to do the docgen run.
- Programming is all about assumptions. When writing new code, you've got some idea of what's going on in the program, and what the inputs will be, and what sort of outputs you can create.
- Of course, assumption are made to be broken. That's why I'm always sprinkling my code with plenty of 'asserts'.
- DBC formalizes all of this. 'assert' is part of the spec (rather than being an ugly macro). Also, there are 'in' and 'out' blocks for functions (to check inputs and outputs). Classes have 'invariant' statements, which are processed before and after functions (to ensure class invariants are maintained).
5 comments:
Newstars has leaks? No way :)
It is probably in all that gods cursed string handling that I do for the XML processing...
But fortunately the server engine starts clean at the beginning of each new turn process...
It's not the server I'm worried about... the Tcl client loads all that code as a DLL...
Nate saw some oddities in the original Win16 client after it was open a few weeks; I'd like the Tcl client to not have the same reputation...
Why don't we just valgrid it then?
I have it installed on deathstar...
I'm not worried about it enough to go to that trouble. Valgrind will tell us where the problems are, but it will take a fair amount of architecting to fix it...
This next check-in will include a global XML DOM tree for Tcl (you might remember when I added tdom, since you had to find the package ;) - previously I used it only in spots too complicated for xml2list.
I initially added the C++ code to handle all the XML. I can now start to wean Tcl off C++, and eventually either replace the C++ with a simple subset, or a simple D replacement.
Post a Comment