try to stump me on C++

Quote:

---

Originally Posted by Ejaz

How should this not be allowed to compile?

Code:

---

CSomeClass obj; // Not allowed

---

Code:

---

CSomeClass * pObj = new CSomeClass; // Ok

---

---

Along the same lines, but more general...

Is it possible to either:

1) Prevent an object from being created on the stack but allow creation on the "heap?"

2) Prevent an object from being created on the "heap" but allow it to be created on the stack?

If you answer yes for either or both, please provide an example....

[please dont let this degenerate to "heap" vs. "freestore", I admit to being loose with the terms...]

Quote:

---

Originally Posted by andersod2

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.

---

I don't understand what you mean by "modifying the 'this' pointer directly (i.e. taking it's address)". In a typical C++ implementation the only "this" pointer is the hidden parameter passed into the function call, which only exists for the duration of the function call. How on earth would you create a memory leak just by modifying the value of that hidden parameter?

Quote:

---

Originally Posted by Plasmator

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

---

Correct :) However, for real world applications, a separate destruction mechanism would be required to deallocate the object.

How did the interview go?

> Is it possible to either:

> 1) Prevent an object from being created on the stack but allow creation
> on the "heap?"

> 2) Prevent an object from being created on the "heap" but allow it to be
> created on the stack?


Ok, for the sake of time I'm going to say yes on both counts, but I don't have time to give examples (not good ones anyway). Basically, your local variables are going to be on the stack, and your dynamic memory will be on the heap. So, as Plasmator revealed, I think the answer to Ejaz' problem fulfills the first one (though nobody said, whether my solution was wrong or right). For the second one, I will just say doing everything normal, except overload new and make it private. Kind of rushing through this, so I haven't given it enough thought.

> How on earth would you create a memory leak just by modifying the
> value of that hidden parameter?

I suppose that would depend on where the parameter came from originally. How is "this" obtained for purposes of pushing the parameter onto the stack? Is it just a matter of taking the address of the object in question? (I don't know) If not, I could imagine a scenario where usurping the address of "this" (in some strange manner) was capable of causing us to lose the address of the object altogether....maybe if "this" was in fact a global variable behind the scenes??... and was just pushed onto the stack as-is, under the assumption that programmers can't access it's address anyway (without trying hard). At any rate, it's not a very enlightening issue since I think we are agreed that it's a good thing that you can't modify "this" very easily. At the very least you've lost your object for the rest of the function call...doh!

Quote:

---

Originally Posted by Plasmator

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

---

Wouldn't you need a free() member function which deletes the object?

Quote:

---

Originally Posted by andersod2

> Ok, for the sake of time I'm going to say yes on both counts, but I don't have time to give examples (not good ones anyway). Basically, your local variables are going to be on the stack, and your dynamic memory will be on the heap. So, as Plasmator revealed, I think the answer to Ejaz' problem fulfills the first one (though nobody said, whether my solution was wrong or right). For the second one, I will just say doing everything normal, except overload new and make it private. Kind of rushing through this, so I haven't given it enough thought.

---

Anybody else have comments before I reveal the answers (which were published in one of the most often referenced C++ books about 15 years ago...)??

A quick guess would be if you wanted to create on the heap but not on the stack would be to make the constructors private and supply some sort of 'Create' function?

For the the stack but not the heap, maybe declare an overloaded 'new' operator for the class but not define it?

Me bad :blush: :blush: :o :o :mad:

I left out the most important qualification (Doh!)...

"...without impacting the ability to create (in the other location) in any way".

My humble apologies..

I am going to take a rough guess and say the stl heap?

1) Prevent an object from being created on the stack but allow creation on the "heap?"

Code:

---

class SomeClass
{
private:
    ~SomeClass() {}
public:
    void Destroy() { delete this; }
};

---

2) Prevent an object from being created on the "heap" but allow it to be created on the stack?

Code:

---

class SomeClass
{
private:
    static void* operator new(size_t);
    static void operator delete(void*);
    static void* operator new[](size_t);
    static void operator delete[](void*);
};

---

What would be the result of the following?

Code:

---

v[i] = i++;

---

Or,

Code:

---

f(v[i],i++);

---

And no cheating ;)

Code:

---

v[i] = i++;

---

is equivelent to

Code:

---


v[i] = i;
i++;

---

Code:

---

f(v[i],i++);

---

Undefined.

^^^ Agree with JohnW