Re: [Plib-users] Memory Leaks

[Steve B. <sjb...@ai...>]

"Alejo, Larry W." wrote:
> 
> Has anyone tried to incorporate plib into a MSVC++ MFC application?

Hmmm - I doubt it.  The whole idea is to use PLIB to make PORTABLE
applications - using MFC utterly guarantees that your code will never
run on a non-Windoze platform and I'll be forced to flame you mercilessly
for idiotically (and unnecessarily) tying your all your hard work to the
worst operating system on the planet.  (Not that I'm biassed or anything :-).

Hence, you won't get *any* help/sympathy from me to get that going.

To the contrary - if there is anything I can do to PLIB to utterly
ensure 100% incompatibility with MFC, I'll do it.   It's not that I'm
opposed to running PLIB programs under Windoze - it's that I'm opposed
to people mindlessly writing code that *won't* run elsewhere.  That's
THE ENTIRE REASON that I wrote PLIB and chose to give it away for nothing
and spend thousands of hours of my time maintaining it.  It would have
been much easier to write a Linux-only package!
 
> I am in the process of developing an MFC application utilizing plib
> (mainly ssg) and the current snapshot of plib in cvs.sourceforge.net
> produces a multiple number of memory leaks, as reported by BoundsChecker.
> 
> I have made an attempt, on my version of plib, to squash a few of these
> memory leaks and respectfully offer the following code changes to the
> contributors of plib for consideration and inclusion into the library.

Thanks!  Good catch.

> I also discovered conflicting multiple definitions for macro _SSG_PUBLIC:
> ssglocal.h:
> #define _SSG_PUBLIC  public
> 
> ssg.h:
> #ifndef _SSG_PUBLIC
> #define _SSG_PUBLIC  protected
> #endif

That's 100% intentional.  Those definitions are not "conflicting" - the
code in ssg.h is checking to see if the definition in ssgLocal.h is present
and explicitly NOT defining _SSG_PUBLIC if it is.

I *hate* the fact that C++ doesn't provide a way to have selected members
be private as far as the application is concerned and public as far as
other functions in the same library is concerned (you can use 'friend' but
that's an awfully blunt instrument because it makes *ALL* fields accessible
in that way).

This mechanism (in effect) creates a new security class for C++ members
'_SSG_PUBLIC' - which is public for code within SSG and protected as
far as the application is concerned.

It works because only members of the SSG library #include "ssgLocal.h"
(hence the name 'Local') and hence #define _SSG_PUBLIC as 'public'. For
general applications code (who *don't* define _SSG_PUBLIC), they'll get
those same fields declared as 'protected'.

Kinda hackish - but then that's the kind of person I am!

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net