C++ stylistic concerns?

Steve smorrey at gmail.com
Wed Mar 21 09:56:29 MDT 2007


I don't think thats the point Michael.
My job here is pretty simple.

Create a crossplatform library which wraps the platform specific
details for creating an OpenGL window, handling user input and playing
sound files, into a single interface and utilizing a common namespace.
 This library should provide functionality similar to SDL, however it
may not bind to, or depend upon any libraries outside of those
normally provided by the manufacturer of the operating system.
It then goes into a platform by platform list of libraries I'm allowed
to use (all of which are basically present on a properly configured
system such as opengl32.dll, etc.

There is also a list of libraries which cannot be utilized, wxWidgets
and libSDL are on the list.

Since it's part of the clients requirements, I'm not really going to
argue the point.
But for the record I do believe that wxWidgets is not LGPL licensed,
but is actually under the wxWidgets license, which is very similar but
not quite the same as the LGPL.
In fact by my reading it's actually more permissive than the LGPL
http://wxwidgets.org/about/newlicen.htm

Either way they want something that they can control the licensing on,
and my job is to provide them with that :D


On 3/21/07, Michael L Torrie <torriem at chem.byu.edu> wrote:
> 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.
> > */
> >
>
>
> /*
> 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