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