Bug in Handle::operator==?

[goetz.rienaecker]

Hi,

At first, thanks to all contributors to the great QuantLib project! The library is  plentiful source of object-oriented design in Quantitative Finance and already quite useful for practical pricing.

What now comes is may be a bug report:

The operator== of a Handle is for example used by Observer::unregisterWith(), where the observer has to find the observable with which it wants to unregister.
I looked at the code and found:

template <CLASS T>
inline bool Handle<T>::operator==(const Handle<T>& h) const {
  return (n_ == h.n_);
}

As I understand, h.n_ is the reference count, not the pointer to the object.
This might cause, for instance, the observer to unregister from the wrong observable.

Probably, this mail comes a bit late because Handle will be replaced by boost::shared_pointer in the future, but I want to make sure if my observation was right.

Best,
Götz
---
Götz Rienäcker
mailto:[hidden email]

[Luigi Ballabio-2]

On 2004.06.16 14:23, [hidden email] wrote:

> What now comes is may be a bug report:
>
> The operator== of a Handle is for example used by
> Observer::unregisterWith(), where the observer has to find the
> observable with which it wants to unregister.
> I looked at the code and found:
>
> template <CLASS T>
> inline bool Handle<T>::operator==(const Handle<T>& h) const {
>   return (n_ == h.n_);
> }
>
> As I understand, h.n_ is the reference count, not the pointer to the
> object.

Hi,
        the above is correct: h.n_ is a pointer to the integer holding  
the reference count, not its value. Testing for equality of such  
pointer is actually stricter than testing for equality of the pointers  
to the object: in the first case, two handles are deemed equal only if  
one of them is a copy of the other, while in the second case, all null  
handles, however instantiated, would be considered equal.

Later,
        Luigi

[goetz.rienaecker]

[hidden email] schrieb am 06.07.04 15:58:33:

>
> On 2004.06.16 14:23, [hidden email] wrote:
> > What now comes is may be a bug report:
> >
> > The operator== of a Handle is for example used by
> > Observer::unregisterWith(), where the observer has to find the
> > observable with which it wants to unregister.
> > I looked at the code and found:
> >
> > template <CLASS T>
> > inline bool Handle<T>::operator==(const Handle<T>& h) const {
> >   return (n_ == h.n_);
> > }
> >
> > As I understand, h.n_ is the reference count, not the pointer to the
> > object.
>
> Hi,
> the above is correct: h.n_ is a pointer to the integer holding  
> the reference count, not its value. Testing for equality of such  
> pointer is actually stricter than testing for equality of the pointers  
> to the object: in the first case, two handles are deemed equal only if  
> one of them is a copy of the other, while in the second case, all null  
> handles, however instantiated, would be considered equal.
>
> Later,
> Luigi
>

-- 

Hi Luigi,

Thank's for your answer - and I should apologize for the false alarm!
Actually I realized that my suspicion was wrong the same day I wrote the message and told the Admin that he may forget it.
Also, an error of this kind would probably have been observed much earlier.

But may be, I do have found a small bug now:
If ENABLE_ERROR_LINES is defined and Error::where() is used (e.g. in QL_ASSERT()), file and line are written into a C string 'char[100]', which causes memory violation for very long file names. Is there a reason why no std::string is used here?

Best,
Götz

---
Götz Rienäcker
mailto:[hidden email]

[Luigi Ballabio-2]

On 2004.07.08 10:04, [hidden email] wrote:
> If ENABLE_ERROR_LINES is defined and Error::where() is used (e.g. in
> QL_ASSERT()), file and line are written into a C string 'char[100]',
> which causes memory violation for very long file names. Is there a
> reason why no std::string is used here?

No reason--it's an oversight. It will be fixed in next release.

Thanks,
        Luigi