Dimajix Developer Blog

C++ already has a rich set of casting operatos, ranging from old-style C casts, over static_cast, dynamic_cast and the almost-never-to-be-used reinterpret_cast. Sometimes it might be convenient to have something similar like a dynamic_cast but with another behaviour if the cast fails. For example one might want to get an exception if a specific cast is not possible.

It turns out that this is pretty easy using templates with the following code

template<class T,class S> T* throwing_cast(S* s) {
   T* result = dynamic_cast<T>(s);
   if (!result)
     throw bad_cast_exception();
   return result;
}

ClassA* a = new ClassB();
ClassB* b = throwing_cast<ClassB>(a);

But we still can do better than this, because we might want to configure which exception should be thrown on a casting failure. The code above can be easily modified to:

Continue reading "New cast operators with additional features"

Today i found a very interesting article about the future of OpenGL on OpenGL.org. The article describes ATI and NVidia thinking about the direction that OpenGL should take in its next releases (they also talk about the new features in OpenGL 2.1, but the proposed direction is far more interesting).

Their idea resembles the original goals of OpenGL 2.0 which propsed a new and clean approach offering backward compatibility only with an additional software layer. Unfortunately this idea was dropped in favor of backward compatibility. Now ATI and NVidia come up with essentially the same idea, the main difference is that they now call it OpenGL 3.0.

Among the features is a new object model (no integer handles any more that placed some special burden upon the drivers - they claim that up to 5% of driver processing time was spent for look-ups), programmable raster operations (stencil, depth and blendmodes will be shaders then), new state objects which will replace the glPush and glPop semantics and the removal of many obsolete features (including display lists wich should be replaced by VBOs).

But I guess we won't see OpenGL 3.0 very soon, if ever at all.

In my last entry I was talking about a neat tool generating reflection information for arbitrary C++ programs. Today I found another useful tool that is somewhat related to reflection, namely scripting. There are many scripting languages out there especially taylored for use with C and C++ programs (like Lua) or powerful toolkits for binding your code to a separate scripting language (like Boost::Python).

The tool called SWIG falls into the later category, but is much more powerful than anything I have seen before. Not only it produces the needed wrapper classes automatically, it has also support for 13(!) scripting languages. So processing your header files with SWIG enables you (or the users of your library/application) to use your work with 13 different languages at a finger-snip! (And of course, no one is holding you back to sell each language-binding separately...)

The only question left open might be what scripting is good for. Scripting allows end-users to interact with your program in an easy and convenient way and offers the complete power of a mature language at the same time. Many games use scripting languages in order to control the game logic, most operating systems use scripts (shell-scripts or .BAT files) for doing small jobs. Scripting simply opens a huge door for your developers and even for your customers to use your program in many new ways you never though of. John Ousterhout (creator of Tcl) also has written a paper that describes the benefits of scripting languages.

One important and useful feature is missing in C++: Reflection. Reflection is the ability of a language to acquire information about objects at runtime. Of course C++ has a typeid operator, but the use of the returned type_info is very limited and compiler dependant. What one is actually seeking for is complete information not only about class inheritance but also about all members and methods of each class.

Exactly this king of information offers the Reflex library developed at CERN. You can get all kinds of information about every object and class in your system, you can even instanciate new objects at runtime using string-literals describing a class and invoke any method of an object. One special advantage of this package is that it works in an absoultely non-intrusive manner, meaning that you do no have to change a single line of your code in order to get reflection. Instead of changing your code, Reflex relies on the gccxml parser that generates rich XML information about your classes. This information is then automatically transformed into some additional files containing cpp code containing all neccessary dictionaries and bindings to your code to enable full reflection.

Imagine the possibilities of such a system: You can easily integrate a scripting language into your program in a very generic manner if you use the rflection information provided by the Reflex library. WIth some additional work it should also be possible to serialise your objects to disk for providing persistent storage semantics. It even should be possible to implement some remote procedure calls building upon the reflection information provided by Reflex.

When it comes to its IDE and its compiler, I consider Microsoft Visual C++ 7.1 and up to be a very good product. Especially the C++ language compatibility is at a very high level. But when it comes to its included standard C library, its compatibility even has gone worse with the 8.0 release, and its C99 compliance is also very liited.

This fact can you get into troubles earlier than one might guess. When you want to write your own string classes (and also in some other cases), it is useful to have a method with a variable number of arguments that in turn calls sprintf or sscanf (which both accept a variable number of arguments). Image the following:


class String {
public:
   int sprintf(const char* fmt,...)

private:
   char* _Buffer;
}

int String::sprintf(const char* fmt, ...) {
   va_list arglist;
   va_start(arglist, fmt);
   return sprintf(_Buffer, fmt, arglist);
}


Continue reading "Visual C++ and vsscanf"

Silently, without a headline on OpenGL.org, five new extensions have been completed and added to the OpenGL Extension Registry:

• EXT_framebuffer_blit. This extensions allows to copy a region from one framebuffer object into another framebuffer object ("blitting"). It is especially useful with the next extension, which in turn would be useless without this one.


• EXT_framebuffer_multisample. This extension finally allows to create multisampled frame buffer objects. As a direct usage of the frame buffer objects as textures or backbuffers is not possible, it heavily depends on the previous extension.


• WGL_3DL_stereo_control. Some stuff for controlling 3d stereographic shutter glasses.


• EXT_stencil_clear_tag. This seems to be a rather esoteric extension for saving bandwidth on the low end generation of PCIe cards that use main memory as a gaphics card resource.


• EXT_texture_sRGB. This extension adds a new texture format for representing the non-linear sRGB colour space. Maybe this extension is useful for hardware accelerated image processing - I really don't know much about its usage.

As you can see, the two probably most valuable extensions (at least for high quality realtime 3d graphics) are EXT_framebuffer_blit and EXT_framebuffer_multisample.