[Gllug] cross platform development (C++)

Sean Burlington sean at tincan.co.uk
Mon Jul 1 22:10:35 UTC 2002


oops ..

ask a question - get somehelpful answers then take ages to respond...


Steve Goodwin wrote:
>>what I really want to do is compile one set of sources to 
>>produce executables 
>>for each of Windows and Linux (preferably Mac OS too)
> 
> 
> Being pedantic for a moment, is that what you want to do? Or do you want the
> same _program_ on both platforms?
> 
> Since they have Windows machines with licenses you might do better (in the
> long run) to work at home, and re-compile a similar (but not necessarily
> identical) code base at uni using native tools. This will invariably give
> better performance/debugging capabilities than cross over tools.
> 

well my hope was to avoid having to use windows myself ... but that 
looks problematic

one reason for avoiding windows is that while the college has licences - 
students don't get enough disk space to hold a whole set of libs/compiler

Qt win requires M$VC++ etc ...

> With console apps, just stick to standard ANSI input/output, or standard
> libraries that exist on both (certainly not MSVCRT et al).
> 
> With graphical apps, I'd create an abstraction layer regardless of the
> underlying toolkit you are using, or plan to use. Create your own class for
> each platform, inheritted from an abstract base that includes the basic
> create window/button/text functionality. 
> 
> class CInterface {
> 	virtual HMYHANDLE	CreateWindow(int w, int h...);
> 	virtual HMYHANDLE	CreateButton(HMYHANDLE hParent, int x, int
> y...);
> 	.. etc ..
> 	};
> 
> then
> 	class CWindowsInterface : public CInterface {	...
> or
> 	class CLinuxInterface : public CInterface {	...
> 
> Depending on the platform, create a new instance,
> 
> CInterface *pInterface;
> 
> #ifdef _WINDOWS
> 	pInterface = (CInterface *)new CWindowsInterface ;
> #else
> 	pInterface = (CInterface *)new CLinuxInterface ;
> #endif
> 
> You can then reference all the functions through the base pointer,
> 
> 	pInterface->CreateWindow(...
> 
> and everything works naturally.
> 
> You can then write your QT functions (all wrapped up) in your CInterface
> class implementation, and repeat for Windows, using whatever
> license/style/code is available at the time. This also helps future
> proofing, as the underlying library can change, without modifying the app.
> 
> Creating a good set of abstract functions is difficult. I'd recommend
> looking at two or three possible setups, and make a version that works
> cleanly with all of them. Since you are trying to adopt two philosphies into
> one API, things don't always fit nicely so instead of fretting over
> something 100% abstract make it 100% abstract for the known cases, and lever
> the others in later!
> 

sounds like a great way to go ...

if you know much more than I do :(

but I did just find this...

http://kde-cygwin.sourceforge.net/faq/#E7

which is very interesting

/more/ like the approach I had in mind - though running X on top of 
M$Windows sounds like asking for trouble ...

interesting to at least see discussion of creating GPL'd Qt for M$Win

I've recently become very keen on the idea of converting people to free 
software  a package at a time ...

I guess this is especially since mozilla and openOffice got out of Beta

-- 

Sean





-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list