On 27 Jul 2008, at 21:02, Tim Moore wrote:

>> If you're doing that work, I'd like you to follow a *really*  
>> minimalist stance
> i.e., if a header file only contains pointers or references to  
> another class or
> includes them as arguments in uninstantiated templates (e.g.,
> osg::ref_ptr<foo>), then that classe's include file should not be  
> sucked in; a
> local class declaration should be made instead.
>
> This will generate more work for you, but is really the way to go in  
> terms of
> reducing compiler dependencies.

For pointers, a forward declaration works - for template, auto_ptr and  
osg::ref_ptr, I'm not totally clear what you mean. With auto_ptr, the  
following can cause problems with virtual destructors not being called  
on older (MSVC6, I think) versions of visual studio:

[the following is from memory of several wasted days a couple of years  
ago, stepping through the generated assembly of MSVC6. I think I have  
the particular case right]

class foo;

class bar
{
        // no explicit dtor!

        auto_ptr<foo> mFoo;
}

class wibble : public foo
{
   virtual ~wibble()
   {
     // .... highly important stuff
   }
}

{
   bar a;
   a.mFoo.reset(new wibble);
   // a goes out out scope, its compiler-generated dtor gets run,  
destroying mFoo
}
// error, wibble's dtor was not run

If we're requiring a never MSVC than that, I believe we're fine. And  
perhaps you meant something else entirely?

>> In C++ code they should be <cstring> and friends in order to ensure  
>> that the
> functions are all declared in the std namespace.

Okay, when I'm bored I'll do the monster patches to fix that.

James



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to