C / C++ / MFC

Rajkumar R11-Feb-08 16:18

11-Feb-08 16:18

But i think u agree that smart pointer provides type safety over untyped LPVOID.

I agree the enforcement on relation between REFFID and LPVOID depends on the __uuidof() or can be use of fashion of REFFID IID_<interface>, but as the __uuidof, even though not enforced, gives one more level advantage to the implementation of smart pointers.

Matthew Faithfull11-Feb-08 6:04

11-Feb-08 6:04

How does calling the pointer you pass for overwriting a CThingy* stop the COM runtime which may be an implementation on a remote machine running under a different OS from overwriting the address you've passed with something that isn't a CThingy* ?

It doesn't and this happens at runtime so no compile time checks can prevent it.
Better to call it a void* to remind you that you don't know what it will be pointing at after the call, except the rules of COM say if the server end works it will safe to cast it to IUnknown* only.

Once you have IUnknown* the rules of COM say it's always safe to call QueryInterface and to believe the result you get.

If in either case the server lets you down the compiler can't help you. If you pretend that it can you won't understand why calling through your CThingy* after the call still crashes even though it looks type safe.

Nothing is exactly what it seems but everything with seems can be unpicked.

Rajkumar R11-Feb-08 16:29

11-Feb-08 16:29

see one of the implementation of CoCreateInstance

__checkReturn HRESULT CComPtrBase::CoCreateInstance(__in REFCLSID rclsid, 
            __in_opt LPUNKNOWN pUnkOuter = NULL, 
            __in DWORD dwClsContext = CLSCTX_ALL) throw()
	{
		ATLASSERT(p == NULL);
		return ::CoCreateInstance(rclsid, pUnkOuter, dwClsContext, 
                    __uuidof(T), (void**)&p);
	}

I don't think your claimed freedom is not here, internally it uses void * as you reminded and HRESULT value is returned to check your server exception. but type safety is achieved as untyped void * is not directly used in a C++ program that i reminding u.

George_George12-Feb-08 2:21

12-Feb-08 2:21

Thanks Rajkumar,

I think what you posted above is the CoCreateInstance implementation of smart pointer class, not the global implementation, right?

regards,
George

Rajkumar R12-Feb-08 2:44

12-Feb-08 2:44

yes, CComPtrBase class.

George_George12-Feb-08 2:57

12-Feb-08 2:57

Thanks Rajkumar,

Could you give your definition or preferred definition of what is type safe please? Smile | :)

regards,
George

Matthew Faithfull12-Feb-08 2:27

12-Feb-08 2:27

This wrapper does not improve type safety at all. Let us say that p is declared as IMySpecialInterface*. How exactly is the external runtime that overwrites the value of p supposed to know whether it is 'allowed' to put a ISomePublicObject* in there or not. It cannot know, it does not check and all this is done at runtime anyway so there is no way to type constrain an addrees that is overwritten by an external process at runtime, during compilation.
Declaring p as a different type will not change the type that is pointed to after the call, ever, it simply disguises the fact that you cannot know what p is pointing to after the call except for the gaurentees that COM gives you.
When using the COM runtime you have the type safety gaurentess that the COM runtime gives you or you have none, you cannot fix this with C++ mechanics.

Nothing is exactly what it seems but everything with seems can be unpicked.

Rajkumar R12-Feb-08 2:43

12-Feb-08 2:43

hi mathew, think in other way, from client point of view, compiler type safety has nothing to do with Runtime it is upto the compilation time, it only gives hint to the programmer to avoid mistakes in the coding, obviously server will overwrite what ever pointer given to it.

I just suggest this, i am clear about it. I am not saying ur COM concept is wrong.

Matthew Faithfull12-Feb-08 2:55

12-Feb-08 2:55

Rajkumar R wrote:
it only gives hint to the programmer to avoid mistakes in the coding

Exactly, which is why in this case void** is the best reminder to the programmer that they should not trust the returned value to be the type they expect because whatever type of pointer they pass in they cannot gaurentee it. They should check with QueryInterface. IUnknown** would be just as good given that COM ensure this much witha validly written server but then the client programmer might forget to check for NULL. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George12-Feb-08 3:08

12-Feb-08 3:08

Hi Matthew,

I have read all of your replies. I am interested in,

what do you mean exactly runtime type safe (not limited in the scope of COM)? Could you give a definition please?

regards,
George

Matthew Faithfull12-Feb-08 3:32

12-Feb-08 3:32

I didn't use the term 'runtime type safe' but if I had it would mean that although the type pointed to by a pointer returned from outside your code (like the result placed in ppv by CoCreateInstance) cannot be gaurenteed when your code is compiled because it cannot be determined, it can be gaurenteed by the external code itself, in this case the COM runtime or the external COM server. Such a gaurentee could be called 'runtime type safety'.
It is in this sense that COM is typesafe, all interfaces are derived from IUnknown which is always implemented so any interface pointers arriving in your process from outside can always be treated safely as IUnknown pointers.
Because this is all that can be gaurenteed this is also all that should be assumed, that is a very important rule of writing good code. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George12-Feb-08 18:00

12-Feb-08 18:00

I have understood your pattern, Matthew! Thanks for your patience for sharing your experience in this thread. I learned a lot from you. Smile | :)

regards,
George

Rajkumar R11-Feb-08 5:06

11-Feb-08 5:06

Exactly, as the question is about compile time type safety

George_George12-Feb-08 2:08

12-Feb-08 2:08

Thanks led mike,

For the compile time type safe issue, you mean the one I pointed in my original post?

regards,
George

George_George12-Feb-08 1:22

12-Feb-08 1:22

Thanks Rajkumar,

For the Google search link you referred about type safe, there are various points which are not all the same. I am wondering which one(s) do you prefer? Smile | :)

regards,
George

Rajkumar R12-Feb-08 1:45

12-Feb-08 1:45

I just meant search the web. Language type safety is what i meant. Smile | :)

George_George12-Feb-08 1:52

12-Feb-08 1:52

Thanks Rajkumar,

What is your preferred definition of type safe (from the discussion, you are so knowledgeable and I think you have your or your preferred definition of type safe)? The search gives me a couple of various definitions of type safe. Smile | :)

regards,
George

Rajkumar R12-Feb-08 2:58

12-Feb-08 2:58

Hi George,
May be this is helpful most definitions involve the use of a type system to prevent certain erroneous or undesirable program behavior (called type errors)[^]

George_George12-Feb-08 3:09

12-Feb-08 3:09

Thanks Rajkumar,

I will read through it. Smile | :)

regards,
George

George_George12-Feb-08 1:20

12-Feb-08 1:20

Thanks Matthew,

Which rule do you refer in the link from MSDN? Implementing IUnknown?

regards,
George

Matthew Faithfull12-Feb-08 2:18

12-Feb-08 2:18

It's Rule number 1.[^]

"Rule #1: Must Implement IUnknown"

Hence the only certain thing about the pointer returned from CoCreateInstance, no matter how you wrap it up, it that it's an IUnknown pointer. Any assumption on top of that is at your own risk. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George12-Feb-08 2:23