Scriptionary Blog

The upcoming C++ revision, C++0x has been delayed and is now scheduled for release somewhere in the 2010’s, thus effectively becoming C++1x.

Here’s a link to an article published in Dr. Dobbs Journal by C++’s creator Bjarne Stroustrup explaining why (page 3).

I don’t think anyone is really surprised with the delay as the new standard would lift C++ up to a more modern level in order compete with contemporary programming languages, thereby implementing much addendum. The list of new features and STL additions is certainly impressive and when C++0x, er, C++1x is released, we’ll probably all need to brush up on our C++ skills.

I don’t know how many times I’ve ran into people that need help with a piece of C code that should run perfectly fine but for some reason it just doesn’t. Of course, after much going back and forward, you find out that the person you’re trying to help is using Borland’s Turbo C compiler version 2.01, released 20 years ago in 1989..

While the compiler is freely download-able from several websites labeled as an “Antique”, it’s really not a great tool to start programming with on modern systems. If you really (really) want to use Turbo C, buy an old 286 and go at it but don’t use your Intel Core i7. Here’s why. PS, this also applies to Turbo C++

1. The compiler is 20 years old, it won’t support the current C99 standard so many things you might have learned, you now have to unlearn in order to get the program working.

2. Turbo C is an MS-DOS compiler, chances are if you are learning C now, you have never used DOS in your life; there’s no reason to go back, nostalgia doesn’t apply to DOS. Furthermore, Windows does not support DOS programs from the 80’s, so you would have to emulate DOS in order to get your programs working properly.

3. There are many free compilers available that are 100% compatible with today’s hardware and not bound by any limitations. Even if your Turbo C compiler is 32 bit compatible, it’s not a great match for your 64 bit CPU and Operating System.

4. You’re stuck on the command line interface with no way out. Even if you make the best command line program for DOS, nobody besides yourself will ever want to use it. Converting your program to Win32 requires a new compiler that will yell at you for using coding practices from 1989 and break your program.

In other words, if the following code compiles without warning, you know you need another compiler.

#include <stdio.h>

main()
{
    printf("Hello, World!");
}

Even though I prefer my web servers to run Linux, I just can’t seem to switch my personal computer to Linux just yet. From an end-user standpoint, Linux is still very rough around the edges, here’s my personal checklist (in no particular order) that I’d like to see fulfilled.

• The ability to install a piece of software without having to invoke a CLI.
• A full-featured development environment (that’s not Eclipse) that rivals Visual Studio in C++ development.
• A non-Unix-like file system.
• Better manual when you buy a distribution (SUSE manual: case and point).
• Better IHV driver support.
• Better native ISV software support without having to run Wine.
• And the coup de grâce: An OpenGL specification that can compete with Direct3D.

Don’t get me wrong, I have nothing against Linux itself, in fact much of my development time goes into LAMP related work. But for the desktop it just seems like a CLI-ridden nightmare at the moment.

There are several articles gathering dust bunnies on the internet on creating a scene graph class in C++ for your 3D engine but most are pretty vague and quite old. Hopefully, this post will give you a foot in the door in creating your own scene graph for your engine.

To start off, let’s go over some basics. A scene graph is a tree-like data structure which holds information about the scene you want to display. Every node has a parent and every node may have children. In this post we’ll use the std::vector to store the scene nodes but you can substitute this with whatever you want. A scene graph can be visualized like so:

             [root node]
                  |
        o=========o=========o
        |         |         |
    [child 1] [child 2] [child 3]
        |
    o===o====o
    |        |
[child 4][child 5]
             |
         [child 6]

Any node may have any number of children who’s children may have any number of children, etc. Each node in the scene graph may have a name for lookup functionality so a very lookup system will be implemented. We will also need functionality to add a child node, remove a child node, set/get a node’s parent and an update function for updating the graph hierarchically.
Read the rest of this entry »

I’ve recently had the need to read an entire file into a byte array but still had the need to extract integers from it. Turns out, it’s very possible to do this but platform dependently since the byte-ordering (or endianness) on different machines can differ.

For example, Little-Endian machine A has an integer that it needs to write to disk: 12345. Big-Endian machine B has the same integer that it needs to write to disk as well.

The hexadecimal representation of the file on machine A would look like: 00 00 30 39 while machine B’s output would look like: 39 30 00 00.

If we were to read machine A’s file on machine B, the output would not be 12345 as expected but 245618442240 instead. Now that’s quite a problem. Any file written on machine A would be useless in any other environment.

In the meantime, be aware that there’s no way to determine if a file is Big or Little Endian so you would need to set a standard for your file. I use Little-Endian byte ordering since that’s my machine’s native format and 99% of the time, yours as the x86 family of processors is Little-Endian.

So in order to read any of the files we have on disk, regardless of endianness, we first need to detect the endianness of our current machine and somehow detect the endianness of the file we’re trying to read. This is not a big pain in the ass as you might suspect since machines, in addition to files, also order their memory in Big- or Little-Endian byte ordering.
Read the rest of this entry »

Maybe this news is a bit old but Visual Studio 2010 CTP was released, you can get it at the following location:

Visual Studio 2010 CTP Site

For you who don’t know, CTP means Community Technology Preview and can almost be regarded as a public beta version.

For C/C++ developers, you can find more info on the next version of Visual C++ 2010 on the Visual C++ Team Blog. I’m glad to see that IntelliSense for VC++ is being improved since in 2008/2005 it’s a quite horrible technology. This version also has support for some C++0x functionality.

First of all, I have to mention that this colleague has been a C and ASM programmer for most of his lengthy professional career, I won’t mention his name here but let’s just call him “Joe the Programmer” in light of current braindead naming schemes.

Joe the Programmer recently started programming with the .NET framework but yesterday came to a stop. When he was asked to help out with .NET development using ASP.NET, he took some time and to his amazement couldn’t find the ASP.NET programming language in the Visual Studio “new project” dialog.

At first this made me chuckle and I brushed it off, but then I realized he was correct to assume that there should be an ASP.NET programming language. After all, there used to be an ASP programming language although it looked suspiciously much like BASIC.

After explaining that ASP.NET is not as much a language but a technology, he went on his way and continued programming.

This all made me think that maybe the name, ASP.NET, is ambiguous, vague and might be a concept difficult to grasp for guys like Joe the Programmer. I just hope that he has a concept of OOP to go along with his newly found knowledge of ASP.NET.

Here’s another little snippet that might come in handy in your programmatic travels. I’ll show you an example of usage below, which might also be of interest to you. The code presented is in C, not C++. First, the code to count the amount of digits in an integer:

const size_t intlen(long long int Num)
{
	size_t out = 1;
	while (Num /= 10) ++out;
	return out;
}; // numlen

Looks simple enough; simply count the amount of times we can divide the number by 10 without the result being zero. This function takes a copy of an int (or long long) so that we don’t have to copy the number inside the body of the function and returns a size_t (unsigned int).

As for the usage example, it’s a bit more complex and might seem a bit “obfuscated” at first, but fear not, I will explain below.

void inttoa(long long int Num, char** RetVal)
{
	size_t neg = (Num < 0);
	size_t len = intlen(Num) + (neg ? 1 : 0); // add one for the "-" character
	size_t i;

	*RetVal = (char *) malloc(sizeof(char) * (len + 1));

	if (NULL == (*RetVal))
		return; // bad malloc

	if (neg)
		Num = -Num; // make pos if neg

	for (i = len; i; (Num /= 10), --i) // loop backwards
		(*RetVal)[i-1] = (char)((Num % 10) + '0'); // add modulo to char zero

	if (neg)
		(*RetVal)[0] = '-'; // first char

	(*RetVal)[len] = 0; // last char, null terminator
}; // intttoa

As you might have suspected, this function converts an integer to character string. First, we determine if the number is negative and retrieve its length with the help of the previous function. We allocate a character string with the length determined and start appending a character to the string.

You can use it like so:

char* mystring; // don't allocate, don't do anything
inttoa(42, &mystring); // simply pass it to the function

// do things with the string

free(mystring); // you *do* have to free() the string though