Do I need two languages for distributed computing?

S

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

Victor Bazarov

Steven said:
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
 
S

Steven T. Hatton

Victor said:
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.
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++."
 
K

Karl Heinz Buchegger

Steven T. Hatton said:
[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.
 
J

John Carson

Steven T. Hatton said:
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).
 
V

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

John Carson

vindhya said:
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.
 
S

Steven T. Hatton

Karl said:
Steven T. Hatton said:
[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.
 
S

Steven T. Hatton

John said:
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.
 
J

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

Steven T. Hatton

John said:
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.
 
H

Howard

Steven T. Hatton said:
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
 
S

Steven T. Hatton

Howard said:
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).
 
A

Artie Gold

Steven said:
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
 
H

Howard

Steven T. Hatton said:
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
 
S

Steven T. Hatton

Artie said:
Well, whether you realize it or not, you have.

In your opinion, which you would do well to keep to yourself.
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.
 
S

Steven T. Hatton

Howard said:
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.
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
 
V

Victor Bazarov

Steven said:
Artie said:
Steven said:
[..]
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.
 
V

Victor Bazarov

Steven said:
[..] 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.
 
S

Steven T. Hatton

Victor said:
Steven said:
[..] 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top