Do I need two languages for distributed computing?

[Steven T. Hatton]

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In the
case of CORBA, that means IDL and C++. In the case of ICE, that means
slice and C++. Slice actually looks a lot closer to C++ than does IDL.
Nonetheless, I'm wondering if there is some fundamental limitation in C++
which precludes its use in the situations where these interface definition
languages are used. Any thoughts on this?

If I understand correctly, distributed operating system services is the
primary engineering domain C++ was designed to address.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Victor Bazarov]

Steven T. Hatton wrote:

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In the
case of CORBA, that means IDL and C++. In the case of ICE, that means
slice and C++. Slice actually looks a lot closer to C++ than does IDL.
Nonetheless, I'm wondering if there is some fundamental limitation in C++
which precludes its use in the situations where these interface definition
languages are used. Any thoughts on this?
The "fundamental limitation" you're asking about is a simple trait of
being too generic. You _can_ define "interfaces" in C++, only it's gonna
be probably _less_efficient_ than with a language *specifically designed*
to do that.
If I understand correctly, distributed operating system services is the
primary engineering domain C++ was designed to address.

C++ wasn't designed to address _any_ specific engineering domain. It was
designed to address a broad variety of engineering problems.

V

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In the
case of CORBA, that means IDL and C++. In the case of ICE, that means
slice and C++. Slice actually looks a lot closer to C++ than does IDL.
Nonetheless, I'm wondering if there is some fundamental limitation in C++
which precludes its use in the situations where these interface
definition
languages are used. Any thoughts on this?

The "fundamental limitation" you're asking about is a simple trait of
being too generic. You _can_ define "interfaces" in C++, only it's gonna
be probably _less_efficient_ than with a language *specifically designed*
to do that.

That kind of begs the question. It implies there are features that the
specialized language provides which C++ lacks. What are they? The
interface definitions are typically not directly compiled into source code.
They are usually translated into stubs and skeletons in some implementation
language (such as C++), and the stubs and skeletons are then implemented in
the target language. That means efficiency of the resulting program
probably isn't a motivating factor. The advantages would be at design
time.

Is this primarily a prohibitive feature of the interface language? That is,
in the interface language you cannot use features which would compromise
the proper design of the interface because those features are not part of
the language.

If I understand correctly, distributed operating system services is the
primary engineering domain C++ was designed to address.

C++ wasn't designed to address _any_ specific engineering domain. It was
designed to address a broad variety of engineering problems.

V

If "primarily" is taken to mean "in the first place", I would say C++ was
primarily designed to address the area of distributed operating system
facilities.

http://www.research.att.com/~bs/bs_faq.html#why
Q:Why did you invent C++?
A:"I wanted to write efficient systems programs in the styles encouraged by
Simula67. To do that, I added facilities for better type checking, data
abstraction, and object-oriented programming to C. The particular projects
that prompted this work had to do with distributing operating system
facilities across a network. The more general aim was to design a language
in which I could write programs that were both efficient and elegant. Many
languages force you to choose between those two alternatives.

"The specific tasks that caused me to start designing and implementing C++
(initially called "C with Classes") had to do with the design of a
distributed operating system.

"You can find more detailed explanations in The Design and Evolution of
C++."

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Karl Heinz Buchegger]

"Steven T. Hatton" wrote:

[snip]
"The specific tasks that caused me to start designing and implementing C++
(initially called "C with Classes") had to do with the design of a
distributed operating system.

And?
BS started to devlop C++ because he had problems with the design of an
distributed operating system. That does not mean that C++ was designed
to address distributed operating systems. In fact *standard C++* as
it is in use today, carefully avoids *any* operating system specific issues.

--
Karl Heinz Buchegger
kb******@gascad.at

[John Carson]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:kO********************@speakeasy.net

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In
the case of CORBA, that means IDL and C++. In the case of ICE, that
means slice and C++. Slice actually looks a lot closer to C++ than
does IDL. Nonetheless, I'm wondering if there is some fundamental
limitation in C++ which precludes its use in the situations where
these interface definition languages are used. Any thoughts on this?

I don't know anything about CORBA, but rumour has it that is does some of
the same things as COM. From my very slight knowledge of COM, I would
venture the tentative opinion that the limitation in C++ is twofold:

1. Static (compile time) rather than dynamic (run-time) linking.
2. The lack of any standard requirements of binary compatibility in compiled
C++ code (so code compiled with one compiler is not in general useable by
another compiler --- or indeed different versions of the same compiler).

These things mean that interface and implementation are not separate at a
binary level, even if they are separate at a source code level. Thus, with
traditional C++, a change to a library implementation requires the entire
project to be recompiled (and compiled separately for different compilers
and platforms).
--
John Carson

[vindhya]

There is a big difference between corba and c++. Corba catters to
different langauages. Like if I have an idl defined then I can couple
it with C++/Java/any other lang having an idl compiler.
Corba didnt involved as a distributed architecture model only rather it
was like a bridge which used to create interfaces so that application
can be platform independent. Any language adhering to Object Oriented
architecture can support and can talk to applications programmed in IDL
supporting language.

[John Carson]

"vindhya" <ma*********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com

There is a big difference between corba and c++. Corba catters to
different langauages. Like if I have an idl defined then I can couple
it with C++/Java/any other lang having an idl compiler.
Corba didnt involved as a distributed architecture model only rather
it was like a bridge which used to create interfaces so that
application can be platform independent. Any language adhering to
Object Oriented architecture can support and can talk to applications
programmed in IDL supporting language.

COM likewise bridges different languages.

--
John Carson

[Steven T. Hatton]

Karl Heinz Buchegger wrote:

"Steven T. Hatton" wrote:

[snip]

"The specific tasks that caused me to start designing and implementing
C++ (initially called "C with Classes") had to do with the design of a
distributed operating system.

And?
BS started to devlop C++ because he had problems with the design of an
distributed operating system. That does not mean that C++ was designed
to address distributed operating systems. In fact *standard C++* as
it is in use today, carefully avoids *any* operating system specific
issues.

That is quite a different thing. C++ is intended to "Leave no room for a
lower-level language below C++ (except assembler)." That means to me C++
is intended to be able to directly access resources which are in the domain
of operating system control. C++ carefully avoids issues specific to any
*particular* operating system. IOW, it is not a Windows programming
language, nor a Unix programming language. It is OS-independent.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

John Carson wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:kO********************@speakeasy.net

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In
the case of CORBA, that means IDL and C++. In the case of ICE, that
means slice and C++. Slice actually looks a lot closer to C++ than
does IDL. Nonetheless, I'm wondering if there is some fundamental
limitation in C++ which precludes its use in the situations where
these interface definition languages are used. Any thoughts on this?
I don't know anything about CORBA, but rumour has it that is does some of
the same things as COM. From my very slight knowledge of COM, I would
venture the tentative opinion that the limitation in C++ is twofold:

1. Static (compile time) rather than dynamic (run-time) linking.

That seems like an implementation detail.
2. The lack of any standard requirements of binary compatibility in
compiled C++ code (so code compiled with one compiler is not in general
useable by another compiler --- or indeed different versions of the same
compiler).
I believe that is more of an OS issue than a language issue.
These things mean that interface and implementation are not separate at a
binary level, even if they are separate at a source code level. Thus, with
traditional C++, a change to a library implementation requires the entire
project to be recompiled (and compiled separately for different compilers
and platforms).

Agreed. But it seems reasonable that someone could design a protocol which
says "given a pure virtual interface we can link against it with any
conforming implementation". In many cases the same dependencies you
mentioned above apply when working with Java app servers. Just because
your code will run without modification to the source on a different
version of an app server, doesn't mean you don't need to recompile it
before it will run. Ideally, of course, that should not apply to the calls
that go across the exposed interface.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[John Carson]

The point is that, while C++ can be extended in various ways to allow binary
modules to communicate more readily and while C++ has in fact been so
extended, such extensions are not part of standard C++.

--
John Carson

[Steven T. Hatton]

John Carson wrote:

The point is that, while C++ can be extended in various ways to allow
binary modules to communicate more readily and while C++ has in fact been
so extended, such extensions are not part of standard C++.

What does it mean, when specifying the qualities of an ideal interface, to
say that it should be possible to transmit the request for service over a
thin wire for service at a remote server.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Howard]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:06********************@speakeasy.net...

John Carson wrote:

The point is that, while C++ can be extended in various ways to allow
binary modules to communicate more readily and while C++ has in fact been
so extended, such extensions are not part of standard C++.

What does it mean, when specifying the qualities of an ideal interface, to
say that it should be possible to transmit the request for service over a
thin wire for service at a remote server.
--

Who cares? It means diddly to me! What's it got to do with the point of
this newsgroup? Is there some actual C++ problem you're trying to solve, or
are you just playing troll again?

-Howard

[Steven T. Hatton]

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:06********************@speakeasy.net...

John Carson wrote:

The point is that, while C++ can be extended in various ways to allow
binary modules to communicate more readily and while C++ has in fact
been so extended, such extensions are not part of standard C++.

What does it mean, when specifying the qualities of an ideal interface,
to say that it should be possible to transmit the request for service
over a thin wire for service at a remote server.
--

Who cares? It means diddly to me! What's it got to do with the point of
this newsgroup? Is there some actual C++ problem you're trying to solve,
or are you just playing troll again?

I've never played troll on this news group. If you don't like the questions
I ask then don't respond. As for my question, it seems perfectly relevant
since "it should be possible to transmit the request for service over a
thin wire for service at a remote server" is a direct quote from
TC++PL(SE).
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Artie Gold]

Steven T. Hatton wrote:

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:06********************@speakeasy.net...

John Carson wrote:

The point is that, while C++ can be extended in various ways to allow
binary modules to communicate more readily and while C++ has in fact
been so extended, such extensions are not part of standard C++.
What does it mean, when specifying the qualities of an ideal interface,
to say that it should be possible to transmit the request for service
over a thin wire for service at a remote server.
-- Who cares? It means diddly to me! What's it got to do with the point of
this newsgroup? Is there some actual C++ problem you're trying to solve,
or are you just playing troll again?

I've never played troll on this news group. If you don't like the questions

Well, whether you realize it or not, you have.
I ask then don't respond. As for my question, it seems perfectly relevant
since "it should be possible to transmit the request for service over a
thin wire for service at a remote server" is a direct quote from
TC++PL(SE).

Is it possible? Absolutely. Assuming you control both ends of the `pipe'
you may define whatever protocol you like. In a simple case, it wouldn't
be terribly difficult. The fact that making it general is non-trivial is
why the `other' languages (defining interfaces) exist.

HTH,
--ag

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

[Howard]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:5t********************@speakeasy.net...

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:06********************@speakeasy.net...

John Carson wrote:

The point is that, while C++ can be extended in various ways to allow
binary modules to communicate more readily and while C++ has in fact
been so extended, such extensions are not part of standard C++.

What does it mean, when specifying the qualities of an ideal interface,
to say that it should be possible to transmit the request for service
over a thin wire for service at a remote server.
--
Who cares? It means diddly to me! What's it got to do with the point of
this newsgroup? Is there some actual C++ problem you're trying to solve,
or are you just playing troll again?

I've never played troll on this news group.

I would tend to disagree there. Most of your posts seem to be of a
philosophical bent, or at least better suited to comp.std.c++ than here.
Here we try to avoid discussing the "why" of C++, and concentrate on the
"how".
If you don't like the questions
I ask then don't respond. As for my question, it seems perfectly relevant
since "it should be possible to transmit the request for service over a
thin wire for service at a remote server" is a direct quote from
TC++PL(SE).

Without chapter and verse, I'm left wondering what the context of that quote
was. I doubt that it had anything to do with the specific requirements for
the C++ _language_. And I still fail to see the relevance of the quote to
the post to which it replied. Step outside your mind-set for a moment and
read that first paragraph. Then read your response. What does one have to
do with the other?

Now, speaking of TC++PL(SE), it seems obvious you've been reading some of
the early text there. Did you happen to read this part (Ch.1, pp10-11)?:

"C++ was designed primarily so that my friends and I would not have to
program in assembler, C, or various modern high-level languages. Its main
purpose was to make writing good programs easier and more pleasant for the
individual programmer."

Here we see the main purpose of the C++ language at its beginnings. It
wasn't to allow the user to directly access mice, networks, threads,
processes, or keyboards (i.e., operating system resources), but simply to
allow them to write better programmers more easily.

-Howard

[Steven T. Hatton]

Artie Gold wrote:

Steven T. Hatton wrote:

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:06********************@speakeasy.net...
John Carson wrote:

> The point is that, while C++ can be extended in various ways to allow
> binary modules to communicate more readily and while C++ has in fact
> been so extended, such extensions are not part of standard C++.
What does it mean, when specifying the qualities of an ideal interface,
to say that it should be possible to transmit the request for service
over a thin wire for service at a remote server.
--
Who cares? It means diddly to me! What's it got to do with the point
of
this newsgroup? Is there some actual C++ problem you're trying to
solve, or are you just playing troll again?

I've never played troll on this news group. If you don't like the
questions

Well, whether you realize it or not, you have.

In your opinion, which you would do well to keep to yourself.

I ask then don't respond. As for my question, it seems perfectly
relevant since "it should be possible to transmit the request for service
over a thin wire for service at a remote server" is a direct quote from
TC++PL(SE).

Is it possible? Absolutely. Assuming you control both ends of the `pipe'
you may define whatever protocol you like. In a simple case, it wouldn't
be terribly difficult. The fact that making it general is non-trivial is
why the `other' languages (defining interfaces) exist.

HTH,

It says very little of substance regerding the question.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:5t********************@speakeasy.net... I would tend to disagree there. Most of your posts seem to be of a
philosophical bent, or at least better suited to comp.std.c++ than here.
Here we try to avoid discussing the "why" of C++, and concentrate on the
"how".

I have posted to comp.std.c++ often. But I really don't care what your
opinions about my conduct are.

If you don't like the questions
I ask then don't respond. As for my question, it seems perfectly
relevant since "it should be possible to transmit the request for service
over a thin wire for service at a remote server" is a direct quote from
TC++PL(SE).

Without chapter and verse, I'm left wondering what the context of that
quote
was. I doubt that it had anything to do with the specific requirements
for
the C++ _language_. And I still fail to see the relevance of the quote to
the post to which it replied. Step outside your mind-set for a moment and
read that first paragraph. Then read your response. What does one have
to do with the other?

The relevance is quite clear. §24.4.2
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Victor Bazarov]

Steven T. Hatton wrote:

Artie Gold wrote:

Steven T. Hatton wrote:

[..]
I've never played troll on this news group. If you don't like the
questions
Well, whether you realize it or not, you have.

In your opinion, which you would do well to keep to yourself.

Actually, not only in Artie's opinion. But that's not why I decided to
reply. You would do really well by not telling others to keep their
opinion to themselves. If you don't like what other people are saying
about your posting habits, either ignore it or change your habits. We
all here have the *right* to post our opinions. Get it? Good.
[..]

[Victor Bazarov]

Steven T. Hatton wrote:

[..] I really don't care what your
opinions about my conduct are.
Too bad. That's a sure method to find a way into people's killfiles.
If you're having a bad day, deal with the reason, not with bystanders.
[..]

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

[..] I really don't care what your
opinions about my conduct are.

Too bad. That's a sure method to find a way into people's killfiles.
If you're having a bad day, deal with the reason, not with bystanders.

[..]

D&E 9.4.3. I just read that for the first time in the past 15 minutes.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Howard]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:6K********************@speakeasy.net...

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:5t********************@speakeasy.net...

I would tend to disagree there. Most of your posts seem to be of a
philosophical bent, or at least better suited to comp.std.c++ than here.
Here we try to avoid discussing the "why" of C++, and concentrate on the
"how".

I have posted to comp.std.c++ often. But I really don't care what your
opinions about my conduct are.

You've also posted to some religion-oreiented newsgroups, (where I see
you've earned massive flame points). But that doesn't make your posts here
any more topical.

If you don't like the questions
I ask then don't respond. As for my question, it seems perfectly
relevant since "it should be possible to transmit the request for
service
over a thin wire for service at a remote server" is a direct quote from
TC++PL(SE).

Without chapter and verse, I'm left wondering what the context of that
quote
was. I doubt that it had anything to do with the specific requirements
for
the C++ _language_. And I still fail to see the relevance of the quote
to
the post to which it replied. Step outside your mind-set for a moment
and
read that first paragraph. Then read your response. What does one have
to do with the other?

The relevance is quite clear. '24.4.2

That section discusses the "ideal" component interface definition, and this
particular sentence describes how the argument of such an interface ought to
be self-describing, to the extent that if it _were_ sent over such a "thin
wire", the "server" would be able to deduce the nature of the argument from
its contents. (As stated in the sentence preceding your quote.)

What the heck that has to do with the paragraph to which you repsonded, you
have failed to make clear in any way. Here's that paragraph again:

"The point is that, while C++ can be extended in various ways to allow
binary
modules to communicate more readily and while C++ has in fact been so
extended, such extensions are not part of standard C++."

You were being told that there _do_exist extensions to the C++ language
(e.g., COM, CORBA) which provide the type of services you were asking about,
but that the C++ language _as described by the standard_, does not define
such extensions.

Care to describe how the ideal of self-describing interface arguments
relates to that fact?

-Howard

[Steven T. Hatton]

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:6K********************@speakeasy.net...
You've also posted to ...
I'm not the topic of this newsgroup.

"The point is that, while C++ can be extended in various ways to allow
binary
modules to communicate more readily and while C++ has in fact been so
extended, such extensions are not part of standard C++."

You were being told that there _do_exist extensions to the C++ language
(e.g., COM, CORBA) which provide the type of services you were asking
about, but that the C++ language _as described by the standard_, does not
define such extensions.

Care to describe how the ideal of self-describing interface arguments
relates to that fact?

COM and CORBA are _not_ extensions to the C++ programming language. I cannot
address that "fact" because it isn't a fact.

I never suggested there needed to be any extension to C++ in order to
achieve what I was asking about. I had already discussed CORBA's IDL in
the first post to this thread. That, AAMOF, is what the original question
was asking about. Do I need IDL(or slice) AND C++ to build distributed
compting systems? The example of passing an interface across a network
connection, though a bit nebulous, hits directly on the issues related to
distrubuted computing in the realm of _interface_ definition languages.

Now if you want to contend that C++ would require a language extension then
you should do so in a way that demonstrates that need. My proposal is that
there is no need for an additional language or language extension in order
to build distributed computing systems with C++.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[John Carson]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:dN********************@speakeasy.net

COM and CORBA are _not_ extensions to the C++ programming language. I
cannot address that "fact" because it isn't a fact.

I never suggested there needed to be any extension to C++ in order to
achieve what I was asking about. I had already discussed CORBA's IDL
in the first post to this thread. That, AAMOF, is what the original
question was asking about. Do I need IDL(or slice) AND C++ to build
distributed compting systems? The example of passing an interface
across a network connection, though a bit nebulous, hits directly on
the issues related to distrubuted computing in the realm of
_interface_ definition languages.

Now if you want to contend that C++ would require a language
extension then you should do so in a way that demonstrates that need.
My proposal is that there is no need for an additional language or
language extension in order to build distributed computing systems
with C++.

I adopt a policy of giving parsimonious replies to your questions since
there is always the threat of an explosive increase in the scope of the
discussion and I don't have a spare lifetime to devote to these discussions.

Chapter 1 of Don Box's book Essential COM is called "COM as a better C++". I
suspect that a reading of it would help answer many of your questions.

--
John Carson

[Steven T. Hatton]

John Carson wrote:

I adopt a policy of giving parsimonious replies to your questions since
there is always the threat of an explosive increase in the scope of the
discussion and I don't have a spare lifetime to devote to these
discussions.
Good for you.
Chapter 1 of Don Box's book Essential COM is called "COM as a better C++".
I suspect that a reading of it would help answer many of your questions.

They can call it what they will. Lots of people call their product "better
C++". That's what some people have called Java. That doesn't make it so.
There are many distributed object technologies. XPCOM, COM, CORBA, DCOP,
ICE(as in zeroc.com), etc. There are also closely related technologies
such as RPC, RPC-XML, SOX, etc. Why should I waste my time with a
propriatery technology restricted to one platform? That's the problem, not
the solution.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[John Carson]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:lO********************@speakeasy.net

John Carson wrote:

Chapter 1 of Don Box's book Essential COM is called "COM as a better
C++". I suspect that a reading of it would help answer many of your
questions.

They can call it what they will. Lots of people call their product
"better C++". That's what some people have called Java. That
doesn't make it so. There are many distributed object technologies.
XPCOM, COM, CORBA, DCOP, ICE(as in zeroc.com), etc. There are also
closely related technologies such as RPC, RPC-XML, SOX, etc. Why
should I waste my time with a propriatery technology restricted to
one platform? That's the problem, not the solution.

I will ignore the predictable troll and remark that you are missing my
point. My point is not to argue for COM or any other technology, proprietary
or otherwise. The chapter I cited does not actually discuss COM at all.
Rather, it describes how you could use C++ to engineer a COM-like solution
(the fact that the C++ techniques described do this is only announced in the
last sentence of the chapter).

Having COM (or, to maintain virtue, some open source alternative) serves
various purposes, including enforcing the disciplines that a C++ solution
would require and providing inter-operability between different languages.

--
John Carson

[Steven T. Hatton]

John Carson wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:lO********************@speakeasy.net I will ignore the predictable troll and remark that you are missing my
point. My point is not to argue for COM or any other technology,
proprietary or otherwise. The chapter I cited does not actually discuss
COM at all. Rather, it describes how you could use C++ to engineer a
COM-like solution (the fact that the C++ techniques described do this is
only announced in the last sentence of the chapter).

Having COM (or, to maintain virtue, some open source alternative)
There is a distinction between open source and open standard.
serves
various purposes, including enforcing the disciplines that a C++ solution
would require and providing inter-operability between different languages.

If I understand the implication of the use of the word "disciplines" in this
context, it would appear that the discussion in the book you have cited is
in agreement with my suggestion that the advantage these interface
languages add is basically prohibitive.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[arketype]

>Now if you want to contend that C++ would require a language extension then

you should do so in a way that demonstrates that need. My proposal is that
there is no need for an additional language or language extension in order
to build distributed computing systems with C++

YES it is possible to build DS with strait C++, you just have to
convince all your clients to adhere to your C++ standard interface,
find a way to guarantee link compatibility, plus myriad other issues.
If you like, you can build a distributed computing system with assembly
and QBASIC. IDL and COM are standards that some consortium has agreed
to.

Normally when I think of distributed computing I think of hundreds or
thousands of nodes on various platforms, hence standards are important.

JJJ

[Zorro]

This is very well put. C++ is a great object-oriented system language.
A distributed operating system was an interesting idea of the past, as
an example of a distributed (system level) application. Now we really
need to make Distributed Applications spanning over many operating
systems that were not considered in those days, like PDA, and cell
phones. The following articles will put you on the right path.

http://www.zhmicro.com/evolution.htm
http://distributed-software.blogspot...able-is-z.html

Regards.

[Zorro]

Indeed. Furthermore, extension means including all of C++ and providing
more, not less than C++. However, there is a big difference between
adding some libraries (which is not different from CORBA), and actually
extending the language grammatically. For the latter, take a look at
Z++.

http://www.zhmicro.com

Regards.

[Steven T. Hatton]

ar******@myrealbox.com wrote:

Now if you want to contend that C++ would require a language extension
then
you should do so in a way that demonstrates that need. My proposal is
that there is no need for an additional language or language extension in
order to build distributed computing systems with C++

YES it is possible to build DS with strait C++, you just have to
convince all your clients to adhere to your C++ standard interface,
find a way to guarantee link compatibility, plus myriad other issues.
If you like, you can build a distributed computing system with assembly
and QBASIC. IDL and COM are standards that some consortium has agreed
to.

Normally when I think of distributed computing I think of hundreds or
thousands of nodes on various platforms, hence standards are important.

JJJ

IDL doesn't specify anything but the interface. All the other issues remain
regardless of whether IDL is used. I guess it's the lack of a clear
concept of interface in C++ which has led to the introduction of these
interface languages.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Zorro]

I will confine myself to the subthread starting at 22, through 27.

The question posted is not religious. It is outrage resulting from
obvious mess we are in.

Don Box (in that book) also proves (in his mind) that COM is an
equivalence relation. Ignoring the proof and looking at his result, so
what is the use of an equivalence relation with every equivalence class
containing exactly on element? Of course equality is an equivalence
relation, but I suppose Don does not know about that.

There is no point wasting time on the obsolate religion of COM.

Pragmatically speaking, it is not possible to do distributed computing
with C++. This is so even if GNU compiler is used on all platforms. As
mentioned elsewhere in this thread, standards are needed for
communication protocols among lots of other issues. C++ will never make
it to distributed computing as a language on its own, because the
domain of C++ is the same as C, i.e. system programs, not platform
independent distributed applications.

There is only one solution to this problem, assuming that C++ is the
most popular system language (I think it is the only one, except for
its subset C). An infrastructure is needed to support platform free
distributed computing, without any protocol standards etc. This
infrastructure must support a language that contains all of C++ as a
subset. That way, a C++ programmer does not need to learn a new
language, and existing C++ code will remain usable. The language must
be the same for all kinds of platforms. For instance, Java for this/
and Java for that contradicts its claim to be platform independent.

There is such a language, and the infrastructure to support it.

Regards.

[Ian]

Steven T. Hatton wrote:

IDL doesn't specify anything but the interface. All the other issues remain
regardless of whether IDL is used. I guess it's the lack of a clear
concept of interface in C++ which has led to the introduction of these
interface languages.

No, they exist in their own right as a language neutral way of defining
an interface.

Ian

[arketype]

NO, in fact an IDL would be pretty useless if it did not provide
linking guarantees. In fact this is arguably one of the most important
aspects of an IDL.

JJJ

[Steven T. Hatton]

ar******@myrealbox.com wrote:

NO, in fact an IDL would be pretty useless if it did not provide
linking guarantees. In fact this is arguably one of the most important
aspects of an IDL.

JJJ

In the IDL specification I see nothing about linking guarantees. When
incorporated into a larger system, perhaps one could argue that linking
guarantees are provided. But the language itself does not provde such
guarantees, and the facilities which do provide the support do no rely on,
nor require IDL. AAMOF, one could program CORBA applications purely in
C++. In the end, that's what happens when IDL is used with the C++
language binding. IDL is translated into C++ skeletons and stubs which
form the basis of the actual application.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[REH]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:kO********************@speakeasy.net...

I came across this while looking for information on C++ and CORBA:
http://www.zeroc.com/ice.html. It got me to wondering why I need two
different languages in order to write distributed computing apps. In the
case of CORBA, that means IDL and C++. In the case of ICE, that means
slice and C++. Slice actually looks a lot closer to C++ than does IDL.
Nonetheless, I'm wondering if there is some fundamental limitation in C++
which precludes its use in the situations where these interface definition
languages are used. Any thoughts on this?

If I understand correctly, distributed operating system services is the
primary engineering domain C++ was designed to address.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand
Russell

CORBA's IDL look a lot like C. So you shouldn't have any trouble. CORBA
allows you to concentrate on your software and let it worry about the
distributed communication without you having to re-invent the wheel. Plus,
client software can be written in any language that supports a CORBA ORB
without even knowing your software is C++. They don't even have to know
what ORB you are using.

CORBA can make your life a lot easier. Implementing the transport (i.e.,
sockets) and the marshalling (data packing/unpacking) yourself is
non-trivial, especially when you consider such things as error recovery.
Put that on top of the software you already have to write, and that a load
of work. With CORBA, making a distributed call in your software is not much
harder than invoking class member.

REH

[arketype]

Which IDL specification? IDL is not homogenous, it just stands for
Interface Definition (or Description) Language. The Queens University
IDL has colonized the acronym, but there are any number of IDL's. ALL
IDL's I have encountered DO provide link guarantees.
You can write (almost) anything in (almost) any language, so
technically you are correct, however you are making it very difficult
for yourself. Please do not trivialize link compatibility betwen
languages and compilers, it is an enormous undertaking to make
languages using various compilers (and possibly VM's) on various
platforms to communicate with each other.

JJJ

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

Artie Gold wrote:

Steven T. Hatton wrote:

[..]
I've never played troll on this news group. If you don't like the
questions

Well, whether you realize it or not, you have.

In your opinion, which you would do well to keep to yourself.

Actually, not only in Artie's opinion. But that's not why I decided to
reply. You would do really well by not telling others to keep their
opinion to themselves. If you don't like what other people are saying
about your posting habits, either ignore it or change your habits. We
all here have the *right* to post our opinions. Get it? Good.

It's rather perplexing that I would be accused of "trolling" simply because
I asked a question about distributed systems in relationship to C++. I was
simply looking at various approaches to the general design domain, and was
also reflecting on some of the appearant limitations I find in C++ related
to interfaces. All of these issues seem interrelated, and the various
interface definition languages, and distrubuted computing architectures
seemed to draw attention to something worth thinking about. There are a
multitude of directions an investigation of this nature might take. Rather
than try to choose one of these and focus on it, I decided to simply bring
up the topic and see what people's thought were on it.

One of the aspects of distributed computing which I find illuminating is how
much it reveals about the design of non-distrubuted systems. I'm thinking
in particular about such issues as compile-time dependencies resulting from
the exposure (to the compiler) of member variables in a class. There seems
to be a compromise in designing classes with local variables as opposed to
pointer members referencing objects on the freestore. The former seems
ideal from the resource management perspective, but the latter seems more
suited to inter-component (de)coupling.

The design of distributed systems forces notions of inter-component and
inter-process communication to the fore. At the time I started this
thread, the topic seemed like a good way of examining how programmers and
systems deal with issues related to interfaces in C++.

Once upon a time there was a graduate student working on software to
simulate distrubuted systems. The focus was on composing software out of
well-delimited modules. The object oriented programming language he was
using was conceptually well suited to the design challenges, but the
compile time, and runtime performance were crippling to the objectives of
the project. He therefore decided to switch to a very low-level
programming language in order to create a useful program and thereby earn
his PhD. This experience made the young Dane swear never again to
undertake such a project with tools so unsuited to the task.

At one extreme was Simula with its powerful notions of abstraction and
object orientation, at the other extreme was BCPL which made C look like a
high-level language. The young Dr. Stroustrup then had the good fortune to
lean C from the very men who had created it. At some point he thought to
himself "Do I need two languages for distributed computing?". His answer
was: "No, I shall create a new and better language by fusing the ideas of C
and Simula"...

The moral of the story? Replace the CPP with an interface language.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Howard]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:dN********************@speakeasy.net...

Howard wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:6K********************@speakeasy.net...

You've also posted to ...

I'm not the topic of this newsgroup.

"The point is that, while C++ can be extended in various ways to allow
binary
modules to communicate more readily and while C++ has in fact been so
extended, such extensions are not part of standard C++."

You were being told that there _do_exist extensions to the C++ language
(e.g., COM, CORBA) which provide the type of services you were asking
about, but that the C++ language _as described by the standard_, does not
define such extensions.

Care to describe how the ideal of self-describing interface arguments
relates to that fact?

COM and CORBA are _not_ extensions to the C++ programming language. I
cannot
address that "fact" because it isn't a fact.

Perhaps a poor choice of words on my part. But, you still never addressed
what your response had to do with the question to which it responded. I
must assume that you have no intention to do so. Given that, no sense in me
trying again. Later.
-H

[Steven T. Hatton]

Howard wrote:

Perhaps a poor choice of words on my part. But, you still never addressed
what your response had to do with the question to which it responded. I
must assume that you have no intention to do so. Given that, no sense in
me
trying again. Later.
-H

It was a rhetorical question intended to suggest that one could use C++ for
creating distributed systems without COM, CORBA or other "languages
extensions".
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

ar******@myrealbox.com wrote:

Which IDL specification? IDL is not homogenous, it just stands for
Interface Definition (or Description) Language. The Queens University
IDL has colonized the acronym, but there are any number of IDL's. ALL
IDL's I have encountered DO provide link guarantees.
I meant the OMG IDL. It looks as though the common theme of IDL programming
is to create the interface declaration in the interface language, and then
"compile" it to create stubs for the implementation. Most of what I've
seen has to do with the creation of client/server relationships of some
kind. But I don't claim to be an expert (yet).

I will say this. google for distributed computing IDL, and see what
proportion of the hits deal with C++. I know that is not a perfect metric,
but it's an indicator.
You can write (almost) anything in (almost) any language, so
technically you are correct, however you are making it very difficult
for yourself.
I'm not sure what I'm making difficult for myself. If you are suggesting
that I use existing technology rather than reimplement the wheel, I
probably will use the best existing technology (as I currently am). Part
of the reason I started this thread is because I want to investigate the
existing capabilities and limitations of C++. If existing capabilities are
revealed, then we can use them. If limitations are exposed, perhaps they
can be addressed by modifications to the Standard. I actually have a
thread going on comp.std.c++ regarding the topic of interfaces.
Please do not trivialize link compatibility betwen
languages and compilers, it is an enormous undertaking to make
languages using various compilers (and possibly VM's) on various
platforms to communicate with each other.

JJJ

I'm not completely sure of what you mean. There are two distinct concepts
we seem to be dealing with. One has to do with the interface through which
an object (module, component, service, etc.) is accessed. The other is how
this communication is achieved. It is the former which I am specifically
interested in. The latter is of relevance in so much as it impacts and
constrains the former. I guess your point is the IDL provides a "contract"
language for formalizing how different components interact. Mind you, my
focus in asking this question was not on language neutrality. It was
specifically directed toward C++.

But to follow your tangent, suppose I took things from a different
direction. Suppose I specified a convention for declaring an interface in
C++, based on Stroustrup's notion of a pure interface (see below). Could
that be used as an IDL capable of being "compiled" by, say, a tool to
produce Java stubs?

These are a few items I came across while looking into this matter:

This one's just a gratuitous random jab. ;)

"COM uses the word interface in a sense different from that typically used
in Visual C++ programming. A C++ interface refers to all of the functions
that a class supports and that clients of an object can call to interact
with it. A COM interface refers to a predefined group of related functions
that a COM class implements, but a specific interface does not necessarily
represent all the functions that the class supports. (Java programmers will
find themselves at home with COM interfaces because Java defines interfaces
in just the same way.)" - MSDN "COM Objects and Interfaces"

XPCOM Part 1: An introduction to XPCOM
http://www-128.ibm.com/developerwork.../co-xpcom.html

"abstract class - a class defining an interface only; used as a base class.
Declaring a member function pure virtual makes its class abstract and
prevents creation of objects of the abstract class. Use of abstract classes
is one of the most effective ways of minimizing the impact of changes in a
C++ program and for minimizing compilation time. Example. TC++PL 2.5.4,
12.4.2, D&E 13.2." - BS

"interface - a set of declarations that defines how a part of a program can
be accessed. The public members and the friends of a class defines that
class' interface for other code to use. A class without data members
defines a pure interface. The protected members provide an additional
interface for use by members of derived classes. See also: abstract class."
- BS
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell