l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
September 2: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
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?



Thanks all. it's Barcap in NYC.
Hai

On Thu, May 27, 2010 at 11:48 PM, Bill Broadley <bill@broadley.org> wrote:
> 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
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.