C++ and Middleware

[David Eng]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform. Sadly,
they chose the wrong middleware platform. Microsoft has notorious
application software. They never produce a true enterprise level
software. Most of their software products target small companies.
However, the strength of C++ is it can build mission critical systems
which are widely used in such industries like telecom, financial,
transport, medical, and military industries. These systems never can
run on Windows operating system. So, why the committee has to embrace
Microsoft which never treats C++ as a first class language?

Then, there is CORBA middleware platform. You can find CORBA in these
mission critical systems in these industries. CORBA is built in the
mind of C++ and indeed treat C++ the first class language. In some
way, I would think because of CORBA, C++ can still keep up with
competition from other programming languages. It is perfect marriage
between a programming language C++ and middleware platform CORBA. My
question is why C++ standard committee ignores CORBA and embraces
Microsoft? Is it time for our C++ community think hard for where C++
should go? The popularity and growth of C++ is declining. If C++
community doesn't accept the trend of distributed computing and
integrates C++ with a middleware platform, C++ will degrade into a
third class language suitable only for a limited application.

 

[Hyman Rosen]

The committee now focus on C++ extensions for ISO CLI

Are you sure it's the C++ committe that's doing this?
Are you aware that Herb Sutter works for Microsoft?
Are you aware that whining that other people are not
doing free work for you doesn't show you in the best
light?

 

[Anthony Williams]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

[snipped anti-Microsoft rant]

So, why the committee has to embrace
Microsoft which never treats C++ as a first class language?

Microsoft has filed C++/CLI with ECMA for standardization, with the intent
that it then become an ISO standard. The C++ committee has decided to
participate in this effort in order to try and ensure that the standardized
C++/CLI is still within the spirit of C++, and has no gratuitous
incompatibilities.

Then, there is CORBA middleware platform. You can find CORBA in these
mission critical systems in these industries. CORBA is built in the
mind of C++ and indeed treat C++ the first class language.

James Coplien told me that he thought there was no good use for CORBA, because
of problems inherent in its design. Though I haven't had a great deal of
experience using CORBA, from what I've seen, I tend to agree.

Anthony

 

[kanze]

(e-mail address removed) (David Eng) wrote in message

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing.

I don't see where anything has actually changed.

The committee now focus on C++ extensions for ISO CLI, the Microsoft
middleware platform. Sadly, they chose the wrong middleware platform.
Microsoft has notorious application software. They never produce a
true enterprise level software. Most of their software products
target small companies. However, the strength of C++ is it can build
mission critical systems which are widely used in such industries like
telecom, financial, transport, medical, and military industries.
These systems never can run on Windows operating system. So, why the
committee has to embrace Microsoft which never treats C++ as a first
class language?

The committee has not "embraced Microsoft". Or any other technology,
for that matter. For as long as I've know it, the committee has shown a
willingness to collaborate with other groups when an interface to the
language has been involved. In this case, there was a demand on both
sides; the committee (or at least some members of it) wanted to ensure
that nothing in CLI would conflict with C++, and the group specifying
CLI (largely dominated by Microsoft) expressed an interest in avoiding
conflicts as well.

Then, there is CORBA middleware platform. You can find CORBA in these
mission critical systems in these industries. CORBA is built in the
mind of C++ and indeed treat C++ the first class language.

Because Corba doesn't specify an execution platform, it runs less risk
of conflicts. Still, more collaboration on this front would be
welcome. From what I understand, however, the resistance is more on the
Corba side than from the C++ committee -- there are C++ committee
members more than willing to collaborate with the Corba group, in order
to find solutions. (Note that unlike CLI, Corba and C++ both have
backwards compatibility problems, which constrain the solutions
somewhat.)

In some way, I would think because of CORBA, C++ can still keep up
with competition from other programming languages.

Strangely enough, very few of the C++ applications I've worked on have
used Corba (and none to date have used CLI). Middleware oriented
platforms definitely have a role to play, but they aren't the entire
world. And C++ integrates pretty well with most of them.

It is perfect marriage between a programming language C++ and
middleware platform CORBA. My question is why C++ standard committee
ignores CORBA and embraces Microsoft?

Because Microsoft asked for comment, and Corba didn't? (It's not that
simple, but when some committee members expressed worries about
compatibility, the CLI group was quick to invite them to participate.)

Is it time for our C++ community think hard for where C++ should go?

I think that the answer to that is: everywhere. C++ remains a
general purpose programming language, not linked to any one technology.
You can use it with CLI, or Corba or any other middleware platform. Or
you can use it in contexts where there is no middleware platform.

The popularity and growth of C++ is declining.

According to what measure. C++ is certainly growing slower than it was
10 years ago -- when you represent over half of all programming, it is
difficult to multiply your user base by 10. C++ suffered a slight slump
after the appearance of Java, but that seems past now -- at least I'm
seeing more job offers and more no projects starting in C++ than in any
other language.

If C++ community doesn't accept the trend of distributed computing
and integrates C++ with a middleware platform, C++ will degrade into a
third class language suitable only for a limited application.

If the C++ community ties itself to only one middleware platform, and
cannot be used without that platform, it will become a niche language,
only suitable for a limited set of applications. That's not where I
want C++ to go.

(I like Corba, and it would certainly be the first solution I'd consider
for communicating processes, but IMHO, that's independant of C++. And
it isn't a miracle solution either -- we're using an in house solution
here because Corba doesn't work, at least not well, in this one
particular case.)

 

[Michiel Salters]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

No they don't. You're confusing ECMA TC39/TG5 with ISO SC22/WG21.
There is a liason between TG5 and WG21, which basically means that
TG5 informs WG21 about its activities and vice versa. In addition,
selected extensions to C++/CLI could be generalized for all C++
implementations - see e.g. N1600 - but this would not force the
CLI on C++ implementaions.

My question is why C++ standard committee ignores CORBA and
embraces Microsoft?

Where do you get the idea that CORBA is being ignored? I doubt there
are many WG21 members whoare unaware of CORBA. Of course, there are
some fundamental differences. Microsoft is proposing CLI as another
ISO standard, and currently works with ECMA. CORBA is not an ISO nor
an ECMA standard, but an ad-hoc standard. That makes it legally
harder to establish a liason.

Regards,
Michiel Salters

 

[Francis Glassborow]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing.

How on Earth do you arrive at that. Of course the C++ Standards Committees
are very well aware of the importance of middleware and distributed
computing but that has nothing to do with the core of C++.

OTOH the work you have stumbled on is not being done by the C++ Standards
Committees but by ECMA and that work presents serious problems to those
responsible for maintaining a platform neutral general purpose language.

This is not the place to go into details other than to point out that in
order to deal with the problems that are raised SC22/WG21 and TC39/TG5 have
had to pursue a degree of creativity in order to achieve a degree of mutual
co-operation. It is worth noting that those responsible for
C++ in Microsoft fought hard to ensure that ECMA rules with regard to
document confidentiality would be loosened enough to allow co-operation.

The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

Rubbish. Please learn the facts before interpreting them.

Sadly,
they chose the wrong middleware platform.

Had WG21 made the choice ... but they did not.

Microsoft has notorious
application software.

Please consider focusing on technical issues rather than emotive
language.

They never produce a true enterprise level
software.

So? What has this got to do with ECMA producing a C++/CLI standard.

Most of their software products target small companies.
However, the strength of C++ is it can build mission critical systems
which are widely used in such industries like telecom, financial,
transport, medical, and military industries. These systems never can
run on Windows operating system. So, why the committee has to embrace
Microsoft which never treats C++ as a first class language?

The strength of C++ is that it can be used for many different purposes
which, happily, includes writing applications for Windows platforms.
Fortunately the C++ Standards Committees take a broader view even if
that irritates those who think they should be spending time considering
some form of middleware 'platform'.

 

[Pete Becker]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

The ISO C++ standards committee is working on C++. There is no ISO CLI.
There's an ECMA committee working on CLI.

 

[Ben Hutchings]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

C++/CLI is largely a Microsoft initiative and is being standardised by
a committee within ECMA (TC39/TG5), not the ISO and ANSI committees
that produce C++ standards (JTC1/SC22/WG21 and INCITS J16
respectively). Some members of the latter committees have been able
to get involved in TG5 but not in an official capacity; furthermore as
guests (not members) of ECMA they are not able to vote on the
standard.

Sadly, they chose the wrong middleware platform. Microsoft has
notorious application software.

Whether that's true or not, how is it relevant to .NET and the CLI?

They never produce a true enterprise level software. Most of their
software products target small companies. However, the strength of
C++ is it can build mission critical systems which are widely used
in such industries like telecom, financial, transport, medical, and
military industries. These systems never can run on Windows
operating system.

Yet many such systems *do* run Windows. While I am no fan of Windows
and I don't think it is very reliable, what you're saying comes across
as dogmatic Microsoft-bashing. How about a rational technical
argument?

So, why the committee has to embrace Microsoft which never treats
C++ as a first class language?

It hasn't.

(I can't comment on the merits of CORBA as I know little about it.)

The popularity and growth of C++ is declining. If C++ community
doesn't accept the trend of distributed computing and integrates C++
with a middleware platform, C++ will degrade into a third class
language suitable only for a limited application.

And there was me thinking C++ was a great systems programming language
that could work with any middleware or indeed be used to build it.
Apparently it has to be restricted to just one such platform. How
silly of me!

 

[kanze]

(e-mail address removed) (David Eng) writes:

[snipped anti-Microsoft rant]

So, why the committee has to embrace Microsoft which never treats
C++ as a first class language?

Microsoft has filed C++/CLI with ECMA for standardization, with the
intent that it then become an ISO standard. The C++ committee has
decided to participate in this effort in order to try and ensure that
the standardized C++/CLI is still within the spirit of C++, and has no
gratuitous incompatibilities.

I don't think that "participate" is the right word. The C++ committee
has a liaison with the CLI group. As they do with some other groups.
There's also some overlap of membership in the two committees.

James Coplien told me that he thought there was no good use for CORBA,
because of problems inherent in its design. Though I haven't had a
great deal of experience using CORBA, from what I've seen, I tend to
agree.

If we throw out everything which has some "problems inherent in its
design", there's not much left. No C++, for example. Or any other
programming language I've used, for that matter. No Unix and no
Windows. No SQL or data bases. Practically none of the Internet
protocols.

Corba's far from perfect, but seriously, what are the proposed,
*non-proprietory* alternatives? (Note that while CLI and Corba might
both come under the heading of Middleware, they are quite different
things, address different problems, and in most cases at least, don't
compete.)

 

[Francis Glassborow]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

The ISO C++ standards committee is working on C++. There is no ISO CLI.
There's an ECMA committee working on CLI.[/QUOTE]

Try ISO/IEC 23271 (CLI) and 23272 (CLI TR) -- fast tracked in April 2003

 

[David Eng]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform. Sadly,
they chose the wrong middleware platform. Microsoft has notorious
application software. They never produce a true enterprise level
software. Most of their software products target small companies.
However, the strength of C++ is it can build mission critical systems
which are widely used in such industries like telecom, financial,
transport, medical, and military industries. These systems never can
run on Windows operating system. So, why the committee has to embrace
Microsoft which never treats C++ as a first class language?

Then, there is CORBA middleware platform. You can find CORBA in these
mission critical systems in these industries. CORBA is built in the
mind of C++ and indeed treat C++ the first class language. In some
way, I would think because of CORBA, C++ can still keep up with
competition from other programming languages. It is perfect marriage
between a programming language C++ and middleware platform CORBA. My
question is why C++ standard committee ignores CORBA and embraces
Microsoft? Is it time for our C++ community think hard for where C++
should go? The popularity and growth of C++ is declining. If C++
community doesn't accept the trend of distributed computing and
integrates C++ with a middleware platform, C++ will degrade into a
third class language suitable only for a limited application.

Sorry guys. I messed up ECMA TC39/TG5 with ISO SC22/WG21. But my
point is C++ has a limited run-time system, so, it is better off for
C++ to associate with an ORB that provides run-time environment to
write distributed applications. Unlike other middleware platforms,
CORBA is platform and language independent. C++ is platform
independent. It is nature for C++ and CORBA to collaborate.

Or, C++ committee may consider next C++ standard will support
distributed applications in which I mean the compiler directly
supports distributed system. I know Bjarne Stroustrup is working on a
reflection library which will make writing distributed application
easier. Does C++ committee has such consideration for C++ to support
distributed system?

 

[Pete Becker]

Finally, the C++ standard committee realizes the importance of
middleware and distributed computing. The committee now focus on C++
extensions for ISO CLI, the Microsoft middleware platform.

The ISO C++ standards committee is working on C++. There is no ISO CLI.
There's an ECMA committee working on CLI.

Try ISO/IEC 23271 (CLI) and 23272 (CLI TR) -- fast tracked in April 2003
[/QUOTE]

Yup. Looks like I've added to the confusion in this thread instead of
subtracting from it.

 

[Eugene Alterman]

(Note that while CLI and Corba might
both come under the heading of Middleware, they are quite different
things, address different problems, and in most cases at least, don't
compete.)

Why would you say that?
They both address the problem of application interoperability by providing
an object oriented, multilanguage, network transparent environments.

 

[kanze]

(e-mail address removed) (David Eng) wrote in message

[...]

Sorry guys. I messed up ECMA TC39/TG5 with ISO SC22/WG21. But my
point is C++ has a limited run-time system, so, it is better off for
C++ to associate with an ORB that provides run-time environment to
write distributed applications. Unlike other middleware platforms,
CORBA is platform and language independent. C++ is platform
independent. It is nature for C++ and CORBA to collaborate.

Collaborate, fine. For the rest, it is precisely because C++ is
platform independant that it doesn't embrace Corba as a prefered
solution, and it is precisely because Corba is language independant that
it doesn't embrace C++ as a prefered solution.

I rather like it this way. Each does what it does best. And I'm free
to use C++ without Corba, or Corba without C++, as well as using both
together.

Or, C++ committee may consider next C++ standard will support
distributed applications in which I mean the compiler directly
supports distributed system.

I hope not. Traditionally, C++ has not supported any particular type of
system directly. The role of a language -- at least a general purpose
language like C++ -- is to provide an essential tool which can be used
on a wide variety of types of systems.

I know Bjarne Stroustrup is working on a reflection library which will
make writing distributed application easier.

I will certainly make writing distributed systems easier. This may even
be the most important use. But it isn't the only one. (The only time I
personally used reflection in Java was for a unit test platform --
nothing to do with distributed systems. But of course, the
implementation of RMI probably uses reflection as well.

Does C++ committee has such consideration for C++ to support
distributed system?

I would expect that it is considered as a possible application. Like
many other things.