try to stump me on C++

Exterminator, look at my example class here:
http://www.codeguru.com/forum/showpo...3&postcount=42


If the assignment operator in that example were simply ...

Code:

---

    Buffer(const Buffer& other)
    {
        *this = other;
    }

---

... then the application would almost certainly crash when the assignment operator tries to free the existing data in temp's destructor, agreed?



EDIT:

Ah, I see your edit, looks like we are agreed. :)

Quote:

---

Originally Posted by Zaccheus

Exterminator, look at my example class here:
http://www.codeguru.com/forum/showpo...3&postcount=42


If the assignment operator in that example were simply ...

Code:

---

    Buffer(const Buffer& other)
    {
        *this = other;
    }

---

... then the application would almost certainly crash when the assignment operator tries to free the existing data in temp's destructor, agreed?

EDIT:

Ah, I see your edit, looks like we are agreed. :)

---

Yes, agreed. I am not thinking of as far as the destructor of temp or otherwise. It just slipped my mind that POD types (our pointer member here, considering it is not a smart one but the old, dumb, naked one :) ) remain uninitialized in constructor body if not initialized in the initializer list. And in that case, it would be impossible to predict if a pointer member points to something meaningful or not and hence any free-up on it would be an UB leading to one possibility - a crash. So, we are okay on this one. :)

Quote:

---

Originally Posted by andersod2

haha...good one CPUWizard....ok, you got me on that one....I knew it was a compile error, but I didn't see it clearly....once I compiled it though, it made sense....comes down to compiler choices I would think..

---

Assuming you fix compilation errors related to non inclusion of <iostream> and that you forward declare the function before its use and you qualify namespaces, the code doesn't complain. I am not very sure on this one, but I think it is ill-formed (or atleast that the initialization is meaningless and X has unpredictable value) as it tries using X to initialize X before X is initialized. Comeau compiles the code fine and Visual Studio 2005 prints out "0" with all build configurations and optimization levels. So, I am really unsure what is a definitive answer and I am quite stressed out to look into the standards. Sorry.

Quote:

---

Originally Posted by andersod2

Hey all,

I got a big C++ interview coming up....and I am arrogant and think I am a C++ god...so see if you can stump my knowledge of the language. I solemnly swear I won't cheat and look up the answer, and you can feel free to rip me a new one in your responses. The only requirement is that you can't include anything about particular libraries or interfaces that aren't intrinsic to C++ (stl stuff is ok). The interview won't include things like that or other trivialities which can simply be referenced. They will be asking me things like "name the 3 ways you can blah blah" or "how could the following code be improved...what is the security or memory problem...what weaknesses does it have etc"

Show me what you got! Put me in my place and make me feel like I am going into this interview a lot dumber than I think!

Thanks to all who decide to participate...I owe you one.

---

Thought this topic was about you ?? now were have you gone ?? lol; no traces of your messages again.

I'm new to C++ (still struggling with it for 2months now :D) what are POD types?? and what is the big deal about this copy constructors??

Quote:

---

Originally Posted by exterminator

Assuming you fix compilation errors related to non inclusion of <iostream> and that you forward declare the function before its use and you qualify namespaces, the code doesn't complain. I am not very sure on this one, but I think it is ill-formed (or atleast that the initialization is meaningless and X has unpredictable value) as it tries using X to initialize X before X is initialized. Comeau compiles the code fine and Visual Studio 2005 prints out "0" with all build configurations and optimization levels. So, I am really unsure what is a definitive answer and I am quite stressed out to look into the standards. Sorry.

---

Well I did type the code in raw...thanks for taking the time to get past that... :wave: :thumb:

It actually IS very well defined behavior, although one that some (pre-2003) compilers did not conform to the standard.

disclaimer: I would NOT accept this in any real world design, for two reasons. The defined behaviour is useless, and it takes a significant amount of time to find out that it is useless...

Quote:

---

Originally Posted by TheCPUWizard

It actually IS very well defined behavior, although one that some (pre-2003) compilers did not conform to the standard.

---

Hmm, in that case I will have an educated guess and go back to my C roots, where all global data was, by default, initialised to zero. I would therefore think that C++ memsets such global data to zero before any user defined initialisation code is run. Therefore I would guess that X will already be zero when it is returned by f().

How should this not be allowed to compile?

Code:

---

CSomeClass obj; // Not allowed

---

Code:

---

CSomeClass * pObj = new CSomeClass; // Ok

---

Quote:

---

Originally Posted by ch0co

Thought this topic was about you ?? now were have you gone ?? lol; no traces of your messages again.

---

I hope he'll be coming back.

Quote:

---

Originally Posted by ch0co

I'm new to C++ (still struggling with it for 2months now :D) what are POD types?? and what is the big deal about this copy constructors??

---

POD means plain-old-data, which is (more or less) any type that can safely be copied using the memcpy function. For example, Windows' POINT structure is a POD type, but std::string is not a POD type.

The big deal with the copy constructors (and assignment operators) is the fact that many many objects will have them, so it is important to get them right consistently.

Glad to see that the "post in under 24 hours or be subject to sarcasm" rule is still in effect. I'm still here, but have a life so, sorry can't fill up the page with pseudo hi-jacking all day. Anyway, GUYS, I can't believe after the careful scrutiny of my original answer, you didn't see that I had completely misread the code...I was just plain wrong! The original code says:

*this = x;

For some strange reason I saw:

this = &x;

...now you see the memory leak that was so obvious to me, yet so not there. Of course, that code is illegal, but the equivalent is just a small difference with a cast or two and perhaps a void* in there.

Anyway, exterminator, thanks for your comments, even though it's sort of moot by the time you realize I was starting with a bad assumption to begin with. Regarding *this, of course, you'd never (or very rarely) want to change the pointer itself (indirectly - the only way). And, modifying the dereferenced *this, as you know, has some specific, common uses, so I think most C++ coders would recommend not using *this unless you have to as there is almost always another way around it that is clearer, and less error prone.


If I haven't answered somebody else please follow up 'cause I pretty much skimmed the mess you see before you once it started getting livelier. Frankly, I don't feel this thread is super-helpful to any other passers by because there is much miscommunication going on. Would be better to condense the info into something more concise and post it seperately.

BTW: "Effective C++" by Scott Meyers does cover the copy constructor/assignment operator stuff quite clearly...(oops, I cheated).

Also, again thanks to everyone who is responding. Still waiting for new and wonderful challenges....my interview is just hours away.

Quote:

---

Originally Posted by andersod2

Anyway, GUYS, I can't believe after the careful scrutiny of my original answer, you didn't see that I had completely misread the code...

---

Because you said:

Quote:

---

Originally Posted by andersod2

Lot's of negative implications with modifying *this, and should almost never be done.

---

As you actually wrote "*" in front of "this" yourself, yet you had not noticed the "*"?

Especially as you responded to me saying that "*this = x" is the same as "operator=(x)", without you saying anything about misreading the code in your post #18.
:confused:

Quote:

---

Originally Posted by andersod2

Also, again thanks to everyone who is responding. Still waiting for new and wonderful challenges....my interview is just hours away.

---

Post #52 in this thread. ;)

Quote:

---

Originally Posted by andersod2

My comments were based on the assumption that the operation was possible, or that you didn't dereference the "this" pointer and were just casting away the uniqueness of everything to make it a legal operation.

---

Oh, when you said that you were thinking about:

Code:

---

this = &x;

---

That sentence makes a bit more sense now.

Quote:

---

Originally Posted by andersod2

If that were the case, then the same comments would be in effect, namely memory leak for sure, and possibly a program crash on destruction.

---

I'm fairly sure the effect of just overwriting the "this" pointer with the address of x would been the same as doing nothing at all in that function.
The "this" pointer is normally just implemented as a hidden parameter which is passed into the function and is effectively a local variable.

So overwriting the "this" pointer, if it were possible, would be like writing the following in C:

Code:

---

foo_foo(const foo* inThis, const foo* inX)
{
    inThis = inX;
}

---

yes, like i said, much confusion going on, mostly on my part...that's what I get for "not cheating."

> I'm fairly sure the effect of just overwriting the "this" pointer with the
> address of x would been the same as doing nothing at all in that function.

True, in the case you gave, but the value of this is still the same for the class being referred to...so I was thinking something along the lines of modifying the "this" pointer directly (i.e. taking it's address). After cheating on that, though, the compiler tells me you can't take the address of this (not an l-value), so one would need a fancy schmancy way of creating the equivalent to "this = &x" ....in order to create a memory leak...good for us that C++ makes that difficult to do.

Ok, so in regard to Ejaz' problem....again with no cheating...I will have to say, um, make the constructor private, and overload the new operator. Seems like there is more than meets the eye there, but I could be wrong. If so, there could be a need to make CSomeClass a derived class, but I can't think of why at the moment.

Quote:

---

Originally Posted by andersod2

Ok, so in regard to Ejaz' problem....again with no cheating...I will have to say, um, make the constructor private, and overload the new operator. Seems like there is more than meets the eye there, but I could be wrong. If so, there could be a need to make CSomeClass a derived class, but I can't think of why at the moment.

---

Assuming no other code, making the destructor private should suffice.