Common Object Model Linking

[Solar]

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

OK. I got food and tea now, so let's disagree.

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

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

Look at Java for another such attempt.

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

I didn't say Java is another component technology. (Java Beans are, unless I'm mistaken.) I quoted Java as another attempt at solving all the problems of the universe, another technology hyped as the miracle cure. Just like Java is just another language, COM is just another component technology.

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).

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

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

I haven't felt the need for a component system like that; not in my private projects, and not at work.

Erm... come to think of it, we have some COM at work. My job is with an enterprise-level data distribution service; some customers demanded a COM client interface so they could use our service in their damned Excel sheets, so we wrapped some COM around our C++ client lib... just as we wrapped some XML around the same lib to satisfy some other costumers.

We could have made all the units and components of our server software COM objects. We didn't. Why? Because that would needlessly add another thing to the list of skills you'd need to work on our software. We're very happy using the features of C++, since the only thing we needed COM for was for the Windows clients. There, it was good. Everywhere else, it would just have added code lines, interfaces, and trouble.

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

You didn't yet state where you feel lack of control. If you have issues with C++, feel free to send me a message, and I'll happily try to work out something.

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

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.

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

interesting, what is the title/author?

GoTo COM by Addison Wesley.

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.

Yep. Goes for every language I know of, and that's why I wouldn't touch COM (or any other component technology) unless I need a component technology.

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

I fully ACK with that. The thing is, complex languages have trouble with virtually every kind of component technology, simply because they have a more versatile object model than what those component technologies allow for.

You always have to "squeeze" them into a corset. Just like "managed C++" in the .NET scheme. Simpler languages like C or VB fit in there quite easily, but as a C++ coder, you always "feel" the difference.

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.

Good luck with that. But you'll end up with the chicken-and-egg problem. There are much better languages out there, but no-one uses them because... well, because no-one uses them.

That was one of the reasons why C++ was made a superset of C - you could take your C skills (and C code), and venture into C++ land, step by step. That's what made C++ so successful. And ugly.

I won't doubt you can come up with a "cleaner" language. But will it be as fast, suited for system programming as well as enterprise applications, as well-supported, as well-documented, with so many libraries, compilers, and tutorials available?

Not meaning to discourage you. But the uglyness of C++ and its success go hand in hand, stupid as that may sound.

[zloba]

2 Candy:

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

no argument here, it can be done. in fact, that's how i do it. except COM is not C++

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

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

i mean without recompiling or reconfiguring the application
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.

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

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.

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

i am not trying to convince you to anything, on account of it not being too relevant, and me not having enough experience with ActiveX and not really caring much about it.

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?

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

fyi, i run linux. been running it full-time for more than a year. lately, Linux From Scratch. i also like to criticize linux, but i prefer it for various reasons.

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

as i've already replied, i imply no such thing. "similar constructions" is exactly what i need more of.

[zloba]

2 Solar

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

well if you have it all figured out, then maybe you don't need for me, well consider it "C++ modules and packages"

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.

i know what templates are. i am using them.
now that "macro" confusion seems all sorted out...

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

ok, to the point.

Code: Select all

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.

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.)

[Candy]

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.

I'd call that dynamic linking, but OK, have it your way...

for you, maybe. for me, plenty.

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

well i am not using java, duh.

That doesn't remove you from the options of the others, such as Corba for instance... which was afaik developed before COM...

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.

You mean a dynamic_cast<>() clone?

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?

They're still round things

[Solar]

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?

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

Downside, there is no such thing as "interface" in C++. Upside is that C++ knows multiple inheritance. ;D

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.

You might also want to check out the details of typeof() and instanceof().

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

In C++, contained members don't receive a pointer to their container per se; that's a difference from Java. Here, I'm afraid, you'll have to pass a pointer / reference to the container, either through the individual function call or the constructor of the contained member. Keep away from calculating offsets; that's "dirty" indeed!

"Inner classes", in C++, are solely a namespace thing I'm afraid...

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

...but from what I read here, you're probably looking for a base class with "protected" members and a derived class, anyway instead of an "Inner Class" - or perhaps a "friend" declaration solves your problem.

[BI lazy]

quid quid agis prutender agas et respice finem

in german: was immer du tust, handle klug und bedenke die folgen.

in english: what ever you do, act clever and keep the consequences in mind.

[zloba]

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

never mind the keywords; structurally, this is how i implement COM interfaces.

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

is, too. called abstract base class, with pure virtual functions. which defines methods and a virtual table layout but does not bind to implementation. that's precisely how COM interfaces are expressed 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.

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. you may receive interface definitions as output from the IDL compiler and sticking your implementation in there is not an option.

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)

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

[Candy]

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)

AFAIK, you get only the exact contents that that class added without its parent class. You need to provide that one too however.

Example:

Code: Select all

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() {}

something like this. If you then only virtually inherit these parts of the tree it works (or virtually inherit IBar, but I'm not sure that'd work as nice with it's b-definition. Might though.

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

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?

Off to work... (no, it's not even morning here)

[zloba]

2 Candy

something like this.

no such luck

Code: Select all

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()

when you introduce a new branch of inheritance with incomplete pure virtual functions, you have to deal with each of those explicitly. that is the problem. it results in extra typing and extra layers of the call stack.

but thanks for all suggestions.

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?

its not "doing it twice", it's more like implementing some basic, low-level services, and then making a higher-level abstraction on top of them. low-level services being filesystem, dynamic libraries, process creation, network connections, RPC, and the higher-level abstraction being a COM runtime (or CORBA or whatever) that you ask to instantiate a component and it hands you an interface pointer, regardless of how it is implemented. and COM conventions make it possible for different components to interoperate nicely.

why have a filesystem when you can just directly write to a raw block device? and why even have devices and OSes when you can just work with hardware yourself?

you can replace the shared library with a different version or a different library from a different vendor, at a different path and with different features.
with ordinary applications, you would have to recompile all of them, giving details where to find the library.
with COM, in the worst case you just restart the programs. you can make the presence of an implementation optional. you can use different implementations from different libraries at once.

i am thinking about making a whole COM-based OS
Solar

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

oooh nice i'll definitely check it out, maybe i'll end up reusing them. this is good news indeed, thanks!

i know i am not convincing anyone here. you are not convincing me either. a thorough article would be needed, and maybe i'll write one and maybe you will be so kind as to criticize it.
or i'll keep up the development and eventually release some software to demonstrate the power. (i don't have anything impressive yet, i only recently started GUI development)

[Solar]

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.

That's the point I was aiming at.

C doesn't have an "object model" to speak off. COM basically adds an object model to C, so it's easy to wed those two.

Same goes for Visual Basic.

Now, OO-languages do have an object model of their own. When this object model doesn't match with the object model of some other technology (Corba or SOAP to name two popular ones), it's definitely not the language to blame, since 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.

C++ predated COM by more than five years. You could blame Microsoft for not making COM better usable under the up-and-coming programming language of that time (Java was still a while off then); but certainly not vice versa.

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...

[Schol-R-LEA]

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...

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.

There are things that can be done in Smalltalk that someone who is accustomed to conventional languages would never believe possible; for example, it is possible to add new methods and instance variables to objects at runtime, even programmatically, without halting the running system. This flexibility comes at the price of the bytecode interpretation, however... it is all in what you are willing to pay for. Smalltalk is also very closely bound to it's user environment in most implementations; in systems like Squeak, there really is no such thing as a standalone Smalltalk program. Again, this is a tradeoff, for it means that the Squeak system will behave essentially the same on any platform it runs under, and it always has the tools to work with for any programming or user task. Finslly, because the language is deeply tied into the object browser system, writing Smalltalk code is radically different than programming in any other language - it is not designed to be understood in the linear fashion of most languages, but rather as it is displayed in the class browser, displaying Class Categories, Classes, Method Categories, and Methods. It's syntax, while unconventional, is much more regular than that of most languages, and also much more flexible, and can be learned in a matter of minutes.

Like with Lisp, learning Smalltalk (even a little bit of it) is a truly eye-opening experience, one which can improve you rprogramming in general. I am tempted to say that if you don't know Smalltalk, you really can't fully understand OO programming. I'll admit that I don't know the language as well as I'd like to myself, but the basics of it are easy enough to grasp; there are tutorials which can explain the fundamental concepts to even an inexperienced programmer in under an hour.

As an aside, I agree that C++ inline functions and const declarations are superior to C-style macros, but that's partly because 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; COM, like most MS tools (and indeed most C tools in general) consistently misuses macros to wallpaper over the complexity of the underlying code, without really eliminating it. Once again, the problem is not in the language per se, but in the blinkered attitude of many of it's users, who keep insisting that since they already have a hammer, everything must therefore be a nail. By ignoring all but a handful of the tools and ideas at their disposal, they are ignoring the greater part of the hard-earned wisdom that the computing field has accumulated over the past fifty years.

[zloba]

Solar

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

interesting observation, i didn't think of it that way.
however, i don't think it is the job of a general-purpose language to impose an object model, but to be consistent with its generality and give me the tools (based on OOP principles) and the choice how to use them.
(the tools being, as i see it, inheritance and virtual tables for polymophism, and complete control over them)

the way i see it, all those "language object models" are nothing but limitations of a particular language. unlike them, COM, CORBA and such are indeed object models, as they have objectives and in view of those objectives, define principles and reasons behind them.

with a general-purpose language, what objectives can there be but generality and flexibility? a user may choose to conform to a popular object model, or they may just do their own flavor of OOP, or a combination of these at the same time. the models may be mutually exclusive with each other, but not with the generality of the language.

i understand that for whatever reasons, the authors of c++ did not provide such control. but since there's nothing i can do about c++, there are 2 choices - forget about it and make do with existing tools, or forge my own tools. (isn't what most of you osdevers here do with OSes?)

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

not yet. i shall try, however, to create one that does, and not only COM but C++ style and whatever else is reasonable, and not by dirty hacks or brute force, but orthogonally using the tools provided.

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

this compelled me to take a look at Smalltalk, to reduce my ignorance. meanwhile, Schol-R-LEA posted his comment on Smalltalk, and from what i've seen so far, i tend to agree. this should be fun, and a source of cool ideas.

Schol-R-LEA

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

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]

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.

If Mohammed won't come to the mountain, then the mountain must come to Mohammed.

I don't know enough about COM to judge whether MysterX implements it well or not, but I would expect that, if any existing language could extend itself to meet the COM model, it would be Lisp (or, in this case, Scheme). If it's flexibility you want, Lisp ant it's relatives are unparallelled (though FORTH is a close match to it).

[Dreamsmith]

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.

Eh? Smalltalk and Self use very similar (identical, really) syntax, but their object models are nothing alike. Smalltalk MUCH more closely resembles C++ than Self in terms of its object model. Smalltalk and Self represent extreme ends of a spectrum, with C++ falling between the two, although closer to the Smalltalk end...

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... )

[zloba]

Schol-R-LEA

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

i want flexibility in a conventional, compiled, general-purpose, procedural and OO language which manipulates integers, structures and pointers - like c++ or pascal, that would allow more or less straightforward translation of c/c++ code, logically being a superset with same philosophy but extra control in the OO department. c++ would also do the trick if given said control, but as its syntax, while concise, is notoriously difficult to implement, and gcc's source code is far from obvious, i am not willing to try that hack.

i've had some experience with scheme, and it didn't strike me as extremely readable. neither did FORTH, at which i only had a brief look. they are compuationally complete, but all those nested lists and resuting brackets are not helping. where a normal language does things sequentially, on the same level, lisp goes deeper. afaik, they are of major theoretical interest, but little used in practice, and i can see why.

Dreamsmith

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... )

interesting indeed. i'll check it out.