[quote user="Iago"]
My suggested rephrasing of the second question would be "OK, now please show how you would prematurely optimise this routine by making potentially-unnecessary use of an unsafe language feature that is notorious for being directly responsible for more major security flaws than anything else in the history of programming."
Seriously, why was the interviewer asking this? He could at least have asked the interviewee to assume that profiling had identified the construction and deconstruction of a CString object as a bottleneck. (Performance-critical programming is about identifying and fixing bottlenecks, not about premature optimisation or about introducing arbitrary rules to forbid safe code.)[/quote]
Interesting - in my experience, "unsafe language features" like pointers (like those used to manage dynamically allocated memory) tend to be a source of more errors... (Also, IME, language features are rarely directly responsible for program failures, it is how they are used/misused by inexperienced and/or lazy developers doing things like not doing simple pointer checks, verifying buffer lengths, etc.)
Use of a CString is far from safe (or efficient) - observant developers will note the lack of any exception handling, and since any CString action that results in allocation is a possible exception point... (Before someone argues that this is sample code, I know that. Then it is also incorrect to play the premature optimization card as well.)
Construction and destruction of a CString object not so heavy - you can create an empty CString, do nothing with it, and later destroy it without any substantial impact. Actually using it for anything that can result in dynamic memory management is where time is used up, not to mention how <font face="courier new,courier">CString::Format(...)</font> works by having to build the formatted string twice. (So if you ever see that plain CString construction and destruction is a bottleneck, it is either wrong, or due to serious misuse of CString.) Again, knowing how things work is important.
As was previously posted, this does not fall under the scenario of "premature optimization". Again, for the purposes of the interview, performance was a concern for the position. Someone else also mentioned the possibility of coding on a platform without a normal heap, or even without MFC support. So (blindly) jumping to the premature optimization argument is in itself, premature.
I myself have asked the first request just to see if a developer is aware of how CString works or not. You would be surprised how many people do not know that the CString allocates memory behind the scenes(!), let alone how the Plex-based allocators work, or how <font face="courier new,courier">CString::Format(...)</font> works. When you have a developer writing MFC code like this:
<font face="courier new,courier">CString sWinText = _T( "The new window text" );</font>
<font face="courier new,courier">m_ecEditCtrl.SetWindowText( sWinText );</font>
That is demonstrative of a serious lack of how things work, IMHO. I have even had the occasional developer argue that it is better to encapsulate all strings(!), not realizing that encapsulation without benefit is a waste (on many levels).
However, you are entitled to your opinion... Just be sure that you do not present it as fact.
Peace!