C-piphany

(rhymes with epiphany)

At some point, I realized why C++ is so unwieldy.

It is really three (or four) different languages:

1. Macro preprocessing language. #define, #include, etc. Mostly deprecated in C++, except for #include, and #ifndef protection in header files. Except when someone drops 300k lines of 15 year old code on you, and it is filled with all sorts of "horrors man was not meant to know" (TM).


2. Base C language (and C++ extensions, which can be considered a language unto themselves). What we normally think of as the language, with declarations and operators. I think this is where C++ shines, with lots of tools to wedge things together (operator overloading, references, etc.).


3. Template programming language. This is needed for the standard library (arrays, etc.). Except, it becomes all to easy to start coding everything in templates. Then, you're hardly using C at all. It's all bizarre template stuff. It's all in header files, and it's all ugly and hard to understand...
   

Hopefully D fixes this. I know the macro preprocessing is gone (integrated into the language). The D template syntax looks much cleaner.

Stuff I've read lately

"The Stone Canal" (Ken Macleod) - This is the precursor to "The Cassini Division", which I read first. I find it didn't add much, although it was ok.

"Why God Won't Go Away" (Andrew Newberg, Eugene D'Aquili, Vince Rause) - Reviewed on my faith blog.

New Stars Status

Big landmark! The Battle VCR!



It also includes the battle report window (very small, just left of the top of the VCR). This allowed me to find an interesting bug. Scan was comparing pointers, so the same ships were getting scanned over and over.

I also added the detailed scan for ships in battle (still need to make this the behavior for WM scans).

This check-in also includes a top level Tcl XML DOM. That's a complicated way of saying Tcl now has access to the parsed XML file at any point. Previously, it required C++ to parse the XML, and could only query the XML for individual objects. This should allow me to migrate to an all Tcl client (or at least one independent of server code).

The Horror, the Horror

(Continuing my rant on g++ 4, which is a part of my musings on D)

Ok, take the code from last time, and add this after the "class Par" definition:

template<typename T>
class Child : public Par<T>
{
public:
void fun(void)
{
   x_ = 4;
}
};

This code should compile on on gcc 3.4 or in Visual Studio. g++ 4 gives the following error:

main.cpp: In member function 'void Child::fun()':
main.cpp:22: error: 'x_' was not declared in this scope

Err, excuse me! x_ is inherited from the parent. Just look, it's 'int x_'. It's protected, that means it's visible to any children! How can I fix this! I don't know what to do!

After about five minutes of careful Googling, I found a site that seems to understand what's going on. They say:

"The C++ standard prescribes that all names that are not dependent on template parameters are bound to their present definitions when parsing a template function or class."

There is actually a good reason behind this. People were having problems where templates were full of buggy code, but no one knew it until you tried to use them (because the compilers were just turning off error checking when interpreting template code). So now, compilers are trying to understand the template code, and check it for errors. The only problem is good code is now wrongly flagged as erroneous code. Oops!

There is a fix:
this->x_ = 4;

Ok, I can see how that helps the compiler figure stuff out. However, it hurts my brain... If somebody else sees this code (and isn't familiar with this change in the compiler, like say they've been programming C++ for the last ten years and never seen it - like I was until this week) they are going to say, "Oh, that 'this' isn't needed. I'll just remove it." Let's say it's in some utility header (like a good template should be). And that it takes an hour to recompile (like my project does). And they change a lot of other stuff before starting a full recompile (because you don't want to wait an hour between every one line change). And then they get that bizarro error. Yea, they're gonna be mad. And they're going to have to back track through all the changes they've made, google for the page above (assuming they can find it, I only found it by looking for "two stage name lookup" - yea, that's intuitive), and recompile another hour or two.

Enjoy! :..(

Note: apparently, it went into g++ 3.4, only 3.2 is safe!

c++->fail()

(Continuing my musings on D)
(that code actually works, try (assuming C has a method fail):
C cAry[2];

C *c = cAry;
c++->fail();
)

I got bit by several very ugly bugs in g++ 4 this week. This is about code that works in gcc 3.2, 3.4, and Visual Studio. But breaks in g++ 4.

This is because g++ 4 is more closely matching the C++ spec!

See below for the exact code.

The first problem is mixing implementations of template member functions. This might be because you need to specially handle certain types (like strings), while having a generic implementation for the standard types (int, bool, float, etc.).

The notation in pre g++ 4 is straightforward (if ugly)

returnType ClassName<SpecificType>::functionName(args) { specific implementation }

and

template<args>
returnType ClassName<args>::functionName(args) { generic implementation }


When I compile under g++ 4, I get this error:

main.cpp:16: error: too few template-parameter-lists


In the code below, line 16 is:

void Par<std::string>::fun(void)


Well, there is the template parameter! Right there! "std::string", it's string! What more do you want from me!

Here is the working code:

template<>
void Par<std::string>::fun(void)


Oh! Of course! Duh! I should of known that. The earlier code was obviously so ambiguous that only every compiler before g++ 4 could figure it out. I'm so glad they fixed that for me!

Here is the total code:

#include <cstdio>
#include <string>

template<typename>
class Par
{
protected:
 int x_;

public:
 Par(void) {}

 virtual void fun(void);
};

void Par<std::string>::fun(void)
{
 printf("String ver\n");
}

template<typename T>
void Par<T>::fun(void)
{
 printf("Generic ver\n");
}

int main(int argc, char **argv)
{
 Par<std::string> p1;
 p1.fun();

 Par<int> p2;
 p2.fun();

 return 0;
}

Stuff I've read lately

"The Cassini Division" (Ken Macleod) - This is actually the third book in a series. I am really enjoying Macleod. His writing is reminiscent of the "good ole days" of science fiction; with big ideas and epic happenings. And there is a good amount left to be mined here (Cassini is from 1998). Stross is writing too much fantasy (Merchants), and horror (Atrocity Archives). Scalzi has just gotten started.

The Cassini Division is a military unit stationed near Jupiter (and, apparently, a gap in the rings of Saturn). They are charged with protecting Earth (and the orbital settlements) from "post-humans", a group of people who uploaded themselves into computers and set off runaway technological progress (the "singularity").

Macleod has an interesting take on the STL/FTL problem. He uses the "hard" sci-fi notion of wormholes (paired creations, which must be moved apart at STL). However, he also allows that the moving end of the wormhole keeps its own time frame - thus, you can travel 10,000 light years (to a point 10,000 years in the future) fairly soon after the wormhole is created. Interesting stuff.

Decoys

(Continuing my musings on D)

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).

Built-in documentation:

• 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.

Design by Contract (DBC):

• 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).
  

Duck Hunt

(Continuing my thought process for considering a new language)

Nine to five, I hack C++. Not just any C++. Imagine hundreds of thousands of lines of code, spread across dozens of directories in a twisty maze. Make takes from twenty to thirty minutes (that's a parallel make, serial is over an hour), and sometimes fails in odd ways.

The program has to run on about five different compiler/platform environments (Windows, plus various forms of UNIX - including a Sparc).

Over the past few weeks, I've been running into all sorts of nasty C++ problems (weird template problems, compiler mismatches, spaghetti recompilation).

As I've been looking for solutions to the problems on the Internet, the C++ Frequently Questioned Answers keeps coming up.

The guy makes a lot of good points. And I started to wonder, does he have some constructive recommendation (besides, "Don't use C++").

It's called D.

I think, what I'm looking for isn't Python or Ruby to replace Tcl. I need something to replace C++. With features like Python or Ruby (rapid development, functional programming).

That's D.

Things are still a little fresh (spec is rapidly moving, environment issues). But considering that, it is working remarkably well. I mean, C++ is way older, and still has issues!

A good place to start is with the overview.

New Stars Status

Finally getting to the point where I can start on the battle VCR!



It took a lot of bug fixes to get to this point...

• Implemented ship to ship scanning
• Fixed bug causing battle messages between fleets the player owns
  
• Fixed a bug where planets could not see enemy ships in orbit
  
• Added a speed spinner to fleet move orders
  
• Fixed a bug when right-clicking on mixed friendly and enemy fleets in one point
  
• Fixed a bug where some fleet GUI items would appear in view planet mode
  
• Fixed widths of some widgets to fix jumpy universe view size
  
• Added previous and next buttons to the message pane
• Removed ship object id from ship names (just in fleet)
• Improvements to the scripting interface

The JOAT player is pretty well into colonizing a second planet. The War monger has no orders beyond scanning...

The battle was really anti-climatic. The current battle engine has the JOAT scout escape without a shot fired. I will need to investigate that outcome...

Need a New Duck

And show me how to get down
How to get down baby
Get it?!

Quack, Quack, Quack!

I've probably forgotten more about programming languages than most people know (since most people know zero programming! :)

Basic, Pascal, Visual Basic, C, C++, Perl, Verilog, Java, various assembly languages (including PipeWrench, don't ask), Awk, Tcl, Lex, Yacc, ML (which we all thought stood for "My Language"), VHDL.

At this point, I've pretty much settled on C++ and Tcl. (plus Perl for text processing).

Tcl is great for rapid development, and GUI design.

C++ is great for interface definition, large projects, and general hacking. I don't know Bjarne's background, but it must include a lot of hacking.

But I've been getting the feeling I need a new language.

I tried Ruby. But "everything is an object" doesn't seem any better than "everything is a string" (Tcl).

I've played with Python, but again, it doesn't really replace Tcl for me.

I've used Darcs, which is the poster child of Haskell. That's pretty much turned me off that... The other functional languages are even more obscure.

Erlang seems to have potential for the multicore future. But it seems to be different in annoying ways, "just cause".

Stuff I've read lately

"The Birth of Christianity" (John Dominic Crossan) - Reviewed on my faith blog.

"Patriots" (David Drake) - Not your typical Drake. Ok, but more character focused. He should stick to tanks and such :)

New Stars Status

Trying to work up to a battle in the two player game. I am trying to actually walk the players through their turns as they would be doing them (i.e. spending a lot of time micro-managing).

Part of that is implementing the "accelerated BBS" option (so I don't have to generate 30 turns before reaching colonization pop).

Then, I added the research tax option (visible in the dialog below). This uncovered several bugs in communicating this information from the player file to the server.



I also fixed the scanner pane so that it resizes itself to fill up the window. There is a somewhat annoying flicker as you click from explored to unexplored planets (due to different widths on the left)...

I also found/fixed a bug for JOAT w/o IFE getting Quick Jump 5 instead of Long Hump 6 (IFE properly gives the Fuel Mizer).

As well as a bug in the growth formula when planets exceed 25% capacity (aided by AccBBS).

Interesting note, on Linux, the two players are right next to each other. That means I can use it for some quick battles (and I need to fix the homeworld placement logic...)

Stuff I've read lately

"Dark Light" (Ken Macleod) - Sequel to "Cosmonaut Keep". Very short, but pretty good. Follows the adventures of the previous characters on a planet some light years from the last (they got their light drive working). The libraries here don't have the third book...

"In My Place Condemned He Stood" (J. I. Packer and Mark Dever) - Reviewed on my faith blog.

New Stars Status

Started in on more bugs:




Here we can see the new universe caused by fixing the randomization of the hab distributions. I also added the player relation dialog, and changed the underlying implementation. With those changes done, I can revamp the battle engine - in preparation for the battle VCR.

I also fixed some of the automation, to improve fuel consumption during scouting missions.

I looked into the fails during generation huge universe (dense and packed). They are running out of planet names. We will need to generate another 1k names...

Stuff I've read lately

"Cosmonaut Keep" (Ken Macleod) - This is some of the best space opera I've read in a long time. Really what I've been looking for lately. Reminds me more of Asimov, and the like. The story is a little confusing at first, because it covers two time frames: the first is in the future on a distant planet, where humans and aliens live together; the second is the near future, where humans make first contact with the aliens.

I look forward to the next book, "Dark Light".

New Stars Status

I started in on some of the bugs:


Here we can see the new fleet composition pane. I still need to connect the "battle plan", "estimated range", and "cloak" areas. Also, I need to add a drop down with other fleets in this location (for fleet to fleet transfers). I also need to implement the Split/Merge buttons.

I also fixed the "close enough" check when adding waypoints. That was one of the first features in the GUI, when the canvas had a lot fewer things floating around. At some point, all the new canvas objects threw off the logic. It should work much better now. I also fixed the "redraw paths on delete" bug.

Then there is the production queue. I fixed the "remove all" problem mentioned, and improved the checks which combine nearby items. Also, the production queue and waypoints list should behave better when adding multiple (always inserting at end, rather than sometimes at the beginning).


I looked into the research tax. It is a top level XML thing, so I may want to adjust that through the C++ interface. I also gathered some data on the hab distribution. It is looking fairly flat. I want to gather a few more data points to be sure... I also started on handling shift and control down, but that will need more effort.


I'm not entirely happy with where this check in is (should have a few more features), but the code has been this way since Saturday (IIRC) and I haven't had a chance to work on it, and might not for a few days...

New Stars Status

Some more operative bugs (and much needed new features):

1. Floating-point exception while generating a huge universe (names underflow?)
2. Need a redraw of paths on delete waypoint
3. Waypoints always insert at 0 (should be end)
4. Fix close enough on shift-click (canvas is returning a list?)
5. Feature - drag waypoints
6. Need to clear the current filename on open (fixed locally)
7. Feature - recent files, remember working directory (.ini)
8. Production Queue (PQ) - shift/control click, hot keys
9. Generate player files automatically on new game
10. PQ - "Remove" removes all on a multiple item!
11. Messages on planetary build (will need filter!)
12. Research tax in GUI
13. Ship Designer - delete needs a refresh
14. PQ - collect ships above and below on add
15. Messages for fleet complete orders and new planet scans
16. Feature - View all fleets (F3)
17. Feature - Fleet composition and split/merge
18. Scanner pane focus arrow, update on next (fleet/planet)
19. Hab distribution is uniform
20. Speed and fuel in fleet orders
    

Stuff I've read lately

"God and Religion" (Bertrand Russell) - Reviewed on my faith blog.

"Surprised by Hope" (N.T. Wright) - Reviewed on my faith blog.

"Introduction to Christianity" (Joseph Cardinal Ratzinger) - Reviewed on my faith blog.

"Agent to the Stars" (John Scalzi) - I'm running out of Scalzi and Stross to read at the local library. I had actually seen this book. But the cover art is really bad. I didn't even realize it was science fiction. I found the text online, and read a bit, and realized it is sci-fi, and classic Scalzi. Very enjoyable.

New Stars Status

Trying to crush off the bugs from the last bug report...


Here we can see the main fixes. I've added a player command to the Tcl interface, mainly to implement player relations. However, I think the main player relation code will need to be reworked...

I also fixed the mining rate calculation, and max defenses calculation (and the resources now say max/max instead of 0/max).

I also added some menus (view race - previously only accessible through F8, research - ditto/F5, battle plans - stub, change password - stub).

I fixed a bug where using the race wizard would break viewing your current game race, and another where planetary resources display as 0 on the first turn.

Stuff I've read lately

"Halting State" (Charles Stross) - This is very near future fiction, about 10 years out. It is basically a mystery/spy thriller featuring a nerdy programmer and an accountant. I found it pretty well done. The zombie flash mob at the end was a nice touch.