Re: Resolving EXC_BAD_INSTRUCTION (Where do I begin?)
Re: Resolving EXC_BAD_INSTRUCTION (Where do I begin?)
- Subject: Re: Resolving EXC_BAD_INSTRUCTION (Where do I begin?)
- From: Jeff Birac <email@hidden>
- Date: Wed, 06 Sep 2006 21:29:45 -0400
Clarification: I am employing the Open PowerPlant framework.
I am trying to minimize warnings, but some would lead to me modifying
code I am weary of touching (e.g., PowerPlant).
The (PowerPlant) code is riddled with warnings like:
warning: 'class LAttachment' has pointer data members
but does not override 'LAttachment(const LAttachment&)'
or 'operator=(const LAttachment&)'
warning: 'class LAttachable' has pointer data members
but does not override 'operator=(const LAttachable&)'
warning: 'LUndoer::mAction' should be initialized in the member
initialization list
Are these warnings really important or are they just there to
encourage "good practice"? If these are frivolous warning, then how
would I turn them off; I have not found any flag/switch/preference to
ignore such warnings.
I am reluctant to override the implicit any PowerPlant class' Copy
Constructor or Assignment Operator because their developers may have
a reason to allow (or rely on) the implicit implementations.
Any suggestions?
Thanks.
-- Jeff
On Sep 6, 2006, at 12:38 PM, Paul Walmsley wrote:
Just because the code worked correctly under CodeWarrior doesn't
mean it was written correctly. Turn on compiler warnings; turn
off optimizations; use the debugger. It shouldn't be too hard to
find. ;)
I often find one of the most likely causes of errors when switching
from one compiler to another is static initialisers. If you have
static data in one .cpp file that references static data in another
then that's one of the first places your program will blow up. C++
makes no guarantee of the order of initialisation, and the compiler
won't warn you about it either.
However, in this case, you'll still be able to see where it's going
wrong in the debugger.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden