> I do whatever seems to be appropriate for the task at hand. In the
> case where I use the get__This property, the objects are tightly
> coupled and require access to many internal class members. Making a
> separate private interface to perform these tasks just to satisfy COM
> is ludicrous and would result in many more lines of code (the project
> is already over 65K lines as it is).
One usually uses accessor functions to access the object's data, and
writing necessary COM methods to access data will be no harder than
writing the accessors. Even if typing them by hand can get too tedious
and error prone, macros can be used to generate them.
> There are other projects where I do exactly
> as you describe and the interfaces in question are not
> exported or published. Those are cases where the builds are
> not integrated and the classes are only loosely coupled.
So, it would be better to point out the safe solution, and *then* state
the especialzed solution which solves your specialized needs (which may
not be those of the OP's), wouldn't it?
> Incidentally, declaring the method as local eliminates any problems
> WRT COM and marshaling as only a direct pointer will work and any
> attempts to use it cross-apartment, much less cross-process or
> cross-machine, (through a proxy) will fail. Thus, portability issues
> are irrelevant and the danger no greater than any other C++ faux pas.
In COM, apartment requirements are part of the implementation details,
so you can't assume anything about your client's apartment. If you make
such an assumption, then your code will break as soon as one of your
assumptions are violated by the client. This is why I consider this
method as potentionally dangerous - although it may work in some cases.
> Also, on a related note, the use of dynamic_cast will return a NULL
> pointer (or toss an exception if you're using a
> reference) if the type information does not match. Comparing
> it's behavior to that of reinterpret_cast is a misnomer --
> it's actually identical to static_cast with the exception of
> the run-time type verification (it will adjust the pointer
> value to reach the proper frame while reinterpret_cast will not).
This is not the point I was trying to make. In VC++, RTTI is
implemented by adding an entry to the object's v-table. COM's interface
method tables are compatible with VC++ object v-tables, as long as there
is no RTTI, and COM relies heavily on this. Adding an entry to the
v-table which COM is not aware of can potentially be dangerous. Of
course I have not tested this myself, but the chances of RTTI breaking
the v-table order in one way or another are not little.
-------------
Ehsan Akhgari
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
"The brightest future will always be based on a forgotten past."
