Frank Pilhofer <fp@fpx.de> wrote in message news:<slrncav734.ij.fp@ariel.fpx.de>...
..
>  This C++ language mapping currently does not map CORBA's types to
> equivalent STL types. IDL's 'string' does not map to 'std::string'
> but to a 'CORBA::String' class (which is little more than a wrapper
> for a char* pointer). IDL's 'sequence' container does not map to
> its equivalent 'std::vector'. The language mapping also defines
> its own equivalents of 'std::auto_ptr'.

Without knowing anything about CORBA, it seems to me that this is
absolutely unavoidable for any package trying to define a
language-independent type system. A Fortan INTEGER can be the same as
some particular C++ signed integer type (though it might be a
different integer type on different platforms) because the realistic
range of options for a type that basic are small, and there's
reasonable chance that they might be exact matches.

However, std::string, std::vector and std::auto_ptr are all three very
complicated data types, which are defined to make heavy use of
C++-specific features. As such, they are extremely unlikely to be
exactly equivalent to any other similar feature of another langauge.
It's virtually impossible to define a language-independent type which
is a std::string, when viewed from C++, unless you're using
"language-independent" to describe a small set of languages, all of
which are closely related to C++. You can make a language-independent
type which can be converted to and from std:: string, or is wrapped by
a class derived from std::string, or implemented as a wrapper for
std::string, but it can't actually be one.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Frank Pilhofer <fp@fpx.de> wrote:
 >  This C++ language mapping currently does not map CORBA's types to
 > equivalent STL types. IDL's 'string' does not map to 'std::string'
 > but to a 'CORBA::String' class (which is little more than a wrapper
 > for a char* pointer). IDL's 'sequence' container does not map to
 > its equivalent 'std::vector'. The language mapping also defines
 > its own equivalents of 'std::auto_ptr'.

Actually, the real problem with the current CORBA mapping for C++ is
that it is extremely error prone:

- Depending on the details of argument passing, you have to follow different
   rules about resource management. Failing to obey these rules results in
   premature release of objects, in resource leaks, etc.
- Some operations are supported (eg. == on _ptr types) but are entirely
   useless and should be flagged so by the compiler.

There is no rationale I can come up with for things like this. Of course,
I expect that people will disagree with the characterization of the
interface being error prone but I had to work with normal programmers so
far and didn't have the luck to work only with the designers of the
binding who actually seem to understand how to use the binding correctly.

The fact that the CORBA binding does not use the types from the standard
C++ library is an annoyance but not the major problem.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Frank's explanation of the relationship between the CORBA C++ mapping
and Standard C++ is excellent, but I thought I'd elaborate a bit on
the history. First, if you really want to know all the gory details,
read this:

<http://www.cuj.com/documents/s=8001/cujcexp1811vinoski/>

First, to say there were a lot of politics involved in forming that
mapping would be a huge understatement. Second, the fact that C++
supports multiple programming paradigms made reaching consensus on a
standard OMG mapping that much more difficult, since we never could
really get people to even agree on a consistent style. Third,
production C++ compilers in the early 1990s left much to be desired,
and as a result the OMG needed to agree on a mapping based on a highly
portable subset of the language at the time, as we wanted a mapping
that would be immediately usable for production-quality CORBA
applications. Fourth, with respect to STL, it had hardly even been
published or vetted at the time the OMG finally published a C++
mapping standard. To try to rely on widely-available
production-quality STL implementations at that time would have been a
huge mistake, as it would have meant that years would have passed
before production-quality portable CORBA C++ applications would have
been possible.

It's now a decade later, and much has changed. If the market wants a
new CORBA C++ mapping, it will happen. Given the difficulties that
those of us who put the existing one together went through to create
it, I sincerely hope that if anyone tries to create a new one, it will
go much more smoothly for them than it did for us.

--steve

Frank Pilhofer <fp@fpx.de> wrote in message news:<slrncav734.ij.fp@ariel.fpx.de>...
> Allan W <allan_w@my-dejanews.com> wrote:
> >
> >  I haven't followed this entire thread. It seems to me that out of all of
> >  the discussion points, there are only a few that seemed relevant:
> >  [...]
> >  I'd like to ask anyone who thinks we need language changes to start
> >  getting more specific. What kind of changes are needed? Why?
> >
>
>  Here's some background for those on C++ newsgroups.
>
>  The issue is that CORBA uses its own type system in its Interface
> Definition Language: basic fixed-width data types (e.g., 32 bit
> integers), narrow and wide strings, as well as structures, sequences,
> arrays etc. Nothing wrong with that for a middleware that claims to
> be language independent. A separate "language mapping" document
> defines how CORBA's types map to a specific programming language's
> native types.
>
>  This C++ language mapping currently does not map CORBA's types to
> equivalent STL types. IDL's 'string' does not map to 'std::string'
> but to a 'CORBA::String' class (which is little more than a wrapper
> for a char* pointer). IDL's 'sequence' container does not map to
> its equivalent 'std::vector'. The language mapping also defines
> its own equivalents of 'std::auto_ptr'.
>
>  The historic rationale for this is, as explained before, that
> the STL was a moving target at the time, with few available
> implementations.
>
>  The result is that CORBA's C++ language mapping is confusing,
> especially to developers familiar with the STL. People have to
> learn a second type system. "Why is a string not an 'std::string'"
> is a FAQ that pops up in every training class.
>
>  Because the language mapping-defined classes are less powerful
> and more cumbersome than their STL equivalents, developers get
> frustrated. Either they live with the types' deficiencies, or
> they have to copy data between the type systems.
>
>  So much for the background.
>
>  So CORBA's C++ language mapping could use a modern, STL-based
> replacement.
>
>  As for the connection to the comp.std.c++ readers here - well,
> obviously this group has a high concentration of C++ expertise,
> which would be needed in authoring an updated document.
>
>  Whether, during a revision of the language mapping, issues with
> the C++ language were discovered -- e.g., issues that prevented
> efficient passing of data, or improvements to allow better mappings
> of IDL data types -- remains to be seen. My personal guess is that
> there would be none.
>
>  All this is hypothetical unless someone commits to spend
> considerable time, effort and investment in revising the language
> mapping, submitting and approving it at the OMG, and working with
> ORB vendors to implement it.
>
>  The initiative must come from the CORBA community. Once set in
> motion, it will be great to have input and comment from the C++
> community here.
>
>  For my 2 cents, there is no haste for the C++ standard to try and
> accomodate anything "to make CORBA better."
>
>  Frank
>
>
> --
> Frank Pilhofer  ...........................................  fp@fpx.de
> My main conclusion after spending ten years of my life working on the
> TeX project is that software is hard. - Donald Knuth
>
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kuyper wrote:
>
> Frank Pilhofer <fp@fpx.de> wrote in message
> news:<slrncav734.ij.fp@ariel.fpx.de>...
> ..
>>  This C++ language mapping currently does not map CORBA's types to
>> equivalent STL types. IDL's 'string' does not map to 'std::string'
>> but to a 'CORBA::String' class (which is little more than a wrapper
>> for a char* pointer). IDL's 'sequence' container does not map to
>> its equivalent 'std::vector'. The language mapping also defines
>> its own equivalents of 'std::auto_ptr'.
>
> Without knowing anything about CORBA,

Not a good way to start an article. ;-)

<snip>
> However, std::string, std::vector and std::auto_ptr are all three very
> complicated data types, which are defined to make heavy use of
> C++-specific features. As such, they are extremely unlikely to be
> exactly equivalent to any other similar feature of another langauge.
<snip>

That shouldn't matter.  Unlike COM, CORBA does not have an ABI.  The
concrete representations of CORBA types are a matter for individual
ORBs to deal with; normally they implement one or more standard
language bindings and the ABIs of some implementation(s) of those
languages.  Every request (call) from one component to another goes
through one or two ORBs, which take care of any necessary conversion
or marshalling.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) wrote in message
news:<8b42afac.0405250626.25b9d05@posting.google.com>...
> Frank Pilhofer <fp@fpx.de> wrote in message
> news:<slrncav734.ij.fp@ariel.fpx.de>...

> ..
> >  This C++ language mapping currently does not map CORBA's types to
> > equivalent STL types. IDL's 'string' does not map to 'std::string'
> > but to a 'CORBA::String' class (which is little more than a wrapper
> > for a char* pointer). IDL's 'sequence' container does not map to
> > its equivalent 'std::vector'. The language mapping also defines
> > its own equivalents of 'std::auto_ptr'.

> Without knowing anything about CORBA, it seems to me that this is
> absolutely unavoidable for any package trying to define a
> language-independent type system. A Fortan INTEGER can be the same as
> some particular C++ signed integer type (though it might be a
> different integer type on different platforms) because the realistic
> range of options for a type that basic are small, and there's
> reasonable chance that they might be exact matches.

> However, std::string, std::vector and std::auto_ptr are all three very
> complicated data types, which are defined to make heavy use of
> C++-specific features.  As such, they are extremely unlikely to be
> exactly equivalent to any other similar feature of another langauge.
> It's virtually impossible to define a language-independent type which
> is a std::string, when viewed from C++, unless you're using
> "language-independent" to describe a small set of languages, all of
> which are closely related to C++.  You can make a language-independent
> type which can be converted to and from std:: string, or is wrapped by
> a class derived from std::string, or implemented as a wrapper for
> std::string, but it can't actually be one.

But that is all a Corba mapping does.  It describes a minimal interface
to the object -- roughly copy, assignent and destruction, and a means of
transporting the object's state over the network.  Corba's equivalent to
an auto_ptr in C++ is only present in the C++ mapping, for example.  And
all Corba requires of the native string type is that it can be copied,
assigned and accessed in some way as a sequence of characters.  The
current mapping uses char*/char const* for this (with radically
different ownership semantics for the two); std::string would do the
trick just as well, if not better, and would certainly be a lot easier
for the user.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W <allan_w@my-dejanews.com> wrote:
>
>  I haven't followed this entire thread. It seems to me that out of all of
>  the discussion points, there are only a few that seemed relevant:
>  [...]
>  I'd like to ask anyone who thinks we need language changes to start
>  getting more specific. What kind of changes are needed? Why?
>

 Here's some background for those on C++ newsgroups.

 The issue is that CORBA uses its own type system in its Interface
Definition Language: basic fixed-width data types (e.g., 32 bit
integers), narrow and wide strings, as well as structures, sequences,
arrays etc. Nothing wrong with that for a middleware that claims to
be language independent. A separate "language mapping" document
defines how CORBA's types map to a specific programming language's
native types.

 This C++ language mapping currently does not map CORBA's types to
equivalent STL types. IDL's 'string' does not map to 'std::string'
but to a 'CORBA::String' class (which is little more than a wrapper
for a char* pointer). IDL's 'sequence' container does not map to
its equivalent 'std::vector'. The language mapping also defines
its own equivalents of 'std::auto_ptr'.

 The historic rationale for this is, as explained before, that
the STL was a moving target at the time, with few available
implementations.

 The result is that CORBA's C++ language mapping is confusing,
especially to developers familiar with the STL. People have to
learn a second type system. "Why is a string not an 'std::string'"
is a FAQ that pops up in every training class.

 Because the language mapping-defined classes are less powerful
and more cumbersome than their STL equivalents, developers get
frustrated. Either they live with the types' deficiencies, or
they have to copy data between the type systems.

 So much for the background.

 So CORBA's C++ language mapping could use a modern, STL-based
replacement.

 As for the connection to the comp.std.c++ readers here - well,
obviously this group has a high concentration of C++ expertise,
which would be needed in authoring an updated document.

 Whether, during a revision of the language mapping, issues with
the C++ language were discovered -- e.g., issues that prevented
efficient passing of data, or improvements to allow better mappings
of IDL data types -- remains to be seen. My personal guess is that
there would be none.

 All this is hypothetical unless someone commits to spend
considerable time, effort and investment in revising the language
mapping, submitting and approving it at the OMG, and working with
ORB vendors to implement it.

 The initiative must come from the CORBA community. Once set in
motion, it will be great to have input and comment from the C++
community here.

 For my 2 cents, there is no haste for the C++ standard to try and
accomodate anything "to make CORBA better."

 Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
My main conclusion after spending ten years of my life working on the
TeX project is that software is hard. - Donald Knuth


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> David Eng <davideng2004@yahoo.com> wrote:
> >  suggestion is only asking C++ committee and CORBA committee can work
> >  together to create a better mapping between C++ and CORBA so that C++
> >  programmers can better use CORBA.

Frank Pilhofer <fp@fpx.de> wrote
>  the current C++ mapping for CORBA predates ISO C++. At the time (early
> nineties), few mature implementations of C++ or the STL were available,
> and of course the OMG did not want to tie itself to a specification that
> was in flux. So they invented their own.

>  Cross-posted and follow-up set to comp.object.corba, which is a more
> appropriate forum, as I don't think that any changes to the C++ language
> would be necessary to come up with an easier-to-use, as-efficient CORBA
> language mapping.

I haven't followed this entire thread. It seems to me that out of all of
the discussion points, there are only a few that seemed relevant:

  * There ought to be more collaboration
  * There IS collaboration
  * C++ doesn't need to collaborate because it's platform-independant
  * We need to change C++ to create a "better mapping"
  * That's because CORBA predates ISO C++
  * Besides, we do NOT need any changes to C++ anyway

In other words, this discussion has been all about controversy. We have
posted philosophical positions that nobody can answer -- least of all in
a technical newsgroup.

In the midst of all this, I've seen at least once, questions like this:
> What features are you missing in particular?
> Is it language or tool support?
If this question was answered, I missed it.

I'd like to ask anyone who thinks we need language changes to start
getting more specific. What kind of changes are needed? Why?

It does no good to say, "something ought to change" without saying
WHAT should change or how it should change. Get specific, and we can
at least argue based on merits, without anybody having to offend
anybody else.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404261345.792bbd8a@posting.google.com>...
> unoriginal_username@yahoo.com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0404240113.2b2f67a@posting.google.com>...
> [snipped]
>
> I never suggested C++ shall support only one platfrom.  I only stated
> C++ is a platform independent programming language and CORBA is a
> platform independent middleware.  So, it is nature for C++ to better
> support CORBA.  No one is against you to write your own middleware.
> The problem is very few people will use your middleware instead of
> CORBA.  I  cannot understand why these people so defensive when I
> suggest that C++ shall collaborate with CORBA for the benefit of C++
> programmers.  It doesn't chang anything about C++.  Unlike C++/CLI,
> you have to add new keywords and use garbage collection.  My
> suggestion is only asking C++ committee and CORBA committee can work
> together to create a better mapping between C++ and CORBA so that C++
> programmers can better use CORBA.  I couldn't believe such suggestion
> will cause me so many troubles for myself.
>
>

I agree with some of your thinking, but I'm not convinced that a
stronger link between C++ and CORBA is the answer.  I've taken
the path of writing alternative middleware that you mentioned.
CORBA has many trapdoors, so it made sense to me to start
something different.  For more information...
http://www.webebenezer.net

I think part of Java's success can be traced to it having
better support than C++ when it comes to middleware.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

As rightly pointed out that though C++ is more fit for application
server programming (while J2EE for web based and .NET for front end),
industry collusion is necessary for further success of C++ in
distributed component based application devleopment and deployment.

The interesting discussion going on, stopped before any conclusion
remarks!!!

Its widespread acceptance that standardization in distributed software
development is need of the software industry. With an excellent
Component framwework (CCM CORBA Component Model again by OMG) build on
top of CORBA provides first class component development, deployment
model for C++ component (.NET ??, J2EE ??).

As pointed in this discussion the efforts for developing C++ should
naturally be aligned to support open standards like CORBA. C++ may not
be needed to be developed to provid distributed application
development support) framework), already provided by CORBA, but more
to support CORBA.

If C++ component development has to become as or more popular then
.NET or J2EE based component development, it has to embrace CORBA.

regards,
Shashank






Francis Glassborow <francis@robinton.demon.co.uk> wrote in message news:<+iFwGWDwHkiAFwPw@robinton.demon.co.uk>...
 > In message <d6652001.0404230305.4f895216@posting.google.com>,
 > kanze@gabi-soft.fr writes
 > >For the moment, the impression I have is that we are getting more
 > >consideration from the people standardizing CLI than we are from those
 > >involved with Corba.  I'm not happy about it -- I definitly like the
 > >total vendor neutrality of Corba.  But that's the way it seems today.
 >
 > Yes, MS as the originators of and main maintainers (through ECMA TC39)
 > of CLI (these days it has an ISO Standard) are quite determined in
 > making C++ a first class .NET language. The rush with the C++/CLI (TG5)
 > is at least partly motivated because they want to positively influence
 > the next revision of CLI so that it gives better support to C++. There
 > stated aim (and knowing many of the people involved, the real aim of
 > their technical people) is to make straight Standard C++ code run out of
 > the box on .NET + make the extended version (C++/CLI) be an equal status
 > authoring language for .NET components. Indeed they want to remove any
 > real incentive for competent C++ programmers to change to C# or other
 > .NET languages.
 >
 > I have many reservations about the form of the work being done (for
 > example, I firmly believe that C++/CLI should be an ISO TR but I do not
 > know of any mechanism allowing fast tracking of and ECMA Standard to an
 > ISO TR) but I have no reservations about the goodness of the intent.
 >
 > It is important for all to distinguish between MS's technical people
 > (who have greatly improved in quality during the last decade -- you do
 > not get people like Herb Sutter and Stan Lippman, to name but two, to
 > work for you unless you are willing to aim high) and MS's
 > marketing/sales/corporate strategists.
 >


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
news:<+iFwGWDwHkiAFwPw@robinton.demon.co.uk>...

    [...]
> It is important for all to distinguish between MS's technical people
> (who have greatly improved in quality during the last decade -- you do
> not get people like Herb Sutter and Stan Lippman, to name but two, to
> work for you unless you are willing to aim high) and MS's
> marketing/sales/corporate strategists.

Actually, Microsoft has always had some top rate technical people.
(Martin O'Riordan comes immediately to mind, but there were others as
well.)  The present difference IS political -- for whatever reasons,
Microsoft has decided to "play the game" (I don't think that they could
have gotten Herb to sign on otherwise); its technical people can now
speak out openly and effectively collaborate, where as before they
couldn't, or at least didn't.

I don't think it was your intent to offend the technical people at
Microsoft, but it could easily have been interpreted that way.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng <davideng2004@yahoo.com> wrote:
>
>                                                            My
>  suggestion is only asking C++ committee and CORBA committee can work
>  together to create a better mapping between C++ and CORBA so that C++
>  programmers can better use CORBA.
>

  David,

 the current C++ mapping for CORBA predates ISO C++. At the time (early
nineties), few mature implementations of C++ or the STL were available,
and of course the OMG did not want to tie itself to a specification that
was in flux. So they invented their own.

 Note that the OMG (Object Management Group) is open to all. Once you
become a member (pricing depends on your company size). As a member,
you can propose your own RFPs (Requests for Proposals).

 In fact, any work you wanted to spend on an improved C++ language
mapping for CORBA would be very welcome. I know firsthand that most
users and some vendors are interested, but it will take some effort
to mount the inertia.

 Cross-posted and follow-up set to comp.object.corba, which is a more
appropriate forum, as I don't think that any changes to the C++ language
would be necessary to come up with an easier-to-use, as-efficient CORBA
language mapping.

        Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
Life would be a very great deal less weird without you. -Douglas Adams


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng wrote:
 > I want to
 > see the better collaboration between C++ and CORBA.

Whatever your reasons are, I read the above statement as you
volunteering to do at least the initial work. I encourage you
and volunteer to review your first draft on a new CORBA/C++
binding. I'm pretty sure that others are interested in the
same issue and that other are willing to help. I expect to see
considerable opposition from the OMG: Essentially, this is
going along the lines "we know our binding sucks but it has to
stay for eternaty anyway due to backward compatibility". This
is a really bad argument, especially for a middleware because
the counterargument is actually pretty simple: just because
there is new binding, there is no need for the old binding to
disappear. The new binding can be use but there shall be no
requirement to use it eg. for new components, if not for an
overall fixup because a good binding will make the maintenace
much easier.

Anyway, *you* want something, *you* invest (that is, if you
don't feel fit to do the work but have the financial resources
to pay for it being done, I'm sure I can arrange is good deal
for you). That is the simple rule. Just whining won't help.
When I used CORBA I worked on this stuff but since I'm
currently not using CORBA anymore I lost some of the interest
(and, more importantly, I lost all support from the company).
As stated above, I and I'm sure others, too, will participate
in this work once it is started.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <d6652001.0404230305.4f895216@posting.google.com>,
kanze@gabi-soft.fr writes
>For the moment, the impression I have is that we are getting more
>consideration from the people standardizing CLI than we are from those
>involved with Corba.  I'm not happy about it -- I definitly like the
>total vendor neutrality of Corba.  But that's the way it seems today.

Yes, MS as the originators of and main maintainers (through ECMA TC39)
of CLI (these days it has an ISO Standard) are quite determined in
making C++ a first class .NET language. The rush with the C++/CLI (TG5)
is at least partly motivated because they want to positively influence
the next revision of CLI so that it gives better support to C++. There
stated aim (and knowing many of the people involved, the real aim of
their technical people) is to make straight Standard C++ code run out of
the box on .NET + make the extended version (C++/CLI) be an equal status
authoring language for .NET components. Indeed they want to remove any
real incentive for competent C++ programmers to change to C# or other
.NET languages.

I have many reservations about the form of the work being done (for
example, I firmly believe that C++/CLI should be an ISO TR but I do not
know of any mechanism allowing fast tracking of and ECMA Standard to an
ISO TR) but I have no reservations about the goodness of the intent.

It is important for all to distinguish between MS's technical people
(who have greatly improved in quality during the last decade -- you do
not get people like Herb Sutter and Stan Lippman, to name but two, to
work for you unless you are willing to aim high) and MS's
marketing/sales/corporate strategists.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng wrote:
>
> I never suggest that C++ should tie to only one platform.  I want to
> see the better collaboration between C++ and CORBA.

What you are demanding are currently missing features which some of them
are under consideration for inclusion into the next version of the C++
standard. Of course, these are language features of general use (like
reflection).

However, the C++ standard will _never_ focus on supporting a particular
platform, implementation or whatever (like CORBA).

> There are several
> reasons.  First, there aren't a lot of platforms exist today.  Other
> than CORBA, here are J2EE and .NET. C++ only have two choices: .NET
> and CORBA.

Please try to inform you a little bit more about what CORBA and .NET do
and offer. You are comparing two different things.

What functionality in particular do you need/demand? I guess it's
communication, isn't it?

> However, I hardly can imagine a mission critical system
> can run on Windows.

Who told you that .NET is bound to windows? AFAIK there is already a
working linux implementation, I've just forgotten the name.

> Besides, .NET treats C++ like a second class
> language.

Considering current technology, this is correct; however, Microsoft
promises to ameliorate this in the next VS version. For all I know, one
of the intentions behind the ECMA standardization is to provide usual
.NET language constructs also in C++.

> Third, the mapping between CORBA and C++ is such a poor
> job.  I cannot find any reasons for such poor mapping.

What features are you missing in particular? Is it language or tool support?

> If there is a
> good mapping, it will be much easy to use CORBA.  That's why I think
> for C++ to stay a mainstream language, C++ needs to collaborate with
> CORBA.

see above!

> CORBA is not perfect, same as C++.

CORBA is far away from being perfect. I wouldn't dare to compare the
'quality' of the CORBA and the C++ standard because it would just lead
to polemics anyway.



Stefan

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
 >
 > In message <408480A7.229F3425@acm.org>, Pete Becker <petebecker@acm.org>
 > writes
 > >David Eng wrote:
 > >>
 > >> 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
 >

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

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404181030.33befde4@posting.google.com>...
 > 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?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<kanze@gabi-soft.fr> wrote in message
news:d6652001.0404220128.2ee06d0f@posting.google.com...
>
> (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.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote in message news:<d6652001.0404230305.4f895216@posting.google.com>...
[snipped]
> C++ needs a good Corba binding.  C++ needs a good database access
> library.  C++ needs a good XML parsing library.  But the first definitly
> does not belong in the C++ standard, and I have my doubts with regards
> to the other two as well.  C++ is a language, not a complete platform.

Yep.  I hope it stays that way.

I have my own middleware, including a rewrite of the entire TCP/IP
protocol (new 64-bit addresses, security, mobility, multicasting,
elegant IPC, etc.)  It's implemented as a ring-3 executable which is
based on a library of 74 C++ classes.

One of the classes is a container template called
Associative_Monarchy<>.

As it turns out, this template can capture the essence of XML, which
is, roughly, a hierarchy of labeled nodes where each node has
"name/value" pairs of strings, and the nodes are labeled by strings:

typedef Associative_Monarchy<String__, Associative_Set<String__,
String__> > XML tree.

I can serialize an XML tree to disk. All of the other 73 classes can
be serialized just as well, but what makes this interesting is that
serialization works over the wire without regard to things like byte
order, word size, floating point incompatibilities, or whether the
source is a PDA or the target is a supercomputer:

Socket p1;  // my equivalent of "socket" definition
XML_Tree foo;
// populate foo
p1 << foo;

// On the other end, the programmer writes:

XML_Tree bar;
Socket p2;
p2 >> bar; // now bar is equivalent to foo

This code could be considered middleware.  Here i am sending a
non-trivial construct from C++ node to C++ node and not having to
worry about security, or whether the node is moving, or whether the
target node is not actually a node, but a set of 100 million nodes,
some of which might be moving.  I have ommitted the mechanisms that
provide a framework for RPC, but certainly you can imagine how that
would be done.

Note that there is no intermediate language.  There is no extra
compiler. There is no preprocessor.  This code is 100% portable. The
whole thing fits in a 1.7MB library, and you can actually use it after
a few hours of thinking.

You do not get univeral object repositories, but the presumption of
such has always been absurd.  As I stated in a related post, the
boundary between language spaces is real, must be respected, and no
amount preprocessing will give the programmer the liberty to create
massively complex data structures in C++ and allow those constructs to
pass unperturbed from source node to target node if the target
language is not also C++.  And sometimes, I do need to pass massive
constructs (eh...data constructs).  For example, one construct is a
network topology representing all nodes on a LAN.  Without going into
details,  if you were to recurse this structure, even 4 levels down,
there are data members of nested classes that are themselves
Associative_List<Digital_Address, List<String__> > ;

In any case, there is no need to think.  Just do:

// on the source node:
topology_graph;
Socket p3;
p3 << topology_graph; // export.  it's done.

// on the target node(s):
topology_graph;
Socket p4;
p4 >> topology_graph; // import.  it's done.

This would not be possible with .NET, DCOM, CORBA, or any of the other
systems I have seen so far.  And for the most part, you're asking too
much if you throw in security, mobility, and scalable multicasting.

Aside from universal object repositories, I cannot understand why
people keep inventing frameworks that require add-on tools. Everything
we need already exists within the confines of the language.

Long live C++.

-Chaud Lapin-


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message
news:<6b74193f.0404231316.4cdc3484@posting.google.com>...

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

--
James Kanze          GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/    http://www.gabi-soft.fr
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

unoriginal_username@yahoo.com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0404240113.2b2f67a@posting.google.com>...
[snipped]

I never suggested C++ shall support only one platfrom.  I only stated
C++ is a platform independent programming language and CORBA is a
platform independent middleware.  So, it is nature for C++ to better
support CORBA.  No one is against you to write your own middleware.
The problem is very few people will use your middleware instead of
CORBA.  I  cannot understand why these people so defensive when I
suggest that C++ shall collaborate with CORBA for the benefit of C++
programmers.  It doesn't chang anything about C++.  Unlike C++/CLI,
you have to add new keywords and use garbage collection.  My
suggestion is only asking C++ committee and CORBA committee can work
together to create a better mapping between C++ and CORBA so that C++
programmers can better use CORBA.  I couldn't believe such suggestion
will cause me so many troubles for myself.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng wrote:
> 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.)

<snip>
> 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!


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng wrote:
>
> 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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote in message news:<d6652001.0404200134.62f83611@posting.google.com>...
 > 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 never suggest that C++ should tie to only one platform.  I want to
see the better collaboration between C++ and CORBA.  There are several
reasons.  First, there aren't a lot of platforms exist today.  Other
than CORBA, here are J2EE and .NET.  C++ only have two choices: .NET
and CORBA.  However, I hardly can imagine a mission critical system
can run on Windows.  Besides, .NET treats C++ like a second class
language.  Second, middleware platforms become more acceptant than
before.  Sure, you can create distributed systems based on sockets.
But I see new projects are likely to use middleware instead of sockets
these days.  Third, the mapping between CORBA and C++ is such a poor
job.  I cannot find any reasons for such poor mapping.  If there is a
good mapping, it will be much easy to use CORBA.  That's why I think
for C++ to stay a mainstream language, C++ needs to collaborate with
CORBA.  CORBA is not perfect, same as C++.  But I do use CORBA and C++
to create mission critical systems.  As a C++ programmer, I want to
see C++ as a useful tool and has a place in software applications.  I
do see .NET is suitable to GUI front end, Java is good at Web-tier,
and C++ is excellent at application servers.  For that to happen, C++
standard has to grow.  I wish next standard will have a thread library
and A database access library (like JDBC).

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <6b74193f.0404181030.33befde4@posting.google.com>, David Eng
<davideng2004@yahoo.com> writes
>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'.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Anthony Williams <anthony_w.geo@yahoo.com> wrote in message
news:<y8or11tg.fsf@yahoo.com>...
 > davideng2004@yahoo.com (David Eng) writes:

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

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.

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

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

--
James Kanze          GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/    http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In message <408480A7.229F3425@acm.org>, Pete Becker <petebecker@acm.org>
writes
>David Eng wrote:
>>
>> 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

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message
news:<6b74193f.0404211726.13770571@posting.google.com>...
> kanze@gabi-soft.fr wrote in message
> news:<d6652001.0404200134.62f83611@posting.google.com>...

>  > 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 never suggest that C++ should tie to only one platform.  I want to
> see the better collaboration between C++ and CORBA.

Fine.  I'm all in favor of collaboration.  On all fronts.

Collaboaration is, of course, a two-way street.  With regards to Corba,
my impression is that the resistance to tighter collaboration is mainly
on the Corba side, although I could easily be wrong.

>  There are several reasons.  First, there aren't a lot of platforms
> exist today.  Other than CORBA, here are J2EE and .NET.

We must mean something different by middleware, because I've worked on
something like a dozen different distributed projects over the last 10
years, only one used Corba, and none used J2EE or .NET.  (For a long
time, I was mainly working on telephone operations systems.  Where BER
encoded ASN.1 is almost a standard.)

> C++ only have two choices: .NET and CORBA.

If J2EE is a middleware platform, then C++ can also implement it.

> However, I hardly can imagine a mission critical system can run on
> Windows.

Some do.  It depends on size.  (And the risks you are willing to take,
but modern Windows -- 2000 up -- represents less risk than, say, Linux.)

Of course, I can't imagine anything really critical going over the
Internet, in any shape, form or fashion.  But maybe we have different
ideas about what is critical.

>  Besides, .NET treats C++ like a second class language.

Less so than J2EE:-).

For the moment, the impression I have is that we are getting more
consideration from the people standardizing CLI than we are from those
involved with Corba.  I'm not happy about it -- I definitly like the
total vendor neutrality of Corba.  But that's the way it seems today.

> Second, middleware platforms become more acceptant than before.  Sure,
> you can create distributed systems based on sockets.  But I see new
> projects are likely to use middleware instead of sockets these days.

Middleware, or at least what I understand by the word, isn't a platform.
A platform may be part of it, although it often isn't.  I think that
using something like MQ Series, BEA Tuxedo or Tibco is pretty far from
programming at the socket level, and judging from the job offers I see,
those are the most widely used middleware products.  (Tibco is at least
partially based on SNMP, which in turn uses a subset of BER encoded
ASN.1.  Not Corba, not J2EE and not .NET.)

If there is a future trend, it would seem to be going in the direction
of XML, not Corba, J2EE or .NET.  Maybe what you really want is an XML
library for C++.

> Third, the mapping between CORBA and C++ is such a poor job.

Agreed.

>  I cannot find any reasons for such poor mapping.

History.

> If there is a good mapping, it will be much easy to use CORBA.

I think that you're not alone in believing this.

> That's why I think for C++ to stay a mainstream language, C++ needs to
> collaborate with CORBA.

And we're back to where we started.

A C++ binding for Corba has no place in the C++ standard.  It's up to
the Corba people.  If they are willing, I doubt that there would be a
lack of people working on the C++ standard who are ready to help.

As I said above, collaboration is a two-way street.

> CORBA is not perfect, same as C++.  But I do use CORBA and C++ to
> create mission critical systems.  As a C++ programmer, I want to see
> C++ as a useful tool and has a place in software applications.

It is used in a lot of server side work, I can vouch for that.  (It's
also rapidly becoming the source language for the most wide-spread
client side software as well -- since both Mozilla and Internet Explorer
are written in C++:-).)

> I do see .NET is suitable to GUI front end, Java is good at Web-tier,
> and C++ is excellent at application servers.

That's about what I see currently happening.  Almost -- Internet
Explorer is often a good alternative to .NET as the GUI front end:-).

> For that to happen, C++ standard has to grow.  I wish next standard
> will have a thread library and A database access library (like JDBC).

I totally agree with regards to the thread library, for a number of
reasons.  For the rest...

C++ needs a good Corba binding.  C++ needs a good database access
library.  C++ needs a good XML parsing library.  But the first definitly
does not belong in the C++ standard, and I have my doubts with regards
to the other two as well.  C++ is a language, not a complete platform.

Which I think is as it should be.

--
James Kanze          GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/    http://www.gabi-soft.fr
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

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.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Eng wrote:
 > 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?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404181030.33befde4@posting.google.com>...
> 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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) writes:

> 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
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

davideng2004@yahoo.com (David Eng) wrote in message
news:<6b74193f.0404181030.33befde4@posting.google.com>...

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

--
James Kanze          GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/    http://www.gabi-soft.fr
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]