In addition to not being exception safe, it may leak memory if "do things" contains a returnstatement. Even if not, the code is fragile because someone might add a returnstatement in the figure, thus inadvertently causing a memory leak.
For a small object like an int, there's no good reason to allocate it on the heap and free it. It should be an automatic variable instead.
and if there is a retrun in th middle what can we do to sovle the problem
In that case the code won't compile because of your typo Wakka wakka!. Seriously though, if there already IS a return in the middle of the "Do Something" code body, then that is where you would use some form of smart pointer such as Aceix suggested. If you are asked "what if someone adds one in the future?" then this is functionally the same as you're employer asking you "what if the person we assign this project to later is incompetent?". More often then not this won't be a question in the interview; if it is then you need to reconsider the kind of place that you are applying to.
and if there is a retrun in th middle what can we do to sovle the problem
unique_ptr<int> pint;
at this point you can put your finger in your ear and start singing marching songs knowing you don't have to care about memory management :D
I want to start off by saying that I am not intentionally trying to be argumentative here, I guess this is more so for my own sake. But from the admittedly limited amount of code given, everything suggests that 'i' and 'pint' are two distinct and different variables and with out more information they should remain so. I would think that if 'pint' was intended to point at 'i', then it would be initialized to point at 'i' and it would not be allocated it's own space.
EDIT: Now if 'pint' where a reference in the original example, then I can see how you guys came to this conclusion.
Over all I think that this interview question is stupid and so open ended that any answer you could give would be wrong for lack of data. It doesn't filter out any ones ability to read what a section of code does as a whole; and in fact it's inclusion in the interview process seems designed to discourage candidates who would point this fact out. It looks like it wants to find people who can identify what individual lines of code do but that trait is useless without the former. It's like something a TA would slap together and hope you don't actually think about it. If this really is the kind of crap you guys were asked in your first interview then I don't know how you guys made it through it with out jumping across the table and punching someone in the brain.
what is the danger here?
find 2 ways to solve the problem?
I guess by danger you mean compiler warnings.
1 2 3 4 5 6 7 8 9
void func()
{int i; //garbage value
int *pint=newint();
Do things
delete pint //missing ;
//*pint = NULL;
//incase if it is deleted again the program won't crash
}
this interview question is stupid and so open ended that any answer you could give would be wrong for lack of data
We had a C++ test that contained several questions that were somewhat open-ended. The purpose was to see what sort of answers the candidate would give and do spark discussion during the interview itself. This question may have been intended similarly. However, I agree that it's poorly described.
An example from our test was "what is the difference between malloc() and new? There are many differences and we wanted to see what candidates came up with.
Also, the purpose of the test was not to see if you could "pass" the test. Rather, it was designed to see if you could demonstrate knowledge that more-or-less corresponded with the level of experience that you claimed on your resume. We told candidates this up front.