They go away when the reference count is 0. That's the COM protocol.
I just read the thread carefully and I'm still fuzzy what you were arguing. But it didn't have anything to do with George2's code.
They go away when the reference count is 0. That's the COM protocol.
I just read the thread carefully and I'm still fuzzy what you were arguing. But it didn't have anything to do with George2's code.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
George2 were claiming that while a pointer is still pointing (read: has a reference) to the object, it won't go away.
I was explaining the concept that you can have a thousand pointers pointing to the object, and the ref count can still be 1, and if it was, if you called Release then, the object would be destroyed regardless how many pointers were pointing to the object because the reference count would reach 0.
Hi Elysia,
I am reading the book Inside COM. It mentioned when there is a new pointer, we should call AddRef, except that we optimize the performance and clear the nested relationship of pointers.
Looks like your concept of reference count and pointer count are different. But in COM (at least in the book), reference count and pointer count are both the same. :-)
regards,
George
No, he wasn't. He got confused by your insistence that Release() should be called after assigning a new value to the pointer (and just how would you call Release() on the old one then?) and merged the idea of having a pointer to the interface and having called AddRef() on it (thus keeping the object alive even if all other holders call Release() to match their own AddRef()). He was, in other words, thinking as a COM programmer should.George2 were claiming that while a pointer is still pointing (read: has a reference) to the object, it won't go away.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law