StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
10857160
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-06-01T20:50:41.093
FavoriteCount
0
LastActivityDate
2012-06-01T21:27:10.467
LastEditDate
2012-06-01T21:27:10.467
LastEditorUserId
1142006
OwnerUserId
1142006
ParentId
10856784
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
It is highly unlikely that an object would be in a position to cause its own release/deallocation if your code is designed properly. So yes, the situation you describe is indicative of bad coding practice, and can in fact cause the program to crash. Here is an example: <pre><code>@interface Widget : NSObject @property (retain) NSMutableArray *array; @end @implementation Widget @synthesize array; - (id)init { self = [super init]; if(self) { array = [[NSMutableArray alloc] init]; [array addObject:self]; } return self; } - (void)dealloc { NSLog(@"Deallocating!"); [array release]; [super dealloc]; } - (void)removeSelf { NSLog(@"%d", [array count]); [array removeObject:self]; NSLog(@"%d", [array count]); } @end </code></pre> and then this code is in another class: <pre><code>Widget *myWidget = [[Widget alloc] init]; [myWidget release]; // WHOOPS! [myWidget removeSelf]; </code></pre> The second call to NSLog in <code>removeSelf</code> will cause an EXC_BAD_ACCESS due to the fact that <code>array</code> has been deallocated at that point and can't have methods called on it. There are at least a couple mistakes here. The one that ultimately causes the crash is the fact that whatever class is creating and using the <code>myWidget</code> object releases it before it is finished using it (to call removeSelf). Without this mistake, the code would run fine. However, MyWidget shouldn't have an instance variable that creates a strong reference to itself in the first place, as this creates a retain cycle. If someone tried to release <code>myWidget</code> without first calling <code>removeSelf</code>, nothing would be deallocated and you'd probably have a memory leak.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIn objective c can a class essentially delete itself?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USUIAdam
UserOwnerUserId
1. USUIAdam
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POIn objective c can a class essentially delete itself?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.