A question on lifetime

Started by
6 comments, last by NotAYakk 17 years, 10 months ago
Hi, I applied for a C++ programming job and a couple of days later the recruitment agency phoned me up. Without any warning he went into asking me many strange questions on C++ and Java. It all went quite badly, but one really stuck out though: If you have a class that has a pointer to an instance of another class as a member, what 4 functions would you use to control the lifetime of the pointer? I really don't get that. I presumed he was asking about C++, but even then, surely it all depends on absolutely everything? He gave me no information on the class, what it was supposed to do, whether these 4 function are standard library functions or user-defined... nothing. So can anyone shed some light on what the hell this was all about?
Advertisement
I'd guess at constructor, destructor, copy constructor and assignment operator - they'd manage the pointer so that it's always valid. Although it is a very badly worded question...
Yeah that's what I started saying at first, but then I wouldn't really think of these as traditional functions. So then I thought about the fact that he used the word lifetime, and asked him 'did you say this class has a lifetime?' he said yes. So i started talking about updating it with time passed and seeing if it needs to be killed or not.

I think I probably went of the rails a bit....
Evil Steve has to be correct, but it is a very misleading question since these do not control the lifetime of the pointer. The lifetime of the pointer is the same as the lifetime of the containing class. It is not even really fair to say they control the lifetime of the pointed-to object since that would depend on whether the containing class owned the object or not.

An agency person with a limited understanding himself, methinks?
It was not a bad question. It was a little obscure if you don't know C++ really really well. And it is the kind of question you can easily start down the wrong track on, and if you don't ever get feedback from the interviewer it can get worse and worse fairly easily.

The question from the OP was "If you have a class that has a pointer to an instance of another class as a member, what 4 functions would you use to control the lifetime of the pointer?". This is ALMOST exactly the right question. It might be more clearly worded as "If you have a class that has a pointer to an instance of another class as a member and want to contol the lifetime of that object, what 4 functions would you typically need to create or edit?". Or even more simply "To control member lifetime in C++, what 4 functions would you typically implement?"

Don't get down about one not-so-great phone interview. And don't bother trying to worry about silly things like the quality of the questions and the interviewers behaviors you don't like, they are counter-productive. Concentrate on seeing this as an example of things you are likely to encounter in the process in the future, and work at improving your performance. I know personally that I reread my resume before every interview, and prepare my thoughts on how to best represent my skills and history. This has nothing to do with being a good programmer, but everything to do with landing a good programming job. Interviewing well is a skill about communications, understand what they are looking for, flexibility and responding to different situations fluidly. Concentrate on not getting flustered during an interview by one bad response or a few stupid questions.

Another thing. Do not hesitate to ask for them to phrase the question again because you are not sure you understand what they are asking or looking for. Especially during phone interviews. As long as this only happens a few times each interview, and about half the time you follow up the request for additional clarification with a good response they will not judge you badly for it at all.

Good Luck in the future.
What about "incrementRefCount" (getRef), "decrementRefCount" type of functions? More of an SE/OO take on the question, instead of a technicality of C++. But if those are half of it, I wouldn't be sure what the other two were.

clone..?
"That''s to do with the day I finally realized the world had gone totally mad and built the Asylum to put it in, poor thing, and hoped it would get better."-Wonko the SaneSo Long, and Thanks for All the Fish
Quote:Original post by EasilyConfused
Evil Steve has to be correct, but it is a very misleading question since these do not control the lifetime of the pointer. The lifetime of the pointer is the same as the lifetime of the containing class. It is not even really fair to say they control the lifetime of the pointed-to object since that would depend on whether the containing class owned the object or not.

An agency person with a limited understanding himself, methinks?


no matter if it owns the object or not, those 4 functions are the functions where you code that choice. If you do not code all 4 of those functions following the ownership rules you decide upon, any decision you have made will be broken and not properly enforced. Hence the reason those ARE the 4 lifetime control functions. And just as the great Rush once said, "you may choose not to decide, you still have made a choice". In this case - if you implement nothing you have decided that it is up to the outer code to ensure that the lifetime of the inner pointed to object exceeds that of the usage of the containing object. Lest you receive a great segement fault smiting.
"The short answer is: don't.

The long answer is: Don't store bare pointers to other classes, unless you aren't worried about object lifetime.

Use either an auto pointer or auto reference class to store the pointer to the other class. The resource management semantics are now implied by your choice of pointer-wrapper.

And avoid rolling your own autopointer/autoreference class (other than to learn), anymore than you should roll your own vector/list/map. Writing them without making a design mistake is hard, and the resulting bugs can be annoying."

This topic is closed to new replies.

Advertisement