"brian" <[EMAIL PROTECTED]> writes: > Yes, what I am describing is impossible. Except, it really is > happening.
No, it isn't. Something *else* is happening, and you are mis-interpreting the symptoms. > I'm only guessing that the 2-parameter version is being called; It can't be: you eliminated it from the library. You can verify that it is gone thus: $ nm --demangle libMyClass.a | grep MyClass | grep set_value > inspection and run-time checking of the code shows no other way that > the enumrated type data member could be set to an invalid value (only 0 > and 1 are defined). Then you either have an unintialized value, or heap/stack corruption (something else "steps" on that data member). > By the way, Brian Kernigan talks about how he finds effective debugging > being careful design and a few well-placed print statements. Careful design is always a good thing, but print statements are an effective debugging technique mostly on platforms that lack other debugging support. My guess is that Kernighan deals with systems that have no debugger at all much more frequently then you do. > the robustness and maintainability of my code generally far exceeds > that of those who live in the debugger. Good for you. I am not advising you to "live in the debugger". I am advising you that when faced with a misbehaving program, you should first read the source, then fire up a debugger (if available), and only then start adding printf()s and recompiling. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ Help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
