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
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 _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug