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 22:36:53 -0400
On Sep 6, 2006, at 10:13 PM, David A Rowland wrote:
At 9:29 PM -0400 9/6/06, Jeff Birac wrote:
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.
They are there to enforce good practice, but they are not
frivolous. If you use the default copy or assign for an object with
pointer members, you will end with two objects having pointers to
the same structures. That could be disaster. For example, if one of
the copies goes out of existence and calls the destructor, does the
destructor free the objects pointed at? If so, the remaining copy
will point to invalid space. If not, where is the pointed at thing
freed?
The warning is telling you to think about it and perhaps use a
"deep" copy that copies not only the top object but also the
pointer destinations.
The warning on LUndoer is probably less serious. mAction must have
a default constructor, so you may be OK using it by default. In
fact, I'm surprised that's even a warning.
David
Thanks for the explanations...
They are there to enforce good practice, but they are not
frivolous. If you use the default copy or assign for an object with
pointer members, you will end with two objects having pointers to
the same structures. That could be disaster. For example, if one of
the copies goes out of existence and calls the destructor, does the
destructor free the objects pointed at? If so, the remaining copy
will point to invalid space. If not, where is the pointed at thing
freed?
LArray makes important use of such overrides to copy an array's items
into a separate Handle. But these warnings are kind of cluttering up
the build results. Is there a way to regulate these (and other)
warnings that do not have seemingly explicit build options?
Thanks.
-- Jeff
_______________________________________________
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