|
And how does __uuidof provides strong typed feature?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
if iam wrong pls correct, making use of __uuidof(), CComPtr class makes type safe.
|
|
|
|
|
Rajkumar R wrote: making use of __uuidof(), CComPtr class makes type safe.
I don't think so. Anyway my sign (Iain Clarke's sentence) holds still.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
thanks i left my sign blank for this 
Any way why u don't think so, CComPtr reduces the mismatch between REFIID and ppv that is the question,
I found these as technical discussion, I take this oppurtunity to get more knowledge. I Consider and take care not to be arrogant if so.
|
|
|
|
|
I don't think so. Using a smart pointer maybe useful and has some advantages indeed, but it enforces in no way the relation between the REFFID and LPVOID parameters of CoCreateInstance.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Thanks Rajkumar,
I think what you posted above is the CoCreateInstance implementation of smart pointer class, not the global implementation, right?
regards,
George
|
|
|
|
|
|
Thanks Rajkumar,
Could you give your definition or preferred definition of what is type safe please?
regards,
George
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
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
|
|
|
|
|
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. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I have understood your pattern, Matthew! Thanks for your patience for sharing your experience in this thread. I learned a lot from you.
regards,
George
|
|
|
|
|
Exactly, as the question is about compile time type safety
|
|
|
|
|
Thanks led mike,
For the compile time type safe issue, you mean the one I pointed in my original post?
regards,
George
|
|
|
|
|
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?
regards,
George
|
|
|
|
|
I just meant search the web. Language type safety is what i meant.
|
|
|
|
|
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.
regards,
George
|
|
|
|
|
|
Thanks Rajkumar,
I will read through it.
regards,
George
|
|
|
|
|
Thanks Matthew,
Which rule do you refer in the link from MSDN? Implementing IUnknown?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
