STL::collapse

A simple addition to C (variable length arrays using the [] notation), allows the removal of std::string and std::vector.

The question becomes, "how much do we really need from STL"?

From personal experience, the most used classes are std::string, and std::vector. The next is probably std::map (although std::list is handy, but vector can do most of it). Keep in mind, Tcl gets by with just string and maps of strings to strings...

D uses a simple concept to add maps.

char[][char[]] strStrMap; // a map from string to string
int[int]       intIntMap; // a map from int to int
char[][int]    intStrMap; // a map from int to string

The usage is just like it looks:

strStrMap["hello"] = "world";
intintMap[6] = 4; // Craw Giant
intStrMap[0] = "trample";

Native Vector

I think the D Faq makes my point for me:

"the implementation of a string type in STL is over two thousand lines of code, using every advanced feature of templates. How much confidence can you have that this is all working correctly, how do you fix it if it is not, what do you do with the notoriously inscrutable error messages when there's an error using it, how can you be sure you are using it correctly"

Vectors are built in to D:

char str1[8]; // eight chars, enough to hold a string of length 7 and the 0 terminator
char str2[]; // a variable size string
char *str3; // a C style unknown length string

D strings are not NULL terminated (although string literals are given an extra NULL byte so that they can easily be used as C strings). This allows substrings to be referenced in situ. String length is determined using the vector length.

D is also able to avoid a pitfall of Java. When Java was developed, Unicode was all the rage. So, strings in Java are all Unicode (2 bytes). That means every string is taking up twice the memory of a C string.

D uses UTF-8 (which I've only learned of recently, Wikipedia says it was first presented in 1993 - Java was started in 1991). That means we can get all the juiciness of foreign characters sets (Hebrew and Greek being of interest to me lately), without the 2x memory penalty.

Native String

The lack of native support for strings in C++ was a determined decision on the part of Stroustrup (I'd love to read his book on the history of the development of C++).

It is largely this decision which has made C++ everything it is (good and bad). Templates are driven by the need to implement vectors, so that strings can be vector<char> (or vector<short> for unicode). Allocation and comparison get added to the template implementation, which requires default parameters. Horribly long and ugly template definitions (std::vector<char, std::alocator, std::traits<char> >::basic_function, etc.) lead to changes in error detection and reporting.

What if we take a step back.

What if we look at a few simple additions to C, that will bring in some of the functionality people have come to enjoy in higher level languages (and what functionality is "good", how do we define "good").

std::string

I was reading the Daily WTF (which is can be a great learning resource on the potential horrors of any programming language and development system).

I saw the most incredible claim, "C/C++ has no native support for such a structure [strings]. It's only in the STL.".

Err, yea, it's hard to do C++ nowadays without the STL.

You might think this code won't work:

std::string arg("Hi me");
if( "Hi me" == arg ) { printf("Yup"); }

But it resolves to

operator==(const char*, std::string &);

Of course it leads to the horror I have to deal with:

Ret myFun(const char *charp)
{
   FX::FXString foxStr(charp);
   randomFoxFun(&foxStr);

   std::string stlStr(foxStr.text());
   randomStlFun(&stlStr);

   // convert STL string to Fox String
   // convert STL string to char*
}

Stuff I've read lately

"March Upcountry" (John Ringo and David Weber) - I was looking for more John Ringo. This series is in the library under Weber. I wasn't sure if it would be more Weber or Ringo. I would say it is more Ringo's style. Straight up marines slogging through enemy territory. Well done.

Stuff I've read lately

"Manxome Foe" (John Ringo) - This is the third book in the "Into the Looking Glass" series. This is really excellent space opera. Ringo is pacing himself nicely - I think he will be able to avoid painting himself into a corner (ala Peter Hamilton's Reality Dysfunction). Good space combat and marine boarding action scenes. The right mix of humor and seriousness.

Stuff I've read lately

"Ghost" (John Ringo) - I wasn't happy with this one. More Tom Clancy than SF. Also, the whole middle of the book is like a weird ad for kinky sex. Not sure what Ringo was trying for. But, I guess you have to give extra points for the main character killing Osama Bin Laden and sending his head to President Bush...

Stuff I've read lately

"Von Neumann's War" (John Ringo) - This is a standalone novel. It covers an invasion of the solar system by self-replicating robots (ala a proposal by Von Neumann for a method for us to explore the galaxy). Fortunately for us, the probes programmers didn't expect concerted, intelligent opposition - humans are able to reprogram them just in time to prevent our extermination. Think "Independence Day", with more marines and less Jeff Goldblum.

Stuff I've read lately

"Vorpal Blade" (John Ringo) - This is the second book in the series starting with "Into the Looking Glass". Ringo is doing an excellent job of building up a rather unique space opera universe. Pretty hard SF, with good characters and the right mix of humor (like, a giant alien squid trying to eat their space going submarine!). I'm looking forward to more.

Stuff I've read lately

"The Family Trade" (Charles Stross) - I have been loathe to start in to these, as they are marked "Fantasy". I haven't read any fantasy in a long time (in all starts to be the same after a while). Sadly, Stross seems determined to continue this series...

That said, this book feels a lot like a hard SF version of "Chronicles of Amber" - so, that's good. For example, once the main character gets back from her first "hell ride", she starts planning all sorts of experiments and evidence gathering!

New Stars Status

Some big changes in store (not much visually...)



Here we can see the recent files list. It does not re-sort when you select a previous file (I am undecided whether that is a good feature or if some sort of better LRU might be nice).

I also fixed the C++ code to use 64 bit numbers when interfacing to Tcl. I think that just went in to Tcl 8.4. That will get things ready for the object id redux.

Finally, I fixed the new game wizard to actually generate the turn files when you start a new game. That is much better than having to save out the new game def, switch to a terminal, and do a 'newStars -n', then switching back to the client...

Stuff I've read lately

"Into the Looking Glass" (John Ringo) - This is the first book by Ringo that I have read. It was pretty good. Kind of a mix of David Drake and some harder SF guy (Niven?). The story is about a physics experiment gone horribly wrong. The initial experiment blows up UCF, and starts opening stargates to all sorts of different places. Soon, evil aliens start pouring through some of them. Lots of action. In the end, they have to nuke Eustis.

Ringo had an interesting weapon system, a "quarkium bomb" or "quark ray". The exact mechanics weren't clear, but it was supposed to be more powerful than anti-matter. So, it can't be that the quarks are the direct objects converting to energy at the target (that would be equally powerful). Perhaps there is some way a form of quarks could trigger a chain reaction of disrupting nuclei. That would be scary...

Tcl and Ini files

The NewStars client GUI is proceeding pretty well. I am finally getting tired of navigating from the client start directory to the regression directory (up two! src/testfiles/twop).

This is the implementation for the "Recent file list" in Tcl:

Create the resource file if it doesn't exist, or process it if it does:

if {![file exists [file join ~ $resourceFileName]]} {
   close [open [file join ~ $resourceFileName] w]
} else {
   eval [read [open [file join ~ $resourceFileName]]]
}

The ini file is a series of Tcl statements. That way, I can just "eval" the file to bring it in.

Then to handle saving the preferences:

rename exit origExit
proc exit {} {
   set f [open [file join ~ $::resourceFileName] w]
   foreach n [lsort [array names nsGui::prevFiles]] {
      puts $f "set nsGui::prevFiles($n) \{$nsGui::prevFiles($n)\}"
   }
   origExit
}

The previous files is a map from the numbers ("1" to "9") to full path filenames. I can grab all the set values (which may be none) and write them out to that file.

By renaming "exit", I can trap any point in the program that is trying to exit. That way, I'm sure that the preferences are saved.

Improving C

A lot of programming languages have been inspired by C. I can easily list C++, Java, and D; there's probably more (Wikipedia lists Perl, I think Perl is a very different sort of C - and Python and Ruby feel more like cleaned up Perl. I always thought of JavaScript as more like VisualBasic, which is more Pascal-ish - Pascal being a sibling of C, both derived from Algol). There is a pretty cool family tree of programming languages, which shows Python as independent of Perl. I'm not too familiar with Python...

C is a pretty good language. Developed in 1972, it served as a sort of "cross platform assembly language". It allowed UNIX to spread to many different computer systems and provided fertile ground for thousands of hackers.

The main problem with C is the lack of support for object inheritance (you can actually do object oriented programming, but it is kind of a pain). But to implement object inheritance, you must relax pointer conversion warnings (I'm not sure how strict modern C compilers are on pointer conversion, C is classically very relaxed).

The other problem is the lack of generic programming, sometimes called template programming. This allows one set of code to work with various underlying types. The most obvious application is in basic data structures and common algorithms (vector, map, sort). Sorting through void* and size is kind of a pain...

Language is a Tool

Is it right to make fun of a programming language? I mean, "it's just a tool". That's what everyone says. You don't mock a hammer for not being a screwdriver (although screwdrivers can be usable hammers ;)

Of course, language is more than a tool.

It is also a means of communication, which means that you've got multiple entities involved.

The main communication is from the programmer to the computer. That means:

• The programmer needs to be able to express himself efficiently (in a matter which makes sense to him, in a reasonable amount of time)


• The computer needs to be able to understand (computers are really bad at English! and not just because English is a terrible language for specifications!)

But, programmers also communicate with one another. If I write all my programs in Tcl, not many other programmers can read them. That's a big part of the "more than a tool". If someone develops the "super monkey hammer" that can build a house in a day, but only super-monkey-hammer technicians can change the light bulbs; people are going to be frustrated.

Steam INNN SPAAACE!

So, I've been thinking about the space elevator, mostly about powering the climbers. Everyone seems to be backing laser power (using ground based lasers to shine on solar panels on the climber).

And, I've been reading Ken Macleod's "Fall Revolution" books, which have "steam launched spaceships". I read them completely out of order, so I never got any details. There is a little in "The Space Fraction".

After looking into it more, I found an excellent source. "Steam" propulsion is somewhat of an exaggeration. The recommended propellants are hydrogen and nitrogen. Water is possible, but not optimal.

But pretty cool, for small scale, high volume launch capacity.

New Stars Status

Tada!


A lot of visual changes!

• Fixed a bug in the defenses calculation (max at 100, please!)
• Implemented hab view mode (circles represent current hab value, flags show ownership)
• Fixed unexplored planets to show gray (both views)
• Fixed the bug I knew would be there when removing too much
• Fixed a bug when adding multiple items to the top of the queue (visual bug, data was ok)
• Fixed the mineral labels to be colored (iron - blue, etc). I made the germanium one more gold than yellow. I find that yellow hard to read...
• Added view planet window (shown, missing mining rates, capacity, hab value, and production queue right now...)
  

Stuff I've read lately

"The Star Fraction" (Ken Macleod) - This is apparently the first in the "Fall Revolution" series. I didn't find anything new and incredible in here. It did give a little more insight into the "steam rockets" mentioned in the other books. That is worthy of its own research...

I Love Tcl

So, I have been grinding through a lot of GUI code (NewStars update coming soon!)...

In the process, I have been shifting code from C++ to direct XML access. Part of this involves something called "XPath" (which I had never heard of before).

The key is, you can query an XML document like a database (including wildcard and logical test patterns). So, if I want the node with the planet with object id stored in variable 'pid', I can do:

set n [$nsGui::turnRoot selectNodes //PLANET_LIST/PLANET\[OBJECTID=$pid\]]

'//' means a relative search (not necessarily from the root). I need "PLANET_LIST" because there is another list of planets, called "UNIVERSE_PLANET_LIST". The outer square bracked "[]" are part of Tcl (execute this part, and resolve it to the string that is returned). The inner (escaped) brackets are part of XPath (return nodes which satisfy "[logical_condition]").

Of course, any language can support XPath. But, in Tcl, I can open a console session, source the stars.tcl, and start issuing XPath commands against the turn file. That allows me to rapidly tune my request to get the results I want (eliminating the compile/re-run steps). Especially since the W3C XPath docs are unreadable...

Then, once I have the planet node, I can pick off attributes:
set concs [$n selectNodes string(MINERALCONCENTRATIONS/text())]

That replaces:
set planXML [xml2list [newStars $::ns_planet $id $::ns_getXML]]
set mainXML [lindex $planXML 2]
set cargoXML [findXMLbyTag "CARGOMANIFEST" $mainXML 2]
set tuple [lindex $cargoXML 1]

Especially since that used "xml2list", which can't always parse some XML...

Const Fail

I only recently discovered an oddity in the C++ "const" feature. Consider this code:

class Foo
{
 int *i;

 void foo(void) const
 {
    *i = 4;
 }
};

(I've left out some boiler plate)

Anyone see it? A const function is changing the state of the object!

Oops, turns out C++ const is not "transitive" (the D docs call it "head const").

This bit me big time on my previous project. To the point that I developed a "const pointer" class to wrap all my pointers (only got partially deployed into the project).

D 1.0 lacks const (because it is hard to get right, witness C++). D 2.0 wants const done right.

Also, there is a great slam on Java and const. (I can't help myself when it comes to slams on Java! :) Yea, no const for you Java-kins!