OSDev.org

zloba wrote: I find your posting to be quite good, if somewhat disagreeable.

When used properly, it helps manage complexity, by breaking up funcitonality into components.

Look at Java for another such attempt.

been there, done that. not quite the same thing.

Use COM for things it is good at. It is certainly not good in kernel space.

i agree, kernel is a different story (kinda obvious).

...but i find it to be quite good for pretty much anything else i can think of

i do want to keep the same OO, but have more control over it and other things.

and "macros" refer to the concept in general, not excluding templates...

Funny that one of the best books on COM...

interesting, what is the title/author?

i can do everything i need to implement COM objects in C++. its just all the extra typing that i find awkward. mo' typing, mo' typos, mo' time wasted, less gets done.

i talked to a few people having skills similar to mine, and they agreed that C++ could use improvement.

I can hardly picture a language giving me more control than C++, except perhaps Assembly.

well, i can. not only that, i intend to implement one. and yes, i know what that means.

Component and interface based programming: easy with c++ too

Upgradability: c++ can do... child classes?

black-box reuse of binary components: something like the default class stuff, like a class library

remote components: 1. why? there's about no reason to do that

2. there are ENOUGH different methods, think Java's RMI

Reliable functionality discovery? Care to elaborate?

ActiveX is an application of COM? are you trying to get me to use it or loathe it?

We're not trying to reinvent the bicycle, we're reinventing the world.

like the microsoft-haters that make a website against bill using frontpage, ....

You care to imply you need macros instead of const ints, inline functions and similar constructions?

I can have that with C++ classes, Perl modules, Java packages... come again, why do I need COM?

It's the very concept of macros I despise, and templates aren't macros. They're more, and most of all, type- and scope-aware as you demanded.

I might add they also allow to outperform C (!) in several crucial areas.

You didn't yet state where you feel lack of control.

interface IFoo1;
interface IFoo2: IFoo1;
...
class Foo1: public IFoo1{
// implementing a dozen methods of IFoo1
};

class Foo2: public Foo1, public IFoo2{
// now not only do we have to implement those additional methods of IFoo2, but those of IFoo1 as well, if only to delegate to the implementation in the base class Foo1
// what i'd like is to simply indicate that corresponding slots in IFoo2 virtual table should be filled with references to the inherited methods of Foo1, without explicitly delegating calls.
};
// is there a neat way to do that? if you can suggest something, then all this flame won't be in vain one way or another.

zloba wrote: yes, you can do it - with shared libraries. COM is just a way to organize those libraries so your application doesn't have to bother knowing any dirty details, depend on the location, version etc. of course, you can do it manually, but i rather not.

for you, maybe. for me, plenty.

2. there are ENOUGH different methods, think Java's RMI

well i am not using java, duh.

Reliable functionality discovery? Care to elaborate?

you have an interface pointer of type IFoo; you would like to work with interface IBar (that is, if the same component supports IBar), so you ask the first pointer if it supports IBar; you either get a pointer to IBar in return, or an error code stating that it is not supported. from there, you can decide how to proceed with the functionality you have available, to work, to complain to the user, etc.
its really just a way to safely typecast (navigate) between interfaces of the same object.

We're not trying to reinvent the bicycle, we're reinventing the world.

so do i. and my world needs weels and bicycles as an environment-frienly transportation. but this metaphor is getting rather abstract, no?

zloba wrote: What i'd like is to simply indicate that corresponding slots in IFoo2 virtual table should be filled with references to the inherited methods of Foo1, without explicitly delegating calls.

Is there a neat way to do that?

also, i'd like inner objects with the ability to refer to the host object without either explicitly storing a redundant pointer or dirty hack of computing the offset

(and of course the above-mentioned ability to fill missing pure virtual functions with those of the host.)

Well, for claiming you don't use Java your example sure smells of it...

Downside, there is no such thing as "interface" in C++.

Thus you would implement the methods declared by I(nterface)Foo1 right within the class IFoo1, and all classes derived from IFoo1 get those methods.

Now, if you use virtual inheritance, your class Foo2 wouldn't even end up containing multiple instances of IFoo1, either.

COM is just a way to organize those libraries

zloba wrote:

Now, if you use virtual inheritance, your class Foo2 wouldn't even end up containing multiple instances of IFoo1, either.

hmm, i'll have to look into this further. i'm not sure what effect that will have on the virtual tables, and whether that will address the problem as stated.

these features - finer control over inheritance and what goes into the virtual table, inner objects (not just a namespace thing but an integral part of the host, that are allowed to have their own vtables) - would turn implementing COM, whether simple objects or more intricate combinations, from a typing exercise into the neat technique it's meant to be. (not to say it wouldn't be useful for OOP in general)

class IFoo1 {virtual void a() = 0;};
class IFoo2 : public IFoo1 {virtual void b() = 0;};
class IBar : public IFoo1 {void a() { return 1; } };
class IBar2 : public IBar, virtual IFoo2 {
    void b() {return 2;}
};

IBar2::IBar2() : IBar(), IFoo2() {}

2 Candy

COM is just a way to organize those libraries

my bad. COM is not _just_ that, but as far as dynamic libraries are concerned, that's what it does - encapsulates, automates and hides dynamic linking.
and sure, you can do all of that yourself in C++ or even in plain C, one way or another. you wouldn't be able to do COM if you couldn't

something like this.

vtbl.cpp:18: error: cannot allocate an object of type `Bar2'
vtbl.cpp:18: error:   because the following virtual functions are abstract:
vtbl.cpp:4: error:      virtual void IFoo1::foo1()

From an OS devers point of view, it's implementing dynamic linking for C and C++ people, AND implementing it for COM stuff, so why do it twice?

Heh. Yet still, the OsKit framework thinks it's a good idea glueing kernel components together with a COM-like interface. Blah.

zloba wrote: i know that if i implemented methods right in IFoo1/IFoo2, there wouldn't be this problem; however, (I)nterface definintion has to be abstract, since there may be no implementation or multiple implementations, or an implementation outside of the project and in a different language. those are the rules of the game called COM, and that's not to say its not a good idea in general.

Solar wrote:BTW: Do you know whether any other OO language suits COM better? I don't know Smalltalk or Eiffel, but I'd daresay they don't match COM any better than C++ does...

Now, OO-languages do have an object model of their own. ... it can't be the job of a language to mold flawlessly into every other object model out there - not even taking into account that those object models might be mutually exclusive

BTW: Do you know whether any other OO language suits COM better?

I don't know Smalltalk or Eiffel, but I'd daresay they don't match COM any better than C++ does...

C macros are only a shadow of the power that a more complete macro system can give

What this has to do with COM, I haven't a clue

zloba wrote: that's exactly what i meant.

What this has to do with COM, I haven't a clue

not with COM, i just mentioned it in the context of wanting to create a better language.

Schol-R-LEA wrote:I do know something (though not much) those languages, and I can assure you, they are nothing like either C++ or COM. Eiffel is somewhat closer to C++, but Smalltalk is... unique, really. The only language that even resembles it that I know of is Self, and Self was conciously designed as a prototype-based Smalltalk derivative.

If it's flexibility you want, Lisp ant it's relatives are unparallelled (though FORTH is a close match to it).

For those of you not familiar with Self (one of my favorite languages), Self could be reasonably described as a "classless" OOP language (for the proletariat masses... )