Quote:Original post by CoffeeMug

Quote:Original post by snk_kid
*** Source Snippet Removed ***

I already considered this, but this causes two problems.
1. Implementation doesn't have access to base interface. For instance, base interface may have functions like GetSize()/SetSize() which are the same accross all platforms. When I call a specific platform's Create(), it should have access to base interface's methods.

There doesn't need to be base type.

Hi CoffeMug

I'm just starting off down the same road. I haven't written a single line of code yet, but I have been thinking about the organisation and class heirarchy.

Personally I'm leaning towards two methods mentioned already; Virtual base class member funcs and living with any overhead, and seperate files/folders for seperate implementations. But I can't help much with the facts or pro's and cons.

I've posted because I've spotted something that's missing here-- or at least has been touched upon in a way that I'm trying to avoid.

The organisation of classes such as class BaseWindow; class Win32Window or class XWindow will lead to you having several versions of your application code. Look at the main() in snk_kid's example - it's platform specific. I know it's just an example, but I saw it as a trap to be avoided :)

Going with seperate files and folders I hope to have a common class BaseWindow, and several versions of class Window.

I'm really aiming for the application code to be as portable as possible and I don't see any reason why it can't be 100% so, given the right interfaces.

-- Matt

Quote:Original post by matibee
The organisation of classes such as class BaseWindow; class Win32Window or class XWindow will lead to you having several versions of your application code.

The problem is win32 & X window system work completely different, there isn't much you can share in implemenation apart from say a string for the window title.

Quote:Original post by matibee
Look at the main() in snk_kid's example - it's platform specific. I know it's just an example, but I saw it as a trap to be avoided :)

Are sure you even understand the code, its not platform specific, sure currently the window imps doesn't share any implementation buts its not hard to factor out commonality into a base type or begin with a base type and then specialize to sub-types.

Even if you go the sub-type polymorphic route clients must still specify which platform there going to be on unless you detect which platform clients are on.

Quote:Original post by matibee
I'm really aiming for the application code to be as portable as possible and I don't see any reason why it can't be 100% so, given the right interfaces.

To achieve something like this you need to completely abstract each feature you support in each API your going support like the example of the icons.

EDIT: i would agree with DigitalDelusion some kind of bridge pattern would probably be the best way to go, you can still share implementation in a commmon base you don't have a pointer to the base type.

[Edited by - snk_kid on September 18, 2004 4:13:12 AM]

Hey snk_kid,

I think we're probably aiming for different things here. Complete control over any number of platform specific systems is likely to end up with either a lot of platform code sneaking into the app code, or an awful lot of encapsulation.

In the context of game-dev'ing tho, I'd be happy to forfeit a lot of control over sub-systems as long as they are tuned to make a good job of running on the platform they are coded for.

So my intention is to have a WindowSys, SoundSys, RenderSys, NetworkSys, InputSys (etc) each with limited (but crafted with experience and testing) interfaces- this is not something I claim to be able to do right now, but it is my ultimate goal.

I get what your code is doing (well, just about ;) ) but Your main() IS platform specific. Of course this is just the init'ing of the app and maybe it's best left to platform specifics.

The biggest thing I wanted to avoid here was a complete nonsense of class naming that might lead to 'Win32insertclassnamehere' being spread all over the app code.

-- Matt

Quote:Original post by matibee
I think we're probably aiming for different things here. Complete control over any number of platform specific systems is likely to end up with either a lot of platform code sneaking into the app code, or an awful lot of encapsulation.

Its difficult how far do you go, for games there isn't much of the windowing system you need, just to be able to get either fullscreen/windowed app, rendering contexts, pixel formats, handling OS messages.

anything more than this such as dialogs etc it maybe be best to use a cross-platform widget library instead of trying to write our own its a big job.

Quote:Original post by matibee
I get what your code is doing (well, just about ;) ) but Your main() IS platform specific. Of course this is just the init'ing of the app and maybe it's best left to platform specifics.

Oh okay you mean't the app's entry point, yeah that was just a silly example.