[PLUG] C++ pointer freeing problem

Carlos Konstanski ckonstanski at pippiandcarlos.com
Mon Feb 15 03:34:20 UTC 2010


On Sun, 14 Feb 2010, Tony Rick wrote:

> Date: Sun, 14 Feb 2010 16:17:39 -0800
> From: Tony Rick <tonyr42 at gmail.com>
> Reply-To: "General Linux/UNIX discussion and help;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> To: "General Linux/UNIX discussion and help,	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> Subject: Re: [PLUG] C++ pointer freeing problem
> 
> On Sun, Feb 14, 2010 at 3:13 PM, Carlos Konstanski <
> ckonstanski at pippiandcarlos.com> wrote:
>
>> On Sun, 14 Feb 2010, Tony Rick wrote:
>>
>> Commenting out the "if(! numericP()) {}" block circumvents the
>> error. Therefore it seems reasonable that something in numericP() is
>> causing the trouble. That's what led me to look at the treatment of
>> the *char. Now I think it's corrupting rawInput().
>>
>> Is it bad to keep using getRawInput() directly whenever I want to read
>> its value, instead of getting a copy into a local variable? This would
>> cause no problems in Java, Lisp, etc, but perhaps C++ is
>> different. I'll try changing that.
>>
>> I appreciate all your help thus far. It is good to know that I should
>> not bark up the free() tree.
>>
>> Carlos
>> _______________________________________________
>> PLUG mailing list
>> PLUG at lists.pdxlinux.org
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
>
> The corruption may be that member function getRawInput() itself has been
> nuked, or that member variable rawInput has been nuked, or that the  table
> holding the info about class members has been nuked,  Since I can't see how
> a simple reference to the variable or the function call could produce a NaN
> to trigger the exception, I lean toward the last one, which involves an
> index into a lookup table, if I recall my C++ Class implementation details
> correctly.   This would mean that the corruption is way bad, caused by
> writing memory locations gone wild, for example.
>
> One point about accessors (eg, get/setRawInput):  they are generally for
> access from the 'outside world', part of the information hiding paradigm.
> Inside a class instance, member variables are directly accessible, unless
> you go to some extraordiary lengths to make them not so.  I would not use
> get/setRawInput in any of the Validator methods, but the variables
> themselves.
>
> const char* charSequence = rawInput.c_str();
>
> - tony

I will try this advice. How different C/C++ is from other
languages. Implementation details are something to learn about and
deal with. Keeps the mind sharp.

Thanks a million!

Carlos



More information about the PLUG mailing list