Hey, it works!

Earlier, I determined that I would need to implement just a few more functions in C++ to get a bare-bones version of my cellular automaton (CA) program working. Here's a list of the necessary functions:

• countNeighbors
• cellNextgen
• updateCAMatrix
• a 2D vector to hold the ruleset information

 I wrote out the functions using pencil and paper. True to my past performance, none of them ran as written on paper. One of these days, I'll get it right from the get-go. Whatever. At least I was correct in that these were the functions required get the job done. At the end of a small hack-a-thon, I was left with a working, bare-bones version of Conway's Game of life. I decided not to fill the blog up with too much source code. If you're interested, the source code is available here on launchpad. I'll only add code snippets as necessary, or when I just feel like it.

Next on the agenda is implementing:

• Toroidal surface version.
• Single step mode.
• Start pattern file input.

The nice thing about C++ is that it is faster than Python. In this case, the C++ version of the CA program is much, much faster than the Python version. It's so much faster that I want to take another look at my Python code to see if there's something amiss. I think C++  is my new language of choice for sound and graphics.

The downside is that C++ is more painful for me to code in. Part of it is my ignorance, and part of it is just the nature of C++. I studied things like "pass by reference", "pass by value" and "dynamic memory allocation" in school, and I quickly left them behind because I was an electrical engineering student, studying other topics. Now that I've started writing more code, and I'm beginning to use C++, I have to start paying attention to these things.

Python is free and easy language. Python has automatic memory management (garbage collection), while in C++ the programmer must take out the trash. C++ has static typing; Python has dynamic typing. C++ is compiled; Python is interpreted. These differences make Python much easier to use, which means it is much faster to write code in. C++ is more painful to code in, but it sure runs fast. The C++ CA program runs so fast compared to Python version that I think it's worth the trouble of climbing the C++ learning curve. And what a steep curve it is! This is going to take a while.

One problem that I notice when asking Google how to do things with C++ is the widespread use of C idioms and libraries to solve problems in C++. While C++ was developed from C, and can run almost everything just like C, it also has a number of distinctly C++ ways of handling tasks. It seems that so many C coders segued into C++ they carried many of their C solutions into C++ code. For example, I wanted to convert some text into an integer. Google shows that many people would use a C method:

...

#include <stdlib.h>

...

...

int myint;

char *mystring;

...

myint = atoi(mystring)

...

which works just fine in C++. It's just that C++ has another way, a native C++ way to do the same thing.
        ...
        #include <string>
        #include <sstream>

        using namespace std;
        ...
        ...
        int myint;
        string mystring;
        stringtream ss;
        stringstream ss;
        ...
        ...
        ss << mystring;
        ss >> myint;

I don't have a big problem with using C idioms in C++; it's just that while studying Python I found it best to write Python code in Python, not translated Scheme or C. I suspect that this will hold true in C++ as well.  While it's true for this example the C code is nice and concise, the C++ version is pretty flexible and can do some interesting things. For example, it could parse a long string of whitespace separated items, and deposit each item into a separate variable. The variables could have varying types, if desired. The infrastructure is already there. I'm just learning this C++ stuff, but it seems to me that you might not always want to immediately just grab a tool from C to tackle a problem in C++.

Another problem is C++ has changed over the years. If in searching for C++ wisdom you see something like #include in sample code, go somewhere else. That does not work anymore, and hasn't for a while.

I've been working through Lazy Foo's Beginning Game Programming tutorials. These tutorials are using Simple Directmedia Layer  so they are of great interest to me. I highly recommend them. I got a copy of Programming Linux Games:  Building Multimedia Applications with SDL, OpenAL(tm), and Other APIs by Loki Software, Inc. with John R. Hall. These days I don't buy too many computer books because they are expensive, often quickly obsolete and just do not give you a lot of bang for your buck. I mean, Google is pretty good at answering questions about computing, and my local library has beau coup books on the subject, as well as a subscription to Safari Books Online. I made an exception for this book, because it's from the people who developed SDL, and the excerpts looked pretty good. Now that I have it in my hands, I glad I spent the money. It's a little old (I think some things have changed with SDL since the book was written), but it's still pretty solid.

Sadly, the author, John R. Hall, is now blessed memory. He died way too young. My condolences to his family and friends.