Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ARGG! VFP send my objects by reference, no by value!!!!
Message
De
08/03/2000 11:13:45
 
 
À
07/03/2000 23:43:34
Information générale
Forum:
Visual FoxPro
Catégorie:
COM/DCOM et OLE Automation
Divers
Thread ID:
00342323
Message ID:
00343288
Vues:
28
>>someFunc(@oObj)
>>
>
>This one's easy - I want to populate an object ref, substitute another object for an existing object referenced in the caller, or completely dereference an object that was passed to a function or method if I choose to assign a new value to the original object reference. Unlike pass by value, this doesn't bump the object's reference counter, since no new reference is being created.
>

I see. Since we have a reference to a reference, we can manipulate the reference (ie reassign what it refers to, or set it to .null.) without disturbing the envioronment?


> a pointer into a vtable. You might want to take a read of:
>
>The COM Programmer's Cookbook
>Crispin Goswell
>Microsoft Office Product Unit
>Spring 1995
>Revised: September 13, 1995

I'll check it out, I am currently reading:
Essential COM
Don Box
Addison-Wesley
3rd Printing, April 1998

I just went over the Details of IUnknown, and QueryInterface. What you said makes the strategy more clear--this level of indirection is what provides the full encapsulation no?

By passing a pointer to a pointer into a vtable back to the caller, we can initialize it, assign it, and handle the reference counting distinct from the caller's namespace, is that the idea? Their pointer that they pass in is a blank space we can fill with whatever interface pointer we choose. That pointer in turn is necessary to allow the independent compilation of the interface's implementation in another file since it points into a vtable that has a standard construct, because interface classes are abstract. Is that right?

I am trying to get under the strategy of COM here. I have a basic (too basic) understanding of how C++ works, but little knowledge of the why's of the types of casting, macros and abstract classes that are common in the COM code--until I started reading this book.

Thanks Ed, it getting clearer. :)

Do you have a recommendation for a next step on the C++ front? I am stuck between knowing the syntax (most of it, the book I have is circa 1995 and so isn't too clear on the various casts and templates)

So I have a rudimentary reading knowledge of the language. For example I can follow what is going on in the COM code but not necessiarily the why.

Do you know of a good book? Not a syntax book, or a learning C++ but a real, "this is how you USE this language" type book. Otherwise its a real Catch 22--I can't write real C++ code until I know it well enough to do real-world code, but I can't get exposed to real-world coding to learn how without picking up work with those who do, and they won't pick me up with just reading knowledge--or something like that.

>>x = someFunc((void**) *&pvar);
>>
>>What is the reason for this?
>>
>
>That's a bizarre recast of a pointer to a pointer...I don't recognize the construct, since *& resolves to self. I'd more expect a construct like (void**) &ptr->, which is used pretty frequently instantiating objects with CoCreateInstance() to receive the interface pointer. I'd expect to receive an interface pointer if I saw it.

Sorry, that's a typo, I left that extra * in there. the example I looked at was how you described, in fact it was CoCreateInstance() I was looking at--although that construct is all through the literature. There is a definite pattern here *s*.

Thanks Ed, you've helped me along. Now I am about to dive into Monikers...

Best,
Bill
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform