[PLUG] C++ pointer freeing problem

[Tim Wescott]

Tony Rick wrote:
> 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();
>   
I would take that under advisement -- sometimes you _do_ want to use a 
class's accessor functions from within the class, particularly when its 
large and complex (and maybe due to be split up) or when you know that 
you will always need the information as presented to the outside world 
and you suspect that you're going to change the internal representation.

-- 
Tim Wescott
Wescott Design Services
Voice: 503-631-7815
Cell:  503-349-8432
http://www.wescottdesign.com