Do I need two languages for distributed computing?

[Howard]

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.

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]

news:[email protected]...

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

 

[John Carson]

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.

 

[Steven T. Hatton]

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.

 

[John Carson]

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.

 

[Steven T. Hatton]

news:[email protected]

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.

 

[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.com/2005/04/how-indispensable-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]

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.

 

[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]

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]

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.

 

[REH]

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]

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.

 

[Howard]

I'm not the topic of this newsgroup.



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]

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

 

[Steven T. Hatton]

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/developerworks/webservices/library/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