Anders Gidenstam <[email protected]> writes:
>
> 2.
> The JSBSim class FGPropertyManager was previously derived from
> SGPropertyNode, but isn't now. This affects the creation of the
> main JSBSim object (FGFDMExec) since it requires a FGPropertyManager
> instance to access the property tree.
>
> I have currently changed the FG JSBSim driver, JSBSim.cxx, like this:
> - fdmex = new FGFDMExec( (FGPropertyManager*)globals->get_props() );
> + // FIXME: The FGPropertyManager object must be freed somewhere!
> + fdmex = new FGFDMExec( new FGPropertyManager(
> (FGPropertyNode*)globals->get_props() ) );
>
> but this will leak a FGPropertyManager object on each reset.
> Hopefully there is no problem to just keep track of the FGPropertyManager
> object and delete it at reset. I have not tried that yet.
>
wouldn't it better to have something like this:
FGPropertyManager pm =
FGPropertyManager((FGPropertyNode*)globals->get_props() );
fdmex = new FGFDMExec(&pm);
that way we don't leak an FGPropertyManager object on each reset. seems
to work for me.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
