C++ stylistic concerns?

Michael L Torrie torriem at chem.byu.edu
Wed Mar 21 09:35:44 MDT 2007


On Wed, 2007-03-21 at 09:29 -0600, Steve wrote:
> Ok sorry allow me to clarify.
> wxWidgets was ruled out by the client in the contract wording.
> When I asked why they said "We cannot re-license it", which is fine
> they want a library that they can set the licensing terms on pretty
> much soup to nuts.

Umm, no one can do this for any license typically.  The library doesn't
belong to them.  If they were to use Qt, for example, under a commercial
license, they do have royalty-free rights to use and distribute the
license, but they cannot re-license the library!  Only the copyright
holders have the right to do that.

Sounds like your client is laboring under some serious misconceptions of
how licensing really works in the industry. 

> 
> Anyways this isn't an all inclusive platform library, now I've been
> working on it for awhile, I can tell you it only needs to wrap up
> platform specific OpenGL stuff as well as input handling and audio.

Are they aware that using OpenGL requires linking to libraries that they
cannot re-license?  The terms of the various OpenGL implementation
libraries are generous and allow royalty-free use and distribution, but
they are still licensed.  Has your client made a contract with SGI over
this issue?  If not then I don't see how you can use OpenGL and fulfill
their requirements anymore than with wxWidgets.

Michael


> 
> For something like this wxWidgets would probably be overkill anyways.
> 
> On 3/21/07, Michael L Torrie <torriem at chem.byu.edu> wrote:
> > On Tue, 2007-03-20 at 23:54 -0600, Steve wrote:
> > > 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.
> >
> > What do you mean by this?  Is your client expecting you to write
> > everything in assembly code?  wxWidgets is licensed under the LGPL which
> > means your code which uses wxWidget can be licensed any way you want.
> > There are plenty of commercial, closed-source applications written with
> > wxWidgets.  I understand if wxWidgets isn't useful in your case, but we
> > need to seriously correct all the misunderstandings of what open source
> > licensing that seem rampant out there.
> >
> > Michael
> >
> >
> >
> >
> >
> > >
> > > 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.
> > > > */
> > > >
> > >
> > > /*
> > > 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.
> > */
> >
> 
> /*
> 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