Carlos Konstanski wrote:
> On Sun, 14 Feb 2010, Tony Rick wrote:
>
>
>> Date: Sun, 14 Feb 2010 16:17:39 -0800
>> From: Tony Rick <tony...@gmail.com>
>> Reply-To: "General Linux/UNIX discussion and help; civil and on-topic"
>> <plug@lists.pdxlinux.org>
>> To: "General Linux/UNIX discussion and help, civil and on-topic"
>> <plug@lists.pdxlinux.org>
>> Subject: Re: [PLUG] C++ pointer freeing problem
>>
>> On Sun, Feb 14, 2010 at 3:13 PM, Carlos Konstanski <
>> ckonstan...@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@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
>>
>
> Confirmed: that did solve the problem. Many, many thanks!
>
> Carlos
>
That shouldn't have made the least difference.
Ah Microsoft, we love you so.
--
Tim Wescott
Wescott Design Services
Voice: 503-631-7815
Cell: 503-349-8432
http://www.wescottdesign.com
_______________________________________________
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
