Do STL iterators need to be deleted when you're done with them? If I remember right, iterators are nothing but pointers that have been gussied up, but do they have their own destructors that clean up all their internal mess? I can't remember for the life of me and google is no help.
Most iterators don't have members, per se, only operators. Further, a lot of iterators are nothing but pointers so there is nothing for a debugger to show you. Error messages are a concern, but compiler vendors (including MS in VC7) are addressing this, and there are coding techniques that can be employed to reduce the "noise" and produce understandable error messages.
If an iterator is a pointer, then an iterator is an object that contains a single pointer, and it will take up some memory, probably the same amount of space as a pointer, but maybe a little more if you do virtual method overriding or other fancy shit with your iterators. The object is object allocated on the stack though, so in that cause, it will be destroyed when it goes out of scope, like any other object allocated on the stack.
It could be useful for an object to store an iterator which refers to a position within some external collection. You would need to be care about how the iterators were used though, if any of the objects were to try to delete portions of the collection using the iterators, it could be bad.
>>11
The Sepples WayTM is just to make another copy, because that's efficient. Then you know you ``own'' it and don't have to worry about it being deleted out from under you.
So elegant!
Name:
Anonymous2011-11-23 2:24
>>13
Switch to C. fags* p = *fags[0], *end = *fags[size];
while(p-end){
p++;
}
What a beauty. So elegant!
then again, 'new'ing an allocator is just batshit insane. "sane" pragmatics don't require explicit allocation of stl containers at all, henceforth: std::vector<fags>::iterator iter; for(iter=thisthread.begin(); iter!=thisthread.end(); iter++) {fags faglett = *iter; /* have a fag */}
>>17[code]'
>sizeof(container)/sizeof(container[0]) on a pointer
>thinks allocated heap chunks are null terminated
Wtf am I reading. enjoy your segfaults
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-23 3:54
>>18
That illustrate why pointers make it easy to step out of bounds
>>19
So you are saying pointers are dangerous if you are an idiot and don't know how pointers/arrays work or how memory work? Wow, how did you came up with that.
Name:
Anonymous2011-11-23 4:12
>>17
>herpaderpa look everyone ima superübernerdygeeknerd doublehacker cuz me no use intendation!!1111 lololol yiff yiff :3
always associating pointers to an array with the length of the array almost always results in redundant information, although it is nice to have for debugging with assertions, or if one doesn't want to think about ways to infer array length.