From: Olly B. <ol...@su...> - 2005-12-21 23:12:37
|
I've found an oddity with PHP and default destructors (this is the PHP issue I alluded to in another thread). The PHP section of the SWIG manual says that reference counting is used and that "[t]he destructor is not available to be called manually". Generally this is true, for example this: %module x; %include typemaps.i class A { public: int m(int x); A(); ~A(); }; processed with "./swig -php -noproxy -c++ test.i" results in functions "a_m" and "new_a". However this: %module x; %include typemaps.i class A { public: int m(int x); }; processed the same way also gives a function "delete_a". Tracing this inside the SWIG code, I've found that in Modules/php4.cxx, in method functionWrapper, that the code checks for a destructor by seeing if the nodeType (i.e. Getattr(n, "nodeType") is "destructor". This is true for an explicit destructor, but for a default one the nodeType is "class" instead (the same is true for the default ctor). But I'm not sure where the bug lies. Is the php backend wrong to assume that it can just check the nodeType to see if this is a destructor, or is SWIG wrong to not set nodeType appropriately for default ctor/dtor? Cheers, Olly |
From: Olly B. <ol...@su...> - 2005-12-27 01:06:11
|
On 2005-12-21, Olly Betts <ol...@su...> wrote: > But I'm not sure where the bug lies. Is the php backend wrong to assume > that it can just check the nodeType to see if this is a destructor, or > is SWIG wrong to not set nodeType appropriately for default ctor/dtor? I've just tried processing the two examples with several other backends (python, perl5, tcl8, csharp) and they all generate the same *_wrap.cxx files for both, which rather suggests it's the php backend which is wrong here. I'll see if I can work out what's wrong. Cheers, Olly |
From: Kevin R. <kr...@ku...> - 2005-12-28 01:13:23
|
Olly, I don't know what's wrong but will also take a look. I appreciate you're help finding & fixing problems. Kevin Olly Betts wrote: >On 2005-12-21, Olly Betts <ol...@su...> wrote: > > >>But I'm not sure where the bug lies. Is the php backend wrong to assume >>that it can just check the nodeType to see if this is a destructor, or >>is SWIG wrong to not set nodeType appropriately for default ctor/dtor? >> >> > >I've just tried processing the two examples with several other backends >(python, perl5, tcl8, csharp) and they all generate the same *_wrap.cxx >files for both, which rather suggests it's the php backend which is >wrong here. I'll see if I can work out what's wrong. > >Cheers, > Olly > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: Kevin R. <kr...@ku...> - 2005-12-29 13:03:51
|
Hi all, In tracking this down, it seems the constructors & destructors created by Language::makeDestructor() and Lanaguage::makeConstructor() do not look exactly like those generated when parsing source. In particular, there is no nodeType attribute. The php4 module checks nodeType in the function wrapper to do some special processing for ctor/dtors. I've found by adding: SetAttr(cn, "nodeType", "destructor"); in the makeDestructor(), that php4 things the generated default destructor is indeed a regular destructor. I'm prepared to commit this change if you think it's ok. But I don't know it's larger effects. Kevin Olly Betts wrote: >On 2005-12-21, Olly Betts <ol...@su...> wrote: > > >>But I'm not sure where the bug lies. Is the php backend wrong to assume >>that it can just check the nodeType to see if this is a destructor, or >>is SWIG wrong to not set nodeType appropriately for default ctor/dtor? >> >> > >I've just tried processing the two examples with several other backends >(python, perl5, tcl8, csharp) and they all generate the same *_wrap.cxx >files for both, which rather suggests it's the php backend which is >wrong here. I'll see if I can work out what's wrong. > >Cheers, > Olly > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: Kevin R. <kr...@ku...> - 2005-12-29 19:23:15
|
As a follow up. I'd like the php generator to always use nodefaultdtor and override it if it is specified in the interface files. Any ideas? Is the best thing to do to test for it in pragma() and issue a warning? Thanks Kevin Kevin Ruland wrote: > Hi all, > > In tracking this down, it seems the constructors & destructors created > by Language::makeDestructor() and Lanaguage::makeConstructor() do not > look exactly like those generated when parsing source. In particular, > there is no nodeType attribute. The php4 module checks nodeType in > the function wrapper to do some special processing for ctor/dtors. > > I've found by adding: > > SetAttr(cn, "nodeType", "destructor"); > > in the makeDestructor(), that php4 things the generated default > destructor is indeed a regular destructor. > > I'm prepared to commit this change if you think it's ok. But I don't > know it's larger effects. > > Kevin > > Olly Betts wrote: > >> On 2005-12-21, Olly Betts <ol...@su...> wrote: >> >> >>> But I'm not sure where the bug lies. Is the php backend wrong to >>> assume >>> that it can just check the nodeType to see if this is a destructor, or >>> is SWIG wrong to not set nodeType appropriately for default ctor/dtor? >>> >> >> >> I've just tried processing the two examples with several other backends >> (python, perl5, tcl8, csharp) and they all generate the same *_wrap.cxx >> files for both, which rather suggests it's the php backend which is >> wrong here. I'll see if I can work out what's wrong. >> >> Cheers, >> Olly >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: William S F. <ws...@fu...> - 2005-12-29 19:46:10
|
Hopefully Marcelo will have a better idea about your nodeType solution as he has been working in this area. To me this should be set whenever the node is created, rather than an add on in the Language class. I'm not sure about suppressing the default constructors/destructors. Unless there is a very good reason it would be better if php was consistent with all the other languages and generate destructor wrappers. Why do you want to suppress their generation - how is a user going to free up the memory created? This area is highly customisable, even more so since Marcelo's recent mods, so a user can always tailor the generation if they so desire. William Kevin Ruland wrote: > As a follow up. I'd like the php generator to always use nodefaultdtor > and override it if it is specified in the interface files. Any ideas? > Is the best thing to do to test for it in pragma() and issue a warning? > > Thanks > > Kevin > > Kevin Ruland wrote: > >>Hi all, >> >>In tracking this down, it seems the constructors & destructors created >>by Language::makeDestructor() and Lanaguage::makeConstructor() do not >>look exactly like those generated when parsing source. In particular, >>there is no nodeType attribute. The php4 module checks nodeType in >>the function wrapper to do some special processing for ctor/dtors. >> >>I've found by adding: >> >>SetAttr(cn, "nodeType", "destructor"); >> >>in the makeDestructor(), that php4 things the generated default >>destructor is indeed a regular destructor. >> >>I'm prepared to commit this change if you think it's ok. But I don't >>know it's larger effects. >> >>Kevin >> >>Olly Betts wrote: >> >>>On 2005-12-21, Olly Betts <ol...@su...> wrote: >>> >>> >>>>But I'm not sure where the bug lies. Is the php backend wrong to >>>>assume >>>>that it can just check the nodeType to see if this is a destructor, or >>>>is SWIG wrong to not set nodeType appropriately for default ctor/dtor? >>>> >>> >>>I've just tried processing the two examples with several other backends >>>(python, perl5, tcl8, csharp) and they all generate the same *_wrap.cxx >>>files for both, which rather suggests it's the php backend which is >>>wrong here. I'll see if I can work out what's wrong. >>> >>>Cheers, >>> Olly >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through >>>log files >>>for problems? Stop! Download the new AJAX search engine that makes >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>_______________________________________________ >>>Swig-devel mailing list >>>Swi...@li... >>>https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>Swig-devel mailing list >>Swi...@li... >>https://lists.sourceforge.net/lists/listinfo/swig-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Kevin R. <kr...@ku...> - 2005-12-29 20:08:17
|
William: William S Fulton wrote: > Hopefully Marcelo will have a better idea about your nodeType solution > as he has been working in this area. To me this should be set whenever > the node is created, rather than an add on in the Language class. > The Langauge class has a method called makeDestructor() which generates the node for the default dtor. It was in this method that I added the Setattr. Actually, the makeDestructor() function is static at file scope in lang.cxx so it's really not a part of the Language class itself. This is probably the best place for this. > I'm not sure about suppressing the default constructors/destructors. > Unless there is a very good reason it would be better if php was > consistent with all the other languages and generate destructor > wrappers. Why do you want to suppress their generation - how is a user > going to free up the memory created? This area is highly customisable, > even more so since Marcelo's recent mods, so a user can always tailor > the generation if they so desire. > You might be right. PHP does do garbage collection for all wrapped objects/structs. The programmer should not call the destructors manually because that will cause double frees even when you aren't using the proxy class generation. I actually thought I had found a place where resources can be leaked in php and needed to add calls to destructors manually. Kevin > William > > > Kevin Ruland wrote: > >> As a follow up. I'd like the php generator to always use nodefaultdtor >> and override it if it is specified in the interface files. Any >> ideas? Is the best thing to do to test for it in pragma() and issue a >> warning? >> >> Thanks >> >> Kevin >> >> Kevin Ruland wrote: >> >>> Hi all, >>> >>> In tracking this down, it seems the constructors & destructors created >>> by Language::makeDestructor() and Lanaguage::makeConstructor() do not >>> look exactly like those generated when parsing source. In particular, >>> there is no nodeType attribute. The php4 module checks nodeType in >>> the function wrapper to do some special processing for ctor/dtors. >>> >>> I've found by adding: >>> >>> SetAttr(cn, "nodeType", "destructor"); >>> >>> in the makeDestructor(), that php4 things the generated default >>> destructor is indeed a regular destructor. >>> >>> I'm prepared to commit this change if you think it's ok. But I don't >>> know it's larger effects. >>> >>> Kevin >>> >>> Olly Betts wrote: >>> >>>> On 2005-12-21, Olly Betts <ol...@su...> wrote: >>>> >>>> >>>>> But I'm not sure where the bug lies. Is the php backend wrong to >>>>> assume >>>>> that it can just check the nodeType to see if this is a >>>>> destructor, or >>>>> is SWIG wrong to not set nodeType appropriately for default >>>>> ctor/dtor? >>>>> >>>> >>>> >>>> I've just tried processing the two examples with several other >>>> backends >>>> (python, perl5, tcl8, csharp) and they all generate the same >>>> *_wrap.cxx >>>> files for both, which rather suggests it's the php backend which is >>>> wrong here. I'll see if I can work out what's wrong. >>>> >>>> Cheers, >>>> Olly >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through >>>> log files >>>> for problems? Stop! Download the new AJAX search engine that makes >>>> searching your log files as easy as surfing the web. DOWNLOAD >>>> SPLUNK! >>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>> _______________________________________________ >>>> Swig-devel mailing list >>>> Swi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>>> >>>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>> files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > |
From: Marcelo M. <mm...@ac...> - 2005-12-30 08:31:43
|
Kevin Ruland wrote: >William: > >William S Fulton wrote: > > > >>Hopefully Marcelo will have a better idea about your nodeType solution >>as he has been working in this area. To me this should be set whenever >>the node is created, rather than an add on in the Language class. >> >> >> >The Langauge class has a method called makeDestructor() which generates >the node for the default dtor. It was in this method that I added the >Setattr. Actually, the makeDestructor() function is static at file >scope in lang.cxx so it's really not a part of the Language class >itself. This is probably the best place for this. > > > >>I'm not sure about suppressing the default constructors/destructors. >>Unless there is a very good reason it would be better if php was >>consistent with all the other languages and generate destructor >>wrappers. Why do you want to suppress their generation - how is a user >>going to free up the memory created? This area is highly customisable, >>even more so since Marcelo's recent mods, so a user can always tailor >>the generation if they so desire. >> >> >> >You might be right. PHP does do garbage collection for all wrapped >objects/structs. The programmer should not call the destructors >manually because that will cause double frees even when you aren't using >the proxy class generation. I actually thought I had found a place >where resources can be leaked in php and needed to add calls to >destructors manually. > > remember that mainly all the target languages do the same, ie, garbage collection, but they take care of the language objects, not the C++ allocated memory. for example, python call __delete__ when it things is needed, the user never calls __delete__ directly. In old swig-python, we use __delete__ to dispatch the proper C++ delete operation. probably in php5 the equivalent method is void *__destruct* ( void ) http://us3.php.net/manual/en/language.oop5.decon.php I don't know if there is something similar in php4. Marcelo >Kevin > > > >>William >> >> >>Kevin Ruland wrote: >> >> >> >>>As a follow up. I'd like the php generator to always use nodefaultdtor >>>and override it if it is specified in the interface files. Any >>>ideas? Is the best thing to do to test for it in pragma() and issue a >>>warning? >>> >>>Thanks >>> >>>Kevin >>> >>>Kevin Ruland wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>In tracking this down, it seems the constructors & destructors created >>>>by Language::makeDestructor() and Lanaguage::makeConstructor() do not >>>>look exactly like those generated when parsing source. In particular, >>>>there is no nodeType attribute. The php4 module checks nodeType in >>>>the function wrapper to do some special processing for ctor/dtors. >>>> >>>>I've found by adding: >>>> >>>>SetAttr(cn, "nodeType", "destructor"); >>>> >>>>in the makeDestructor(), that php4 things the generated default >>>>destructor is indeed a regular destructor. >>>> >>>>I'm prepared to commit this change if you think it's ok. But I don't >>>>know it's larger effects. >>>> >>>>Kevin >>>> >>>>Olly Betts wrote: >>>> >>>> >>>> >>>>>On 2005-12-21, Olly Betts <ol...@su...> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>But I'm not sure where the bug lies. Is the php backend wrong to >>>>>>assume >>>>>>that it can just check the nodeType to see if this is a >>>>>>destructor, or >>>>>>is SWIG wrong to not set nodeType appropriately for default >>>>>>ctor/dtor? >>>>>> >>>>>> >>>>>> >>>>>I've just tried processing the two examples with several other >>>>>backends >>>>>(python, perl5, tcl8, csharp) and they all generate the same >>>>>*_wrap.cxx >>>>>files for both, which rather suggests it's the php backend which is >>>>>wrong here. I'll see if I can work out what's wrong. >>>>> >>>>>Cheers, >>>>> Olly >>>>> >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through >>>>>log files >>>>>for problems? Stop! Download the new AJAX search engine that makes >>>>>searching your log files as easy as surfing the web. DOWNLOAD >>>>>SPLUNK! >>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>>>_______________________________________________ >>>>>Swig-devel mailing list >>>>>Swi...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/swig-devel >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>>>files >>>>for problems? Stop! Download the new AJAX search engine that makes >>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>>_______________________________________________ >>>>Swig-devel mailing list >>>>Swi...@li... >>>>https://lists.sourceforge.net/lists/listinfo/swig-devel >>>> >>>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through >>>log files >>>for problems? Stop! Download the new AJAX search engine that makes >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>>_______________________________________________ >>>Swig-devel mailing list >>>Swi...@li... >>>https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> >>> > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: Kevin R. <kr...@ku...> - 2005-12-30 12:13:56
|
Marcelo, I've decided to not persue requiring !nodefaultdtor until I can come up with some good test cases. The big question for you is, can I modify makeDestructor() to add the Setattr() call so it looks like any other destructor? Kevin Marcelo Matus wrote: > Kevin Ruland wrote: > >> William: >> >> William S Fulton wrote: >> >> >> >>> Hopefully Marcelo will have a better idea about your nodeType solution >>> as he has been working in this area. To me this should be set whenever >>> the node is created, rather than an add on in the Language class. >>> >>> >> >> The Langauge class has a method called makeDestructor() which generates >> the node for the default dtor. It was in this method that I added the >> Setattr. Actually, the makeDestructor() function is static at file >> scope in lang.cxx so it's really not a part of the Language class >> itself. This is probably the best place for this. >> >> >> >>> I'm not sure about suppressing the default constructors/destructors. >>> Unless there is a very good reason it would be better if php was >>> consistent with all the other languages and generate destructor >>> wrappers. Why do you want to suppress their generation - how is a user >>> going to free up the memory created? This area is highly customisable, >>> even more so since Marcelo's recent mods, so a user can always tailor >>> the generation if they so desire. >>> >>> >> >> You might be right. PHP does do garbage collection for all wrapped >> objects/structs. The programmer should not call the destructors >> manually because that will cause double frees even when you aren't using >> the proxy class generation. I actually thought I had found a place >> where resources can be leaked in php and needed to add calls to >> destructors manually. >> >> > remember that mainly all the target languages do the same, ie, garbage > collection, but > they take care of the language objects, not the C++ allocated memory. > > for example, python call __delete__ when it things is needed, the user > never calls __delete__ > directly. In old swig-python, we use __delete__ to dispatch the proper > C++ delete operation. > > probably in php5 the equivalent method is > void *__destruct* ( void ) > > http://us3.php.net/manual/en/language.oop5.decon.php > > I don't know if there is something similar in php4. > > Marcelo |
From: Marcelo M. <mm...@ac...> - 2005-12-30 17:49:03
|
Check out CVS again, there is no more makeDestructor/makeConstructor. Marcelo Kevin Ruland wrote: > Marcelo, > > I've decided to not persue requiring !nodefaultdtor until I can come > up with some good test cases. > > The big question for you is, can I modify makeDestructor() to add the > Setattr() call so it looks like any other destructor? > > Kevin > > Marcelo Matus wrote: > >> Kevin Ruland wrote: >> >>> William: >>> >>> William S Fulton wrote: >>> >>> >>> >>>> Hopefully Marcelo will have a better idea about your nodeType solution >>>> as he has been working in this area. To me this should be set whenever >>>> the node is created, rather than an add on in the Language class. >>>> >>>> >>> >>> >>> The Langauge class has a method called makeDestructor() which generates >>> the node for the default dtor. It was in this method that I added the >>> Setattr. Actually, the makeDestructor() function is static at file >>> scope in lang.cxx so it's really not a part of the Language class >>> itself. This is probably the best place for this. >>> >>> >>> >>>> I'm not sure about suppressing the default constructors/destructors. >>>> Unless there is a very good reason it would be better if php was >>>> consistent with all the other languages and generate destructor >>>> wrappers. Why do you want to suppress their generation - how is a user >>>> going to free up the memory created? This area is highly customisable, >>>> even more so since Marcelo's recent mods, so a user can always tailor >>>> the generation if they so desire. >>>> >>>> >>> >>> >>> You might be right. PHP does do garbage collection for all wrapped >>> objects/structs. The programmer should not call the destructors >>> manually because that will cause double frees even when you aren't >>> using >>> the proxy class generation. I actually thought I had found a place >>> where resources can be leaked in php and needed to add calls to >>> destructors manually. >>> >>> >> remember that mainly all the target languages do the same, ie, >> garbage collection, but >> they take care of the language objects, not the C++ allocated memory. >> >> for example, python call __delete__ when it things is needed, the >> user never calls __delete__ >> directly. In old swig-python, we use __delete__ to dispatch the >> proper C++ delete operation. >> >> probably in php5 the equivalent method is >> void *__destruct* ( void ) >> >> http://us3.php.net/manual/en/language.oop5.decon.php >> >> I don't know if there is something similar in php4. >> >> Marcelo > > > |
From: Olly B. <ol...@su...> - 2005-12-30 19:30:58
|
On 2005-12-30, Marcelo Matus <mm...@ac...> wrote: > Check out CVS again, there is no more makeDestructor/makeConstructor. I've just rechecked and Marcelo's changes have fixed the main problem for PHP. There's one minor wrinkle remaining - the generated files for the two cases in my original message now differ like so in __wrap_delete_A: --- test_wrap.cpp 2005-12-30 18:56:16.770587768 +0000 +++ test2_wrap.cpp 2005-12-30 18:56:19.385190288 +0000 @@ -1078,7 +1078,7 @@ void __wrap_delete_A(zend_rsrc_list_entr efree(value); if (! newobject) return; /* can't delete it! */ SWIG_ZTS_ConvertResourceData(ptr,rsrc->type,type_name,(void **) &arg1,SWIGTYPE_p_A TSRMLS_CC); - if (! arg1) zend_error(E_ERROR, "A resource already free'd"); + if (! arg1) zend_error(E_ERROR, "A::~A resource already free'd"); delete arg1; } (test_wrap.cc is from the case with the EXPLICIT dtor; test2_wrap.cc has the default one). Basically it's cosmetic, but it would be better if the default destructor case generated exactly the same code. The "A" or "A::~A" are from GetChar(n,"name") where n is the destructor node. Looking at internal values, the constructor's "name" is also different if it's default ("A" for test.i vs "A::A" for test2.i), but that doesn't seem to affect the generated code in my example. Cheers, Olly |
From: Marcelo M. <mm...@ac...> - 2005-12-30 20:02:25
|
Olly Betts wrote: >On 2005-12-30, Marcelo Matus <mm...@ac...> wrote: > > >>Check out CVS again, there is no more makeDestructor/makeConstructor. >> >> > >I've just rechecked and Marcelo's changes have fixed the main problem >for PHP. There's one minor wrinkle remaining - the generated files for >the two cases in my original message now differ like so in __wrap_delete_A: > >--- test_wrap.cpp 2005-12-30 18:56:16.770587768 +0000 >+++ test2_wrap.cpp 2005-12-30 18:56:19.385190288 +0000 >@@ -1078,7 +1078,7 @@ void __wrap_delete_A(zend_rsrc_list_entr > efree(value); > if (! newobject) return; /* can't delete it! */ > SWIG_ZTS_ConvertResourceData(ptr,rsrc->type,type_name,(void **) &arg1,SWIGTYPE_p_A TSRMLS_CC); >- if (! arg1) zend_error(E_ERROR, "A resource already free'd"); >+ if (! arg1) zend_error(E_ERROR, "A::~A resource already free'd"); > delete arg1; > > } > >(test_wrap.cc is from the case with the EXPLICIT dtor; test2_wrap.cc has the >default one). > >Basically it's cosmetic, but it would be better if the default destructor >case generated exactly the same code. > >The "A" or "A::~A" are from GetChar(n,"name") where n is the destructor node. >Looking at internal values, the constructor's "name" is also different if >it's default ("A" for test.i vs "A::A" for test2.i), but that doesn't seem to >affect the generated code in my example. > > > You need to use the more robust way: Getattr(Swig_methodclass(n),"name"); since you want the name of the class, and not the method. Before it worked since instead of a new method, the makeConstructor/makeDestructor returned a copy of the class. Marcelo >Cheers, > Olly > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: Olly B. <ol...@su...> - 2005-12-30 21:36:41
Attachments:
swig-php-double-delete-error-message-fix.patch
|
On Fri, Dec 30, 2005 at 01:02:21PM -0700, Marcelo Matus wrote: > You need to use the more robust way: > > Getattr(Swig_methodclass(n),"name"); Thanks, though it seems I actually need this slight variant, or I just get "void" instead of the typename: GetChar(Swig_methodclass(n),"name") I've attached a patch for Source/Modules/php4.cxx - with this applied I get identical output on the two examples I posted earlier. Cheers, Olly |