Programming Matters

From the D website,

“D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

D is statically typed, and compiles direct to native code. It’s multiparadigm: supporting imperative, object oriented, and template metaprogramming styles. It’s a member of the C syntax family, and its look and feel is very close to C++’s.”

This language first piqued my interest about 2 years ago. At the time I saw it as a great idea but wanted to wait to see if it would catch on at all. Since then I have been hearing about it from time to time and finally decided it was time to take a close look. And I’m really glad I did.

This article mainly compares C++ to D from the perspective of what C++ is missing that D has. If you haven’t read my last article about what I love about C++, you’ll probably want to do that first.

Favorite additions C++ is missing:

1. Garbage Collection – this is almost always faster and more efficient use of runtime cycles and the developer’s development cycles; a total no-brainer in most cases. You can do manual memory allocation when you think you know better.
2. Nested functions – The nested function has full access to the local variables of the function it is nested in. Being able to break up large functions in the scope of the calling function makes things sensible and clean.

3. Inner (adaptor) classes – Nested classes support access to the variable scope of the calling class. Use a static nested class to prohibit access.

4. Properties – Being able to use the syntactic sugar of values with underlying functions makes good sense. Why shouldn’t value be able to be abstracted out and have underlying functions?

5. foreach – cycle through all the elements and let the compiler decide the most efficient way.

6. Implicit Type Inference – this is coming to C# soon as well. It’s nice not to have to specify the type when it is already specified by what it it’s being set equal to.

7. Strong typedefs – This one is especially nice. You want to create a typedef that isn’t considered the same as the original as function signatures are concerned. C++ forces you to create a class to do this thing that should be simple.

8. Contract Programming – puts your in and out contract constraints into the code in a clean, consistent way. The compiler can now better optimize and inherit contract constraints.

9. Unit testing – makes it simple to include unit tests directly within each class to validate it.

10. Static construction order – Being able to explicitly define in what order static objects are created in shouldn’t be too much to ask. I’ve seen more than a few projects bit by this in C++. In C++ you have no guarantee when statics will be initialized. Interdependencies in C++ can leave you shaking your head as you unravel the evil.

11. Guaranteed initialization – you have to explicitly say that you want no initialization for performance reasons. 95% of the time not initializing is a mistake – let the compiler do it for you.

12. No Macro text preprocessor – the source of so much potential ugliness – gone!

13. Built-in strings – sure the STL has them but being built in to the language certainly seems like a reasonable way to go.

14. Array bounds checking – built in support for checking bounds on all arrays. Turn it on or off – very nice. How many times in C++ have you wished you could flip a switch and make sure nothing was going out of range at runtime. Maybe you should use the STL all the time, but I don’t know anyone who doesn’t use built in arrays at least some of the time.

Nice to haves C++ is missing:

1. Function delegates – a convenient way to point at member functions.

2. Resizable arrays – being built in to the language is the way to go for such a basic operation.
3. Array slicing – another minor convenience.

4. Associative arrays – an STL plus that is built in to the language.

5. String switches – its definitely convenient at times.

6. Thread synchronization primitives – with the prevalence of threads having basic sync support in the language is a timesaver.

7. Typesafe variadic arguments – gets around C++ clunky access to an unknown number of arguments.

8. Documentation comments – a consistent way of documenting code.

9. Try-catch-finally blocks – I’m still not a big fan of exceptions. I blame it on my background in game programming.

There are more advantages over C++, but I just wanted to mention a few of the highlights.
For a complete comparison of D vs. C, C++, C# and Java go to the D website’s comparison

Doing a little deeper digging under the covers I found a few things I didn’t like – and one was a deal-breaker.

First of all – all classes in each module have access to each others private data. There is no way to turn this off. This forces a loss of encapsulation – a concept i don’t agree with.

Unfortunately the dealbreaker that would make me prefer Managed C++ from Microsoft over D is the lack of interop with C++. D is very proud of it’s simple interop with C. But unlike Microsoft’s Managed C++, D requires cumbersome mechanisms to interop with C++. This is extremely unfortunate and leaves me wishing the C++ standards commitee would make C++ over time more like D.

All in all, D appears to be a very promising language with much to offer. With more straightforward support for coexisting with C++, I would think it would be a shoe-in to eventually gain mainstream popularity. It seems very suitable for performace based coding across multiple platforms. It certainly might be possible to use an auto-wrapper generater like SWIG to bridge C++ libraries to D.

I will admit that I have only given D a laymen’s overview. I haven’t coded at length in it yet. However I think I’ll end up coding lower level constructs in C++ and using C# for higher level garbage collected code.

In my mind D is a pleasant surprise but doesn’t quite fit the bill. I would love to see more convenient interfacing with C++ to the extent that such seemless interfacing is feasible.

This article is actually a precursor to my article on the D programming language. I lay the foundations for my interest in D by talking about what I love about C++.

I have been coding in C++ for a long time now. Even though from the start the language had certain warts I didn’t like, certain aspects of it were irresistable to me and made it top dog.

1. An expressive language – Once learned, few languages are intrinsically as expressive as C++. It has a million nuances (like the English language) that somehow make expressing exactly what you want to say seem easier than other languages. Having true const support, multiple inheritance (in those rare circumstances where it makes sense) and references that can never be null are just a few of the unqiue ways that it supports saying exactly what you mean. Even if saying it sometimes may seem to the novice a little verbose and complicated. How many times have you checked for null in a Java or C# program and gritted your teeth knowing that the value should in fact NEVER be null. In C++ once you define a reference you have made a contract with the compiler expressing your intent. The language spec will not let you check for null.
2. Multi-paradigm – A Even though 10 years ago I jumped on the OO paradigm in a big way, single paradigm language never could quite cut it. Even though generics exist in other languages, few are as strong as C++. Simpler, yes. Powerful, no. Support for objects and generics is a must in my book. Supporting a simple functional style is important as well. Some concepts in the real world are both functional and freestanding. Granted – it is rare that I use freestanding functions, but there are times when they can reduce coupling in a big way. In object-insistant languages you are forced to wrap these guys in a class to “objectify” them. This is silly at best.

3. Supporting low level constucts – someday this will go away. But doing a good amount of 3D coding I still like to be able to optimise things pretty tightly sometimes. The day has come and gone when assembly or flat C was a must in this category. But C++ is still very useful in this way.

4. Huge opensource support – let’s face it C & C++ are still the reigning kings here.

5. Ability to interface with C & C++ effortlessly – given this “isn’t quite fair”. Of course C++ works well with C and C++. This is important because of #4. Many langauges support clumsy bindings to C++ and C and this adds a layer of inconvenience to “get at” the wealth of opensource code already out there.
Many other aspects of C++ have been absorbed by other languages. I like the availibility of generics. Being able to force strong typing when it is important is key to me – like const correctness. You know exactly what you want. Being able to also use generics and avoid strong typing is equally important. Your intent is clear. C# is a close runner up for me in many respects – the two main things that makes it difficult to fully embrace include clumsy bindings with C++ and its lack of ubiquity on other platforms. The thought of writing a large body of code in C# and then having to rewrite it for say the Wii or a handheld makes me cringe. Mono may help, but as far as I’m aware the jury is STILL out on how widely accepted it will be.

For the certain types of coding C++ is still essential to me. It’s a love hate relationship. I look forward to the day when everything I enjoy about C++ is in a language that removes the things I truly dislike.

In this article’s follow up I’ll talk about the D programming language. You might be pleasantly surprised by what it brings to the table. There I will mention the things that D does right and C++ clearly does not.

I get a lot of questions about scenegraphs and 3D development. Many people either aren’t sure what they are or have misconceptions about them. For this article I will explain the concept of scenegraphs from the standpoint of OpenSceneGraph, an amazing opensource scenegraph inspired by the granddaddy of the modern scenegraph – SGI’s Performer. For purposes of this article I will use the terms OpenSceneGraph and scenegraph interchangeably in many places. It is beyond the scope of this article to explain all possible permutations of the scenegraph concept.

Standard graphics objects and a spatial graph

At their heart, scenegraphs are nothing more than a graph of nodes representing the spatial layout of a 3D scene while encapsulating primitive graphic characteristics in objects. This sums up the two greatest strengths of the scenegraph – spatial organization for culling and encapsulating graphics characteristics in a data format.

Standard graphics objects

Why is this such a great thing?

When model data is read into memory to be utilized in OpenGL or Direct3D using non-scenegraph solutions, proprietary formats are often used that are suited to the exact needs of the application. While this isn’t a bad thing in many respects, it makes it difficult to impossible to grab libraries and pieces of code you need from sources and use them without significant modification. Many times graphics programmers will see a technique they like and be forced to dig into the code and rewire things to work with there data structures. Scene graphics enable users to create code that works with the basic object primitives out of the box. This can quickly lead to a huge amount of code that is available for just about any graphics technique or purpose, ready to use out of the box.

Many ask, “What if you choose the wrong data format for these objects? Why is one superior to another? Scenegraphs choose a format that encapsulates the lowest level graphics primitives and states into unique objects. These objects are combined in the graph to visualize anything that can be procedurally generated in a lower level graphics API. Various graphics states such as material attributes, blend modes, textures, etc. each have a corresponding object that is applied when the scenegraph itself is drawn. Because of this flexible “standardizing” of basic graphics operations it is both possible to represent most anything the graphics sub-system can create as well as allowing new objects to be built to utilize them in a standard way.

Culling of the scene, optimization, transform stacking, billboards, LOD management, texturing are all able to have powerful, simple and standard code to manage them.

A spatial graph

By setting up the scenegraph as a spatial non-acyclic graph culling can be more easily managed as well as graphics state. A node with children can set the state for the children without the need to redundantly specify it in the children. A scenegraph is traversed as it is drawn and state is popped and pushed to both minimize setting state without need and to simply the organization and management of the scene as a whole. Scenegraphs are often used in a complimentary fashion to other more “automatic” and hardboiled culling and spatializing strategies such as bsp nodes. I have seen many scene graph systems over the years that use bsp structures at various levels in the scene graph strictly for collision detection. The main thing about this approach is flexibility. Scenegraphs can build very sophisticated scenes in a way that is logically consistent, as simple as possible and easy for the (relative novice) to learn and understand.

What scenegraphs don’t do

Scenegraphs are very powerful but not much easier to learn than the underlying graphics API’s themselves such as OpenGL or Direct3D. They are not “game engines” that the novice can pick up and with little understanding create 3D scenes from.

You may ask yourself what the point is. The point is to not reinvent the wheel. The scenegraph is so flexible a tool because it doesn’t try to hide capabilities or oversimplify them. However, it mirrors the kind of system one would generally have to write themselves through much trial and error to achieve the same functionality. Many of these concepts are “classic” at this point. OpenSceneGraph, for example, is chocked full of appropriate and useful design patterns. Performer used these design patterns long before the term became a buzzword. SGI spent a lot of time and money developing Performer, and like OpenGL, the results were impressive. Most modern scenegraphs are directly influenced by Performer and can be seen at their core to be “Performer-clones”. Those who try to build fast and flexible graphics solutions will eventually come to something close to a scene graph on their own eventually. But why reinvent the wheel. With solutions like OpenSceneGraph already waiting……

The choice seems obvious

Use an existing scenegraph solution. You wouldn’t try to write your own graphics API in today’s world. In just the same respect you shouldn’t try to think you’ll create a better scenegraph. If you need a fast, flexible graphics solution and use one of the scene graphs out there today. I personally prefer OpenSceneGraph, something I mention often. It has a huge user base and an unmatched set of features for an opensource project. Other commercial options include Gamebryo or Renderware.

In short the benefits of using a scenegraph are numerous. A reusable, flexible and fast object system and a graph structure for hierarchy give it a strong user base and an ever expanding collection of useful code.

The next time you think about doing a project coding in a low level graphics API think about bumping up to a scenegraph. They sit nicely on top of the underlying graphics API’s and make your job much simpler at the end of the day by allowing you to focus on the problem at hand and avoid reinventing the wheel.