Yea, Im passing it to a direct x device.

Im not using dynamic_cast nor need it now with the preprocessor commands
Just in the base class I have a getwindowhandle.

Actually now that I mention it, I am going to derive a class from a base window class for a Windows version of initing, ect... should I just have the class in preprocessor so there is only 1 window class and the preprocessor picks the correct one?

If you have access to the base class definition, then dynamic_cast is not required:



Of course, if this conversion is very infrequent, does not make any sense as part of the design (it does, after all, break the open/closed principle in most cases) or is required in a similar fashion for many other classes, then dynamic_cast is a better solution.

Quote:Original post by Anonymous Poster
@joanusdmentia:
That's a really good idea. Then just #ifdef around the headers you need.

No #ifdef's are required at all. The majority of your code will only include the 'PlatformWindow.h' file (which contains no platform-specific types). The parts which are platform specific (eg. the window's implementation, Direct3D, etc) will then include the appropriate platform specific header (eg. Win32Impl.h). By keeping each platform's implementations in different .cpp files you can compile and link only the source files for the current platform.

Quote:Original post by Nypyren
(you can make a dummy instance - I wish C++ had a construct to get direct access to the vtable pointer without a nasty hack like this)

There is no such thing as a vtable pointer in C++, citizen.

The output of certain compilers may include a vtable pointer as an implementation of dynamic binding of methods. Other compilers, or certain virtual machines, may also implement dynamic binding of methods through a hash system or by decorating objects with their methods directly. While you can expect the usual C++ compilers to use a virtual table, you cannot assume that this is the case, lest you explicitly violate the C++ Standard and end up with undefined behaviour.

Also note that your hack can only be expected to work if the object is of the expected type. In particular, if C is-a B is-a A, then a reference to A storing a C will not be converted to a B this way. dynamic_cast and a virtual method would work here, however.

As for the work done by dynamic_cast: it's mostly a type lattice traversal (although it's not a lattice, but let's assume it is) which checks that the required type is a supertype of the dynamic type. This traversal is linear (straight up) when not using multiple inheritance, but it may need to look for several paths when multiple inheritance is used.

Quote:Original post by t0Xic
dynamic_cast<>() requires c++ RTTI-system to be enabled. This afaik intoduces some overhead not only to your specific class but to all classes in your code.

It's true: lattice traversal information is added to each class. This results in a slightly larger executable. However, speed and runtime memory usage are unaffected.

Quote:
To ensure that your class is a B, you could simply write your own little RTTI for that class.

This would most probably result in time and per-instance memory overhead for that class, not to mention that it would be unsafe. Using virtual functions to perform typecasts (as I outlined above) has no such overheads, is typesafe and requires less work.

Quote:Original post by joanusdmentia

Quote:Original post by Anonymous Poster
@joanusdmentia:
That's a really good idea. Then just #ifdef around the headers you need.

No #ifdef's are required at all. The majority of your code will only include the 'PlatformWindow.h' file (which contains no platform-specific types). The parts which are platform specific (eg. the window's implementation, Direct3D, etc) will then include the appropriate platform specific header (eg. Win32Impl.h). By keeping each platform's implementations in different .cpp files you can compile and link only the source files for the current platform.

I like that method. I think I will use it in conjucnction with a ifdef for a handle. I dont want to have to parse that out in d3d or other stuff. Who knows may even do your handle method. Thanks for the idea.