RE: [Boost-Users] shared_ptr in Borland C++ Builder

From: scleary_at_[hidden]
Date: 2002-06-12 08:39:07

> From: Craigus [mailto:yg-boost-users_at_[hidden]]
> 
> Hi
> 
> I'm new to using the Boost library.

Welcome! :)

> I have Codeguard turned on (detects memory leaks, accessing freed memory,
> overwriting memory illegally and the like).  When the shared_ptr object
> count goes to zero operator() in checked_deleter eventually gets called.
> Codeguard is reporting (in poor English):
> 
> Method called on illegally casted object

If you want to fix the problem: uncheck Project Options -> C++ -> Zero
length empty class members.  Then rebuild (not remake).

The rest of this e-mail is just explaining what the error is and why this
fixes it.

Here's the problem: CodeGuard is complaining that the 'this' pointer for the
checked_deleter object is invalid when its operator() is called.  (The error
is not reported if you uncheck the "Validate the 'this' pointer on member
function entry" and rebuild).

Many function objects contain no data or base classes, but operator() cannot
be static, so for these function objects (including checked_deleter), a sort
of unspoken convention has arisen: never use the 'this' pointer.  But
CodeGuard validates the 'this' pointer anyway...

In common implementations of Standard C++, CG's validation would work:
  in the case where a function object is used as a most-derived class, it
has non-zero size (according to the Standard), so 'this' would reference a
"placeholder" memory location for that object.
  in the case where a function object is used as a base class, then the
most-derived class has non-zero size, and 'this' would reference a member in
some derived class.

C++ Builder, however, has a non-Standard-conforming option that is on by
default: Project Options -> C++ -> Zero length empty class members.  This
creates a "loophole" in the first case described above:
  in the case where a function object is used as a most-derived class *as a
member of another class*, it has zero-size(!) -- and therefore if it is the
last member of that class, 'this' would reference memory *after* the
most-derived class.

Unchecking this option allows CG's validations to work in the way described
above, closing the "loophole".

Happy coding! :)

        -Steve