[PLUG] C++ pointer freeing problem

[Tony Rick]

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