C++ stylistic concerns?

Steve smorrey at gmail.com
Tue Mar 20 23:54:15 MDT 2007


Ok thanks for the advice guys.
wxWidgets is not really something that can be used here, the client is
wanting something they can completely control the licensing of.

I appreciate the feedback, and am glad to know that I'm doing this the
right way, crossplatform development is a real pain, and doing this
simplifies things for me as well.


On 3/20/07, Brian Hawkins <brianhks at activeclickweb.com> wrote:
> I think your approach is the right one.  If you want it used, think of
> what the developer that is using your code will have to do.  Whatever
> makes their life easier is the right approach.  I've used several cross
> platform libraries and it is very nice to be able to just #include
> <xproj.h> in my code.  This makes my code even more cross platform as I
> do not have to maintain any ifdefs or other such nonsense.
>
> Brian
>
> Steve wrote:
> > Hello All,
> > I'm hoping someone with more experience in this matter than me can
> > answer a quick question about longterm code maintainance.
> >
> > Up until now most of my code has been quick little "throw away" jobs,
> > stuff that I never expect to last long enough for maintainance to be a
> > major concern.
> >
> > Now I've picked up a project that will be dual licensed with GPL and
> > an optional proprietary closed source license (so end users don't have
> > to open up their code base if they want to, instead they can just pay
> > a small fee).
> >
> > Anyways, the heart of the project is a cross platform wrapper for
> > Windows Linux and Mac, it wraps OpenGL, Input and Sound, effectively
> > making a gaming library.
> >
> > At first I tried the traditional approach of creating a couple .h
> > files for each unit interface, and a different .cpp file for each
> > platforms implementation.
> >
> > I ran into a whole lot of compile time issues with this approach
> > mostly due to the fact that each system relies to one extent or
> > another on each of the other systems.
> >
> > So I tried a new style I had read about.
> >
> > In this style, you create a .h for your basic definitions on each
> > system, then you place a few #ifdefs for each platform and #include a
> > platform specific header to handle the implementation details.
> >
> > It looks a little like this
> >
> > /*PlatformGL.h*/
> > namespace Platform{
> >        namespace GL{
> >             void Init(int width,int height,bool fullscreen);
> >        }
> > }
> >
> > #ifdef LINUX
> > #include "PlatformGLLinux.h"
> > #endif
> >
> > #ifdef WINDOWS
> > #include "PlatformGLWindows.h"
> > #endif
> >
> > #ifdef MACINTOSH
> > #include "PlatformGLMac.h"
> > #endif
> >
> > What concerns me most is the long term maintainability of the code,
> > something tells me I may be creating a maintainance nightmare by going
> > this route since the .h files are effectively just the *.cpp files
> > renamed to *.h
> >
> > But I just can't put my finger on why this feels like a bad idea.
> > Maybe it's just because it's so different than anything I've done before.
> >
> > On the bright side though a user of this library could just #include a
> > single header file to have access to the entire system, and just issue
> > a make on each platform without any need to retool (hopefully).
> >
> > Anyways, if someone has seen this method of library creation before
> > and has any feedback it would be greatly appreciated.
> >
> > Thanks in advance!
> >
> > /*
> > PLUG: http://plug.org, #utah on irc.freenode.net
> > Unsubscribe: http://plug.org/mailman/options/plug
> > Don't fear the penguin.
> > */
> >
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>



More information about the PLUG mailing list