Sign in to follow this  

A question on lifetime

This topic is 4197 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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....

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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..?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
"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."

Share this post


Link to post
Share on other sites

This topic is 4197 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this