[fxruby-users] FXVec* default constructors

[David MacMahon]

On Jan 25, 2009, at 23:17 , David MacMahon wrote:

> I just noticed that the default constructors for FXVec* do not  
> initialize their elements.  This also affects anything that uses  
> FXVec* default constructors under the covers such as the FXExtent*  
> default constructors.

Another thing to note, which I think is an fxruby and/or swig issue,  
is that the FXExtent* methods #lower, #upper, and #[] return a new  
object for each call, but all these different objects are backed by  
the same underlying C++ object.  This can lead to weird/undesirable  
behavior...

$ irb -r fox16
irb(main):001:0> include Fox
=> Object
irb(main):002:0> e1=FXExtentd.new(0,1,0,1)
=> #<Fox::FXExtentd:0x4d09ef0>
irb(main):003:0> l1=e1.lower
=> [0.0, 0.0]
irb(main):004:0> l2=e1.lower
=> [0.0, 0.0]
irb(main):005:0> l1.eql?(l2)
=> false
irb(main):006:0> l1.equal?(l2)
=> false
irb(main):007:0> l1 == l2
=> true
irb(main):008:0> h={}
=> {}
irb(main):009:0> h[e1.lower]=1
=> 1
irb(main):010:0> h[e1.lower]
=> nil
irb(main):011:0> l2.x = 9
=> 9
irb(main):012:0> l1
=> [9.0, 0.0]
irb(main):013:0> e1.lower
=> [9.0, 0.0]

It is a little disconcerting to see the state of object_id A change  
when object_id B is altered.

If the "new-object-returned-on-every-call" behavior is due to how  
swig maps public members, could that mapping be persuaded to return  
the same object on each call?

If not, could the object_id method be overridden to return the  
address of the underlying C++ object or does Ruby and/or swig already  
use #object_id as a pointer to some other "wrapper" structure?

If not, it would be nice to have a method that tests whether two  
objects are backed by the same memory if #object_id cannot be used  
for that purpose.

I think the moral of the story (for now?) is don't use #eql? or  
#equal? to compare the return values from these methods, which also  
means don't use them as hash indexes.

Thanks,
Dave