Steve Clamage wrote in message <7iho3e$1re$1@engnews1.eng.sun.com>...
>
>That is not an implementation detail, it is a fundamental flaw of
>COM relative to C++.

COM is not a language. Your comparison with C++ is therefore a type error.
If anything, it is a target platform, and anyone building a compiler where
every
object was a COM object would find sufficient freedom in the standard to
cope.
After all, my CPU doesn't support even single inheritance, but my compiler
seems happy to layer it all on top.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

fvali@biotrack.com writes:

>In article <7i4q53$6mn$1@engnews1.eng.sun.com>,
>  clamage@eng.sun.com (Steve Clamage) wrote:
>>
>> fvali@biotrack.com writes:
>>
>> >To the best of my knowledge, the only requirement
>> >that COM places on C++ implementations is that they
>> >implement virtual functions (polymorphism) a certain
>> >specific way (which is not in direct conflict with any of
>> >the mandates in the standard).
>>
>> Last time I looked, the COM specification could not accomodate
>> multiple inheritance or virtual base classes.  That is, there
>> was no way to implement them in COM.  Perhaps the spec has
>> been revised to accomodate them.
>>
>As I understand it, it's not that COM can't accomodate multiple
>inheritance or virtual base classes, or a different implementation of
>virtual functions. These implementation details are not addressed by
>the COM specification.

The COM specification I saw did not support the C++ semantics of
virtual base classes with multiple inheritance. That is, given
    class VB { ... };
    class A : public virtual VB { ... };
    class B : public virtual VB { ... };
    class C : public A, public B { ... };
COM could not express the fact that there is only one copy of VB
in the hierarchy. The best you could get would be separate
copies of VB as base classes of A and B in a C object.

That is not an implementation detail, it is a fundamental flaw of
COM relative to C++.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<fvali@biotrack.com> wrote in message news:7hhl36$eki$1@nnrp1.deja.com...
>
> I find it a little irritating that the author would resort to
> type punning using reinterpret_casts (in the instance i
> mentioned, and in others involing COM aggregation) when there
> are other safer and well-defined ways of accomplishing the task.

Using reinterpret casts not only irritating, but *very* common.  In fact,
the first example I'd ever seen in which a well-defined mechanism was used
was the opening post of this thread.  This comes after having read a
multitude of Microsoft example and header (inlined) code.  Clearly, M$ has
assumed that there is no need for their COM code to run on any compiler that
uses a different inheritance implementation than theirs (in the relevant
aspects).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7i4q53$6mn$1@engnews1.eng.sun.com>,
  clamage@eng.sun.com (Steve Clamage) wrote:
>
> fvali@biotrack.com writes:
>
> >To the best of my knowledge, the only requirement
> >that COM places on C++ implementations is that they
> >implement virtual functions (polymorphism) a certain
> >specific way (which is not in direct conflict with any of
> >the mandates in the standard).
>
> Last time I looked, the COM specification could not accomodate
> multiple inheritance or virtual base classes.  That is, there
> was no way to implement them in COM.  Perhaps the spec has
> been revised to accomodate them.
>
>
(I hope the moderator lets this one through)
As I understand it, it's not that COM can't accomodate multiple
inheritance or virtual base classes, or a different implementation of
virtual functions. These implementation details are not addressed by
the COM specification.
What COM does require is that when a table of function pointers is
exposed ('a binary interface'), the table conforms to a certain binary
specification.  If your C++ implementation happens to implement its
virtual function dispatching in a similar fashion, then you can take
advantage of it, and use abstract base classes.
Otherwise you have to manually expose a pointer through which, an
appropriately indexed function pointer can be accessed and called.
The implementation of your COM component can be written entirely in
standard C++, using any or all of C++'s features, as long as when you
expose your interface, you do so according to the binary specification.
That is why I do not see any excuse for COM programmers to resort to
reinterpret_casts, if there is a well-defined way to perform the casting
using static_casts.
The original example I posted is not the worst of it - you should see
the mess that is created when the aggregation of COM components is
written in C++ using type-punning in an attempt to exploit the
similarities of the vtbl implementation of similarly structured yet
unrelated type abstract base classes - yuk!.  I rewrote a working
version without any reinterpret_casts, which involved modifying the type
heirarchy a little bit but I believe in the process the semantics of the
code itself became clearer and easier to comprehend, not to mention that
the code now had the guarantee of the standard that it would behave as i
intended it to behave.
-fais

--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373B4756.51B1@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> fvali@biotrack.com wrote:
>
> > A) As I understand it the following code leads to undefined behavior
> > according to the Standard:
>
> > B) But the following fragment is well-defined:
>
> Right on both count (unless I have missed something)
>
> > The reason this concerns me is because in a book I am reading
> > on COM, the first style is heavily used, and i believe it
> > to lead to behavior that is undefined by the standard.
>
> They probably don't care much about portabillity...
> which might make sens if other parts of the code
> are inherently non portable.
>

To the best of my knowledge, the only requirement
that COM places on C++ implementations is that they
implement virtual functions (polymorphism) a certain
specific way (which is not in direct conflict with any of
the mandates in the standard).
There are other specific requirements (IPC mechanisms, and dynamic
linking of loadable modules) but each OS supports that in its own
way, and implementations provide support for these mechanisms
through keyword extensions that can easily be #defined in order
to be portable - in addition the OS specific API's can be isolated
in a 'component' (according to lakos's defintion), which would
then be the only 'component' that would either have to be rewritten
or that would require extensive preprocessor machinations.


I find it a little irritating that the author would resort to
type punning using reinterpret_casts (in the instance i
mentioned, and in others involing COM aggregation) when there
are other safer and well-defined ways of accomplishing the task.
(I see other problems with the code too, but i think those
are mostly style issues and in my experience are fairly rampant
in books that focus on teaching the reader about the intricacies
of a formal system (other than that defined by the rules of
C++ or good programming style) while using C++ to codify and
explicate the workings of that system)

In my opinion COM developers should very much care about
writing portable code.

-fais


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

fvali@biotrack.com writes:

>To the best of my knowledge, the only requirement
>that COM places on C++ implementations is that they
>implement virtual functions (polymorphism) a certain
>specific way (which is not in direct conflict with any of
>the mandates in the standard).

Last time I looked, the COM specification could not accomodate
multiple inheritance or virtual base classes.  That is, there
was no way to implement them in COM.  Perhaps the spec has
been revised to accomodate them.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Consider the following class heirarchy:

class InterfaceA { public: virtual void someMethod() = 0; };

// Note: since no virtual dtors are involved, do not delete
// ComA through one of its base classes - <cringe>
class ComA : public InterfaceA
{
   virtual void someMethod() { }
   bool queryInterface( const string& interfaceName_, void** v_pp_ )
   {
       assert( v_pp_ );
       *v_pp_ = 0;
       if( interfaceName_ == "InterfaceA" )
          *v_pp_ = static_cast<InterfaceA*>( this );
       return *v_pp_ != 0;
   }
};


A) As I understand it the following code leads to undefined behavior
according to the Standard:


int main()
{
   InterfaceA* a_p = 0;
   ComA ca;
   ca.queryInterface("InterfaceA", (void**)&a_p ); // reinterpret_cast
   a_p->someMethod();
}

B) But the following fragment is well-defined:
int main()
{
   InterfaceA *a_p = 0;
   void *v_p = 0;
   ComA ca;
   ca.queryInterface("InterfaceA", &v_p );
   a_p = v_p ? static_cast<InterfaceA*>(v_p) : 0;
   a_p->someMethod();
}

The reason this concerns me is because in a book I am reading
on COM, the first style is heavily used, and i believe it
to lead to behavior that is undefined by the standard.
What do the rest of you think?
Am I right?

-fais











--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

fvali@biotrack.com wrote:

> A) As I understand it the following code leads to undefined behavior
> according to the Standard:

> B) But the following fragment is well-defined:

Right on both count (unless I have missed something)

> The reason this concerns me is because in a book I am reading
> on COM, the first style is heavily used, and i believe it
> to lead to behavior that is undefined by the standard.

They probably don't care much about portabillity...
which might make sens if other parts of the code
are inherently non portable.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]