save and load bug.
David Bateman
dbateman at dbateman.org
Sun Dec 28 05:20:55 CST 2008
Søren Hauberg wrote:
> søn, 28 12 2008 kl. 11:12 +0100, skrev David Bateman:
>
>> Either don't save all of the variables or don't have database or ftp
>> that rely on SWIG loaded.... The swig packages don't have the code to
>> save the swig objects.. Perhaps these packages shouldn't be marked as
>> autoloaded
>>
>
> I don't know this part of the code, so this might be a silly question.
> How hard would it be to extend the swig code to support saving variables
> such that when the user tries to save these variables a warning is
> printed saying that the variables won't be saved?
>
> Søren
>
>
>
Reading ftp_wrap.cpp I see the following
// octave_swig_type plays the role of both the shadow class and the class
// representation within Octave, since there is no support for classes.
//
// These should really be decoupled, with the class support added to
Octave
// and the shadow class given by an m-file script. That would
dramatically
// reduce the runtime complexity, and be more in line w/ other modules.
class octave_swig_type:public octave_base_value {
struct cpp_ptr {
void *ptr;
bool destroyed;
cpp_ptr(void *_ptr):ptr(_ptr), destroyed(false) {
}};
So it seems the solution is to implement the comment about the shadow
class being written as OOP code in octave and then the load/save of SWIG
objects would be implemented ass OOP objects can be loaded and saved in
Octave 3.1.51+... Xavier Delacour wrote this stuff perhaps he'd be
willing to look at this conversion.
Note however this seems to be unrelated to the original issue in this
thread.
Regards
David
--
David Bateman dbateman at dbateman.org
35 rue Gambetta +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
More information about the Help-octave
mailing list