So I have been futzing around with porting some of the OpenGL SuperBible examples to use SDL instead of GLUT. It turns out the new SDL 1.3 is using the zlib license which is much more permissive, and it also can create OpenGL 3.x+ GL contexts.
So I started writing some C++ wrappers to help instantiate SDL and create a GL context for me. I forgot how atrocious C++ is. I haven't seriously written any "real" C++ code in about 4 years (I wrote some C++ which basically looked like C, but I didn't use Templates, namespaces, or classes). I even forgot how to pass in arguments to the parent class constructor. And I am aleady dreading the whole Copy Constructor vs. = operator overloading, using smart pointers, etc etc.
But the thing that really confuses me? Makefiles. I hate them, so I've been looking for an alternative. I found waf a long time ago, and I think I'll use it, but it looks like it will have a pretty steep learning curve too. But what I like about it is that it is more generic. It isn't JUST a C/C++ build/configuration tool. It's kind of interesting how the waf author handles dependencies. Although obviously he had to use a DAG to traverse dependencies, the python code he used to automatically determine these is pretty cool, and I wish I had thought of that for the code I did at work.
So I've already begun the tedious process of learning waf, in addition to re-learning C++, the C++11x additions, libSDL and of course OpenGL. Oh, did I mention that the game logic is in Clojure and will do low-level network communication with Netty (on the clojure side) to a boost.asio asynchronous network? To say that I have a lot to learn is a huge understatement.
Speaking of C++11x, some of the features seem interesting, but some of them I also just don't understand. I'm still trying to wrap my head around the ability to bind to rvalues. I am looking forward to auto and decltype, which may help me overcome my fear of Template programming. But still, I had to wonder...was there a better way?
So I started looking into Google's Go, and the D programming language. Go seems to be quite a departure from C/C++, eliminating some strongly typed aspects of the language. The syntax is also a little funkier, but nothing too bad I think. But I've already heard some people say that it's not exactly true that Go is a System Programming language, but rather a network programming language. It's also still in a very early stage of development. D on the other hand seems to be more of a real programming language. It also seems to do everything C++11x does, including a few that C++11x doesn't. In fact, the more I looked at D, the more I liked it. For example, it does automatic garbage collection (Go does too btw), it has an easier to read Template system, it has lambdas and closures, it has built-in complex numbers, built in unit-testing, and a few other nice features.
But...it has one major drawback (Go suffers the same fate). D does not have a preprocessor and thus does not understand .h header files. Sure, it can natively call C API libraries..but you have to define the types yourself. So basically, you have to convert header files into a D module. uggghh. I've been through this before with python ctypes, JNA, and bridj. It's not fun. And SWIG isn't much better. With SWIG, you still have to make a .i file, and even if you use a "raw" header, the stuff it outputs is barely human legible.
I'd love to use D, but I'd have to convert libSDL to modules (already done with the Derelict module...but it's using the 1.2 version of SDL which doesn't do OpenGL 3+ contexts, and I don't know what version OpenGL it supports). Sadly, if a system's programming language isn't compatible with C (and I don't just mean being able to call functions in a library, I mean to understand all the types in a header file too), then it's just not going to find a lot of uptake.
No comments:
Post a Comment