l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2010 May 28 14:03

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] anything wrong with this code?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] anything wrong with this code?

On 05/27/2010 08:35 PM, Chanoch (Ken) Bloom wrote:
> On Thu, 2010-05-27 at 22:08 -0400, Hai Yi wrote:
>> hi there:
>> can anyone look at these two small c++ snippets to see what's wrong
>> with them? I was interviewed with them...

Out of curiosity, where?  (feel free to not answer)

>> 1.
>> A* createA(){ return new A();}
>>      void fun(){createA();}
>>      What's wrong with the above code?
> It leaks memory.

Is A defined?  Is it that A is allocated but the return value isn't 
checked (for an allocation failure)?  Or that the pointer isn't used? Or 
that it leaks?

>> 2.
>> for(iter=map.begin();iter!=map.end();iter++){
>> erase(iter++);
>> iter++;
>> }
>> anything wrong with the above code? What's happened for "iter++" internally?
>       1. erase() is a member function of the map class. It is not a free
>          function. A free function named erase() wouldn't know what
>          container to erase the iterator from.
>       2. The code only works if map.size() is a multiple of 3. If it
>          isn't, then one of the iter++ operations may try to put iter 2
>          or 3 past the end of the map. If you did this on a raw array, or
>          a vector (whose iterators are usually just pointers to the
>          elements, unless you're in some kind of debug mode),
>                * then the standard doesn't guarantee that you can form
>                  the address of the element 2 or 3 past the end of the
>                  array,
>                * if you could form that address it would certainly no
>                  longer be equal to array.end(), so you'd miss the
>                  termination condition.

While true, wouldn't it be simpler to just say that iter is incremented 
3 times per loop and it's likely that the intent is once?  While legal 
in C/C++, in general you shouldn't much with an iteration variable. 
Either turn it into a while (without increment) and handle it in the 
body, or increment in the for loop and don't muck with it in the body.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.