🚀 go-pugleaf

I Googled this question as I have been having the same problem (and disregarded) for a long time, here the answer (which I don't fully understand) from a fellow on another newsgroup:


> 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! :)






"Leen Keus" <lj.keus@tiscali.nl> wrote:
>Hi,
>
>I get the same GodeGuard error on TADODataSet. I must use a TADODataSet in 
>the TADOConnection->OpenSchema method, but this method does not work because 
>of this error. In some examples how to use TADODataSet, I found the 
>following statement:
>
>TADODataSet *ds = new TADODataSet (NULL); // NULL instead of this or Owner!
>
>But this does not work, get the same CodeGuard error.
>
>Does any one have a solution so far?
>
>Leen
>
>"Mich" <michellep@timemarkinc.com> schreef in bericht 
>news:41c1b81f$1@newsgroups.borland.com...
>>I get the same error with a TADOConnection object in BCB 5 as soon as I 
>>call
>> Open() or set Connected to true.  The ConnectionString for my object is
>> "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + sFilePath +
>> ";Mode=ReadWrite|Share Deny None;Persist Security Info=False"
>>
>> So far the only luck I've had is to use a TADOTable instead.  But now that
>> is not populating my TDBComboBox through the TDataSource...
>>
>> --Michelle
>>
>>
>> "Aleix Ventayol" <aleix@metalcam.com> wrote in message
>> news:41acbca3@newsgroups.borland.com...
>>> I'm using C++Builder 6, when I try to create a TADODataSet object,
>> Codeguard
>>> says:
>>> "Method called on illegally casted object"
>>>
>>> You can check it using the code:
>>>
>>> void __fastcall TForm1::FormCreate(TObject *Sender)
>>> {
>>>     TADODataSet * ds=new TADODataSet (this);
>>> }
>>
>> 
>
>