The future of C++
David Eng
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.
CORBA's strength is built on programming language independence. There
is need for Java or C# to talk to C++. If C++ doesn't have a future,
why applications need to talk to C++? If no applications talk to C++,
then why people need to use CORBA since Java has EJB middleware and C#
has .NET? The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA. They must understand that the future of C++ and CORBA
is dependent on each other. If they realize this relationship, I
believe the future of C++ and CORBA is bright. The reason is simple:
together, C++ and CORBA can build mission critical applications which
Java and C# cannot even think about.
[ 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...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Bryan Bullard
"David Eng" <davide...@yahoo.com> wrote in message
news:6b74193f.04041...@posting.google.com...
One of the primary strengths of C++ is that it is general purpose and
doesn't try to conform to all the latest bells and whistles (like Java
does). In 10 or 15 years when all the technologies that are built into Java
have become obsolete what good will Java be?
..
Edward Diener
David Eng wrote:
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if
> its > proprietery .NET and C# technology, how long can we except C++
> to hold > on against these might competitors?
> > Has C++ become a dying language?
> > What is the future of C++?
>
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++).
Hardly.
C++ thrives very well, thank you, for a wide variety of platforms,
compilers, and standard libraries despite Sun's, Microsoft's, and Borland's
attempts to treat it as a second-rate language in order to promote their own
favored computer programming languages. It can adapt itself to CORBA, DCOM,
and most whatever other middleware comes down the road. Getting caught up in
the politics of software development hype is, thankfully, not what C++ is
all about.
Le Chaud Lapin
davide...@yahoo.com (David Eng) wrote in message news:<6b74193f.04041...@posting.google.com>...
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> CORBA's strength is built on programming language independence. [snip]
Yuck. Please don't take this perosonally, but I find distrbuted
polylingual polymorphic objects disgusting. After years of duking it
out with Microsoft COM abominations, I am convinced that some
boundaries are not meant to be blurred, and making an
all-encompassing, super model for "distributed objects" is gross if it
comes with box of duct tape and chicken wire.
Every language has a distinct type space, and no matter what trickery
is employed, if programs written in two different languages must
communicate with each other, at some point, the boundary between the
type spaces must be dealt with. Any attempt to smooth over the
interface without regard for the fact that the type spaces *are*
distinct results in cumbersome tools like data marshallers and weird
compilers that require perturbation of the host languages.
If multilingual interaction is required, it would be much better to
find a way to get data from node A to node B, entirely within the
framework of one prescribed language [why not C++?], then provide
specific mechanisms to translate from the prescribed language to a
target language as necessary, and if possible. After all, the
boundary will have to be crossed by someone at some point anyway, so
why make everyone suffer when it is the polyglot who is asking for it?
You might say, "Well, there is an enormous benefit of having
language-independent objects accessible from any node by any
language." I would agree if it were actually possible to have such a
thing.
No unified typespace can scale to the mode of aggregation that complex
(not complicated) systems demand without the need to think carefully
about what happens when aggregate objects need to cross from the
unified type space to a specific type space. I doubt that it is
possible to go from
Associative_Polyarchy<String_, Associative_List<unsigned int,
Polyarchy<String_> > >
on a node running C++ to the same thing on a node running C# while
keeping the data structure in one piece. The problem is that I use my
source language to construct things, and if the elements of
construction do not exist in the target language, then I must somehow
manually syntesize the construct anyway. If it is stipulated that I
must choose from a particular set of primitives, and use them in a
certain way in my source language, then guess what? I am no longer
speaking my native language. This fact can be seen by reading between
the lines on Microsoft's MSDN site. They openly profess .NET's
language independence while surreptitiously attempting to displace C++
in favor of C#, which, among other things will allow to them to
provide platforms and tools on Unix & Company undermining their market
dominance.
-Chaud Lapin-
By the way, French is language-independent. All you have to do is
learn how to get from French to English, French to German, French to
Swahili...
Asfand Yar Qazi
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if its
> > proprietery .NET and C# technology, how long can we except C++ to hold
> > on against these might competitors?
> > Has C++ become a dying language?
> > What is the future of C++?
>
I consider C++ to be an object-oriented cross-platform assembler, so it
is the only way to go for writing high-performance multi-platform game
(and other real-time) code.
---
Steven T. Hatton
Bryan Bullard wrote:
> One of the primary strengths of C++ is that it is general purpose and
> doesn't try to conform to all the latest bells and whistles (like Java
> does). In 10 or 15 years when all the technologies that are built into
> Java have become obsolete what good will Java be?
Which technologies are those? There is the core Java language as specified
in _The Java Language Specification_, by, James Gosling, Bill Joy, Guy
Steele, Gilad Bracha, and then there is a huge collection of fairly well
integrated supporting libraries. Note: that's the same Guy Steele who
coauthored the highly regarded _C: A Reference Manual, Fifth Edition_.
CORBA should not be part of the C++ language anymore than Enterprise
JavaBeans, or RMI are part of the Java Language Specification.
Nonetheless, CORBA represents the direct C++ counterpart of come of Java's
most successful technologies.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
John Nagle
enough introspection to allow generation of marshalling code
via suitable templates. Currently, you have to define
interfaces for CORBA, OpenRPC, or DCOM in an external
language which is then processed into C source by an
interface generator.
This direction might give the template fanatics something
useful to do.
Actually, RMI is part of the "core Java" specification.
John Nagle
Animats
Steven T. Hatton wrote:
> CORBA should not be part of the C++ language anymore than Enterprise
> JavaBeans, or RMI are part of the Java Language Specification.
> Nonetheless, CORBA represents the direct C++ counterpart of come of Java's
> most successful technologies.
>
>
>
---
Thomas Richter
Hi,
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++). Applications are built today are distributed applications
> instead of stand alone applications. For C++ to success in this
> environment, it has to have a middleware platform. C++ has a
> disadvantage comparing to Java and C# which both have a middleware
> platform. However, CORBA can become the middleware platform for C++.
Oh well. For that to happen, the OMG should possibly do its homework
first. I'm using CORBA with its C++ bindings here, and I'd to read the
"standard literature" for that task, the Henning/Vinoski book, and the
C++ CORBA bindings are *still* giving me headaches. Does it really
have to be *that* complicated? I wouldn't have problems with two
mappings, or a layered design with a simple, general purpose
top-layer, and a specialized layer that provides all the fancy
extensions I rarely need. Currently, CORBA and its C++ mapping is both
too special and too general at once.
I also feel that CORBA does its job possibly only half the way it could.
For example, it nicely runs new threads for me serving my objects, but
at the same time it doesn't provide necessary services for keeping
object states consistent amongst the threads - there are no "mutex"
specifications in CORBA.
On the plus side, CORBA provides lots of language bindings, so I can
really interact with Java, Python, Perl,..., but the integration into
the C++ language really deserves a cleanup.
> The answer is clear, the C++ standard committee and OMG
> must work together to create a better mapping and association between
> C++ and CORBA.
Bingo.
So long,
Thomas
David Eng
Thomas Richter <th...@cleopatra.math.tu-berlin.de> wrote in message news:<c607kn$q19$2...@mamenchi.zrz.TU-Berlin.DE>...
> I also feel that CORBA does its job possibly only half the way it could.
> For example, it nicely runs new threads for me serving my objects, but
> at the same time it doesn't provide necessary services for keeping
> object states consistent amongst the threads - there are no "mutex"
> specifications in CORBA.
I blame this for C++. The thread mode should be built into C++
instead of CORBA. I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library. The another area bothers me is database access layer. All
these database vendors promote JDBC because there is no a standard C++
access library. If these vendors stop to support their proprietary
C++ API, who will use C++ in a distributed environment? I never head
C++ committee even has an initiative to standardize a database access
layer library. No matter how great C++ is, without a standard thread
and data access libraries, C++ will have a hard time to survive in a
distributed computing. Just to imagine how C++ can survive in a
system computing without an I/O library! If the committee thinks
proprietary libraries can do the job, I am sure that C++ will not be a
mainstream programming language; it will downgrade to a third class
language doing some limited applications.
John Nagle
a matter for C++ standardization. We already have POSIX threads,
which are available across multiple platforms.
But if the compiler is going to help with locking, language
support is needed.
Some things only the compiler can do:
- generate direct locking instructions inline when
appropriate.
- lock at every entry to an object from the outside
- optimize out unneeded locks
- Calls to a public function from inside an
object may not need a relock.
- access functions that retrieve a single
value using an atomic machine operation
may not need locking. (Yes, you have
to check for the case where a value is
updated twice within a member function, offering
the possibility of a transient value.)
- Functions that don't access member data or functions
don't need locking.
So there's a real payoff to making the compiler knowledgeable about
locking.
John Nagle
Animats
David Eng wrote:
> Thomas Richter <th...@cleopatra.math.tu-berlin.de> wrote in message news:<c607kn$q19$2...@mamenchi.zrz.TU-Berlin.DE>...
> > I also feel that CORBA does its job possibly only half the way it could.
> > For example, it nicely runs new threads for me serving my objects, but
> > at the same time it doesn't provide necessary services for keeping
> > object states consistent amongst the threads - there are no "mutex"
> > specifications in CORBA.
>
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library. The another area bothers me is database access layer. All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library. No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
---
Jim Melton
"Thomas Richter" <th...@cleopatra.math.tu-berlin.de> wrote in message
news:c607kn$q19$2...@mamenchi.zrz.TU-Berlin.DE...
>
>
> > As I posted in CORBA group, I believe the future of C++ depends on
> > CORBA (the same is true that the future of CORBA depends on the future
> > of C++). Applications are built today are distributed applications
> > instead of stand alone applications. For C++ to success in this
> > environment, it has to have a middleware platform. C++ has a
> > disadvantage comparing to Java and C# which both have a middleware
> > platform. However, CORBA can become the middleware platform for C++.
>
> Oh well. For that to happen, the OMG should possibly do its homework
> first. I'm using CORBA with its C++ bindings here, and I'd to read the
> "standard literature" for that task, the Henning/Vinoski book, and the
> C++ CORBA bindings are *still* giving me headaches. Does it really
> have to be *that* complicated? I wouldn't have problems with two
> mappings, or a layered design with a simple, general purpose
> top-layer, and a specialized layer that provides all the fancy
> extensions I rarely need. Currently, CORBA and its C++ mapping is both
> too special and too general at once.
Writing distributed programs is hard. If you have any doubt, just Google
this group for discussions on multi-threading. Distributed programming is
multi-threading with unknown latency and unreliable communication. It takes
more to write a distributed program than to just slap some middleware
between two programs you wrote. The CORBA spec represents 10 years of
experience with what is required to do distributed programming. The stuff
you don't think you need... you'll need it.
The CORBA C++ binding suffers from much of the same baggage as the C++
language: backward compatibility. At the time the binding was specified,
there was no STL, consequently no std::string (one of the biggest disasters
of the binding). To change the binding now would break *all* existing
programs, so it will not be done lightly.
At the risk of straying even farther off-topic for this group, I'll point
out that Michi Henning has gone on to write a middleware designed to work
much more intuitively with C++, and has taken quite a bit of heat from,
among others, Steve Vinoski.
> I also feel that CORBA does its job possibly only half the way it could.
> For example, it nicely runs new threads for me serving my objects, but
> at the same time it doesn't provide necessary services for keeping
> object states consistent amongst the threads - there are no "mutex"
> specifications in CORBA.
Again, this is off-topic for this group, and you might want to take these
comments to the CORBA group, but "mutex" has no tractable meaning in
distributed programming. CORBA specifies the interface by which clients may
access distributed services, and it defines language bindings by which
programmers may implement (or access) those services.
> On the plus side, CORBA provides lots of language bindings, so I can
> really interact with Java, Python, Perl,..., but the integration into
> the C++ language really deserves a cleanup.
Absolutely.
> > The answer is clear, the C++ standard committee and OMG
> > must work together to create a better mapping and association between
> > C++ and CORBA.
>
> Bingo.
I don't get the question. From a CORBA programmer's perspective, a better
C++ binding would be desirable. But from a C++ programmer's perspective, why
should I care? Why do you assume that CORBA will triumph over SOAP or EJB or
the next greatest fad in distributed programming? C++ will be integrated
into every middleware for which a vendor can make a business case. C++ will
continue to be required for mission-critical applications where one can't
afford to have the JVM crash, or can't afford the non-determinism of garbage
collection, or requires access to operating system facilities not available
in a virtual machine, or ...
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&S
(303) 971-3846
David Abrahams
davide...@yahoo.com (David Eng) writes:
> We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
Please. Did you submit a proposal for a standard threads library?
Did anyone? [hint: the answer is no]
The "C++ committee thinks" (as though we are all of one mind, but I'll
play along) that a threading library is important. I don't think we
have any threading experts with the time to bring forward a proposal
on it. If you think you're qualified, please do it yourself.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
John Nagle
> davide...@yahoo.com (David Eng) writes:
>
>
>>We are moving to grid computing, yet C++
>>committee doesn't think it is important to standardize a thread
>>library.
Actually, "grid computing", even if it happens, is independent
of threads. Threads are a local issue. Things like CORBA
need marshalling support, not threading. An introspection
mechanism good enough to do that would be helpful. The
ability to iterate through the data members of an object at
template instantiation time would be helpful.
A good metric for template/instrospection interaction is
whether you can write a template that generates efficient
marshalling code for an object. If one could write different templates
that generated marshalling for a few common protocols (OpenRPC,
Java RMI, Microsoft DCOM, SOAP), that would be a big win.
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
>
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
I'd put locking in the language, but leave threading to POSIX.
I've discussed an approach to object-level safe locking before.
If someone wants to solicit me to write a formal proposal,
I'd be willing to do it.
John Nagle
Animats
---
David Eng
> If you think of threads in terms of a library, that's not
> a matter for C++ standardization. We already have POSIX threads,
> which are available across multiple platforms.
>
> But if the compiler is going to help with locking, language
> support is needed.
>
> Some things only the compiler can do:
>
> - generate direct locking instructions inline when
> appropriate.
> - lock at every entry to an object from the outside
> - optimize out unneeded locks
> - Calls to a public function from inside an
> object may not need a relock.
> - access functions that retrieve a single
> value using an atomic machine operation
> may not need locking. (Yes, you have
> to check for the case where a value is
> updated twice within a member function, offering
> the possibility of a transient value.)
> - Functions that don't access member data or functions
> don't need locking.
>
> So there's a real payoff to making the compiler knowledgeable about
> locking.
>
> John Nagle
> Animats
That what I mean. Compilers shall handle the synchronous primitives.
Puting a library into C++ standard have two purposes. First, if
compilers can generate better code, the compilers shall do it.
Second, the compilers shall enforce error checking. If it is just a
thread library, it will put all responsibility to developers. The
developers have to make correct library calls. BTW, pthread is C
based and only for Unix platform. In a distributed environment, we
need an object mode for distributed computing. That's why C++ thread
mode is needed in the C++ standard.
David Eng
Thomas Richter
Hi,
> > I also feel that CORBA does its job possibly only half the way it could.
> > For example, it nicely runs new threads for me serving my objects, but
> > at the same time it doesn't provide necessary services for keeping
> > object states consistent amongst the threads - there are no "mutex"
> > specifications in CORBA.
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA.
But then, CORBA *requires* the corresponding ORB/POA implementation to
provide threads one way or another, why doesn't it require from the
implementing library to provide some mutex mechanism as well? Or
rather, to make the internal locking mechanism any suitable
implementation must have anyhow available to the outside as a service?
Whether this should be part of C++ or not is another question, but it
should be definitely mandatory part of the CORBA specifications to
have. A specific implementation could still make use of a potential
"standard" mutex/threading class as soon as we had one.
> I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
This is true to some degree, but is another argument.
So long,
Thomas
Steven T. Hatton
David Eng wrote:
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
Is the problem that the committee doesn't think it's important, or is it
that the committee doesn't have the resources? What about
http://www.boost.org/libs/thread/doc/index.html? That seems to have the
unofficial blessing of the committee. I agree that C++ /seems/ a bit
behind the times when it comes to threading, and many other issues. What
about X509, and all the other crypto stuff. Take a look at the standard
Java SDK, and compare that to what you can get with a 'standard' C++ setup.
I haven't looked at C#'s offerings, but I gather it comes with a similar
arsenal of libraries.
> The [other] area bothers me is database access layer. All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library.
There are many open source libraries available, and for that matter, you
could probably make a C++ to JDBC bridge. I suspect it's already been done.
Nonetheless, I agree that standards are a good thing. I find myself
spending a lot of time hunting around for solutions to things I get as part
of Java either with the JSDK or as a freely available extension. And let
us not forget XML.
> No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
I believe C++ has a lot of problems when it comes to competing with Java and
C#. People who have never coded in Java (I can't comment on C# directly)
really have no idea of the strengths Java has as far as ease of use.
C++ _*needs*_ some kind of module support. It probably also should have
checked exceptions. I have the sense many C++ programmers don't really
understand the concepts of listeners and events as they are used commonly
in Java. All one really needs to do is to pick up _The Java Programming
Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
chapters to see how much Java offers as core features.
Too often C++ programmers become defensive and dismissive of these strengths
of Java. If someone presents an I idea which even hints that it may have
been influence by java, it is automatically rejected.
I've been putting a lot of time into C++ lately, and I know there are
significant strength in the language that Java lacks. But they may not be
sufficient to keep anything but a niche in the emerging environment. One
view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
etc., are a bunch of idiots for shifting their focus to Java (or C#).
There's not much to say to in response to such assertions. They seem to
speak for themselves.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Hyman Rosen
Jim Melton wrote:
> Writing distributed programs is hard.
And yet, Ada supports it as a built-in feature of
the language, in compilers which support the
Distributed Systems Annex E.
<http://www.adaic.org/standards/95lrm/html/RM-E.html>
Stanley Friesen
davide...@yahoo.com (David Eng) wrote in message news:<6b74193f.04042...@posting.google.com>...
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library. The another area bothers me is database access layer.
I do not see grid computing being so pervasive as you seem to think.
I WILL NOT run distributed apps on my personal computer at home, not
even with a broadband connection. And at work it is unlikely that
many of the main applications I run will be grid apps any time soon.
> All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library. No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
C++ is, and will remain, a good language for performance-critical
systems, where the performance cost of grid computing is too high.
Jorge Rivera
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may not be
> sufficient to keep anything but a niche in the emerging environment. One
> view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> etc., are a bunch of idiots for shifting their focus to Java (or C#).
> There's not much to say to in response to such assertions. They seem to
> speak for themselves.
>
I agree that both Java and C# provide more pacakges. However, to me,
part of the beaty of C++ is that it is a programming language, not a set
of technologies.
I don't think the C++ language should grow to the point of Java and C#.
If you need what Java has, go right ahead and use it. If you're
needs are well-served by C++, stick to it.
It is simple enough.
Jorge L.
---
John Nagle
language issue. Even if a standard thread library is
provided for C++, many projects will continue to use POSIX
or platform-specific thread primitives.
Locking, though, really is a core language-level issue.
As discussed below, there are some things only the compiler
can do well in this area.
Is somebody addressing this?
John Nagle
Animats
David Eng wrote:
---
ka...@gabi-soft.fr
David Abrahams <da...@boost-consulting.com> wrote in message
news:<ur7uh6...@boost-consulting.com>...
> davide...@yahoo.com (David Eng) writes:
> > We are moving to grid computing, yet C++ committee doesn't think it
> > is important to standardize a thread library.
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
I was under the impression that the Boost threading library was being
discussed. Internally, of course, and only for inclusion in the next
version of the standard.
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
It's also important to put things in a historical perspective. The C++
standard was published in 1998. That means that most of the features
being including were stabilized at least a year before, and were
proposed many years before that. I think that the cut-off date for a
completely new feature would have been something like 1995, possibly
even earlier. While I don't think that anyone today doubts the
importance of threads, I'm not sure that you could have said the same
thing in 1995. (And BTW, some of the large servers I work on still
don't use threads. All things considered, threads mean extra work, and
unless they otherwise save you more work than they cost, you're better
off without them.)
--
James Kanze GABI Software mailto:ka...@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
Thorsten Ottosen
news:Fsmdnfd76ID...@speakeasy.net...
| Is the problem that the committee doesn't think it's important, or is it
| that the committee doesn't have the resources?
lack of resources can be a problem. For example, if no threading experts are
willing to sacrifice their
freetime on helping the comittee, the commettee probably won't consider
threads.
| I believe C++ has a lot of problems when it comes to competing with Java
and
| C#. People who have never coded in Java (I can't comment on C# directly)
| really have no idea of the strengths Java has as far as ease of use.
it all depends. I think C++ can be very easy to use if you learn it the
right way.
| C++ _*needs*_ some kind of module support.
what do you mean? It already has namespaces which IMO are superior
to packages.
| It probably also should have
| checked exceptions.
checked exceptions are a pain to use; I never use them. See eg.
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
and note that C# did not include them.
| Too often C++ programmers become defensive and dismissive of these
strengths
| of Java. If someone presents an I idea which even hints that it may have
| been influence by java, it is automatically rejected.
Some might do that. However AFAICT, the general opinion of the C++ comittee
is that C++ should be easier to use; some changes to the core language can
help this and a larger std library can help this.
br
Thorsten
---
David Eng
> >
> > I've been putting a lot of time into C++ lately, and I know there are
> > significant strength in the language that Java lacks. But they may not be
> > sufficient to keep anything but a niche in the emerging environment. One
> > view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> > etc., are a bunch of idiots for shifting their focus to Java (or C#).
> > There's not much to say to in response to such assertions. They seem to
> > speak for themselves.
> >
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
>
> I don't think the C++ language should grow to the point of Java and C#.
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
This is too simplicity. How can you separate a programming language
with a set of technology that use that language. If the technology is
changing, how could the language is not changed? Otherwise, no
technology will use the language.
No one suggests that C++ should grow to the point of Java or C#. But
what's wrong for C++ to add some libraries to help to better use C++?
Do you complain about STL? A programming language never shall be
static. If technology is changed, the language shall be changed too.
llewelly
[snip]
> what do you mean? It already has namespaces which IMO are superior
> to packages.
What kind of 'packages' are you thinking of? Why do you think
namespaces are superior?
David Eng
> C#. People who have never coded in Java (I can't comment on C# directly)
> really have no idea of the strengths Java has as far as ease of use.
C++'s disadvantage is not because the strength of Java's ease of use,
rather Java and C# come with a middleware platform.
> C++ _*needs*_ some kind of module support. It probably also should have
> checked exceptions. I have the sense many C++ programmers don't really
> understand the concepts of listeners and events as they are used commonly
> in Java. All one really needs to do is to pick up _The Java Programming
> Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
> chapters to see how much Java offers as core features.
I don't know what you mean by module support. But C++ programmers
know quite well about listeners and events. It is simply a callback
mechanism which is used in every systems. Arnold, Gosling and Holmes'
book is about J2SE. Actually, it is much less offers than C++
standard. The difference is J2SE's extension called J2EE, which is a
middleware platform. J2EE is nothing new. It is based on two
technologies: CGI and CORBA. Unlike CGI and CORBA which are language
independent, J2EE is only for Java so that Java is easier to write
distributed application. However, a distributed environment is
heterogonous. Most mission critical systems cannot afford garbage
collection and unable to access to operating system.
> Too often C++ programmers become defensive and dismissive of these strengths
> of Java. If someone presents an I idea which even hints that it may have
> been influence by java, it is automatically rejected.
I agree. How often some C++ programmer argue C++ is a language and
nothing to do with technology that uses C++. They think C++ shall be
static and needn't change when the technology is changed. I think
this view is very damage to C++. If this view is held, I believe C++
will become FORTURN.
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may not be
> sufficient to keep anything but a niche in the emerging environment. One
> view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> etc., are a bunch of idiots for shifting their focus to Java (or C#).
> There's not much to say to in response to such assertions. They seem to
> speak for themselves.
Because they don't like CORBA. They think CORBA is too complicated.
But it is nature for a middleware that support different platform and
different language to be complicated. They want to make it simple.
In Java case, it only supports a single language. In Net case, it
only supports a single platform. But this is not a solution. A
distributed environment is heterogonous. Most mission critical
applications have to access to operating system and they cannot afford
garbage collection. The problem is, in my opinion, the lack of
collaboration between C++ and CORBA, and C++ is too slow to adapt the
change of technology.
---
Kevin Cline
Jim Melton <jim.m...@lmco.com> wrote in message news:<c63j4f$bk...@cui1.lmms.lmco.com>...
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility.
> At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
Binding is done by the IDL compiler with support from the marshalling
code. Why not define a modern C++ binding that could be selected when
the IDL is compiled?
David Eng
David Abrahams <da...@boost-consulting.com> wrote in message news:<ur7uh6...@boost-consulting.com>...
>
> > We are moving to grid computing, yet C++
> > committee doesn't think it is important to standardize a thread
> > library.
>
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
>
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
No! I don't think I am qualified, but that doesn't mean I cannot have
a opinion about thread. As a software engineer who make living by
writing code, I feel strongly C++ should supports thread, especially,
in a distributed environment. A thread library is different from a
language which supports thread. In a thread library, lock and unlock
must be called explicitly while they can be called implicitly in a
language that supports thread. The system will be deadlock if
something happens before the unlock is called explicitly in a thread
library. It will never happen if the language support thread because
the unlock will be called implicitly. Besides, you have to deal with
compiler, processor, and memory system if the language doesn't support
thread to write multi-thread applications. Furthermore, without a
standard thread, you have to use these proprietary thread libraries
which are hard to maintain and scale cross different platforms and
development environments. For all these reasons, C++ standard
committee shall consider next standard shall support thread.
Maciej Sobczak
Hi,
Jim Melton wrote:
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility. At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
I do not see any reason why there should be only *one* binding.
CORBA is used not only to maintain legacy systems, but also to write new
ones, where it does not really matter if the binding was defined 10
years ago or just a while ago. The "new" and "old" bindings could of
course interoperate over the wire, just like components in different
languages do. After all, the whole idea of binding is to decouple
components from the implementation details of each other.
Having the strings bound to std::string and arrays to STL sequences
would be beneficial to those who want to use CORBA in new systems. I do
not understand what is the merit of repeating this compatibility
argument over and over well 6 years after the C++ standard was set up.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Steven T. Hatton
Thomas Richter wrote:
> Whether this should be part of C++ or not is another question, but it
> should be definitely mandatory part of the CORBA specifications to
> have. A specific implementation could still make use of a potential
> "standard" mutex/threading class as soon as we had one.
>
>> I still cannot understand why C++ doesn't have a
>> standard thread library. We are moving to grid computing, yet C++
>> committee doesn't think it is important to standardize a thread
>> library.
>
> This is true to some degree, but is another argument.
>
> So long,
> Thomas
Has this been mentioned in this context? I know virtually nothing about it
other than Stroustrup mentions it in one of his web pages, and the
introductions I've read sound hopeful.
/*----------------------Excerpt------------------*/
Overview of ACE
The ADAPTIVE Communication Environment (ACE) is a freely available,
open-source object-oriented (OO) framework that implements many core
patterns for concurrent communication software. ACE provides a rich set of
reusable C++ wrapper facades and framework components that perform common
communication software tasks across a range of OS platforms. The
communication software tasks provided by ACE include event demultiplexing
and event handler dispatching, signal handling, service initialization,
interprocess communication, shared memory management, message routing,
dynamic (re)configuration of distributed services, concurrent execution and
synchronization.
ACE is targeted for developers of high-performance and real-time
communication services and applications. It simplifies the development of
OO network applications and services that utilize interprocess
communication, event demultiplexing, explicit dynamic linking, and
concurrency. In addition, ACE automates system configuration and
reconfiguration by dynamically linking services into applications at
run-time and executing these services in one or more processes or threads.
ACE continues to improve and its future is bright. ACE is supported
commercially via the Riverace corporation using an open-source business
model. In addition, many members of the ACE development team are currently
working on building The ACE ORB (TAO).
/*------------------END-Excerpt------------------*/
http://www.cs.wustl.edu/~schmidt/ACE-overview.html
http://www.awprofessional.com/title/0201604647
http://www.awprofessional.com/title/0201795256
David Eng
Thomas Richter <th...@cleopatra.math.tu-berlin.de> wrote in message news:<c6803n$pqs$1...@mamenchi.zrz.TU-Berlin.DE>...
> Hi,
>
> > > I also feel that CORBA does its job possibly only half the way it could.
> > > For example, it nicely runs new threads for me serving my objects, but
> > > at the same time it doesn't provide necessary services for keeping
> > > object states consistent amongst the threads - there are no "mutex"
> > > specifications in CORBA.
>
> > I blame this for C++. The thread mode should be built into C++
> > instead of CORBA.
>
> But then, CORBA *requires* the corresponding ORB/POA implementation to
> provide threads one way or another, why doesn't it require from the
> implementing library to provide some mutex mechanism as well? Or
> rather, to make the internal locking mechanism any suitable
> implementation must have anyhow available to the outside as a service?
> Whether this should be part of C++ or not is another question, but it
> should be definitely mandatory part of the CORBA specifications to
> have. A specific implementation could still make use of a potential
> "standard" mutex/threading class as soon as we had one.
The problem is if threads are specified by CORBA, the behavior of
implementation would be disaster. There is big different between a
thread library and a language that supports thread. In a thread
library, the lock and unlock must be called explicitly while they can
be called implicitly in a language with thread mode. In a distributed
environment, you cannot guarantee the unlock will be called
explicitly. What happen if an exception is thrown? Then the system
will locked for ever. If a language supports thread, the unlock will
be called implicitly in this situation. Since CORBA support multiple
languages and not every languages support thread. So, it is difficult
for CORBA to specify a thread mode. That's why I wonder why C++
standard doesn't have a thread standard. If a language doesn't
support thread, it will put huge burden on developers in multi-thread
applications since the compiler, processor, and memory system all can
alter the behavior of a multi-threaded applications.
Thomas Richter
Hi Jim,
> Writing distributed programs is hard.
Gee, I know. I'm writing one.
> If you have any doubt, just Google
> this group for discussions on multi-threading. Distributed programming is
> multi-threading with unknown latency and unreliable communication. It takes
> more to write a distributed program than to just slap some middleware
> between two programs you wrote. The CORBA spec represents 10 years of
> experience with what is required to do distributed programming. The stuff
> you don't think you need... you'll need it.
The point is not that "I think I don't need it, so drop it". The thing is
that the stuff I need is pretty elaborate already in fields where there's
absolutely no need for being so complex. Why's there no "layered" design
of the iterface so "I don't need to care about what I don't need to use".
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility. At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
Of course. First, that doesn't make things better, of course. It only
explains the reasons. But what about offering an optional new binding
as an extension?
> At the risk of straying even farther off-topic for this group, I'll point
> out that Michi Henning has gone on to write a middleware designed to work
> much more intuitively with C++, and has taken quite a bit of heat from,
> among others, Steve Vinoski.
I've been following this discussion, actually. However, CORBA is pretty
much standard, it works, so I'm currently very reluctant to choose
something different (incompatible).
> Again, this is off-topic for this group, and you might want to take these
> comments to the CORBA group, but "mutex" has no tractable meaning in
> distributed programming. CORBA specifies the interface by which clients may
> access distributed services, and it defines language bindings by which
> programmers may implement (or access) those services.
But whenever I implement a distributed program, it is very common that
need to consider the situation that several clients approach one server
at the same time, so I need to care about consistency very much so. I
would even go further and say that this is a pretty much central problem
in distributed software.
Ok, what about the following: I believe that the CORBA folks know quite
a lot about these problems, so what about setting up a list of features
that are generally considered "necessary" to implement a distributed
program. If the result will not be part of CORBA, it could become
part of C++ since synchronization problems are not only CORBA specific
but more general. I would really suggest that one knowledgable member
of the CORBA group approaches the C++ committee by ideas of how a
standard "distributed services" library should look like. If it also
contains threading and mutexes, it will be quite useful for everyone
else in C++.
>> > The answer is clear, the C++ standard committee and OMG
>> > must work together to create a better mapping and association between
>> > C++ and CORBA.
>>
>> Bingo.
> I don't get the question.
No question. Just my answer. I agree.
> From a CORBA programmer's perspective, a better
> C++ binding would be desirable. But from a C++ programmer's perspective, why
> should I care?
Well, even *if* you don't write CORBA, a library providing necessary services
for CORBA (and even though I'm far from an expert, I believe threads and
mutexes are essential for that) and for CORBA applications will help you a lot
in other situations. Plus, these are the people that should have the
experience in the field.
> Why do you assume that CORBA will triumph over SOAP or EJB or
> the next greatest fad in distributed programming?
I, personally? I don't know. I'm using it "because it works". If I also
get a SOAP or EJB implementation that is common enough to be found available
for Java, C++, C and various operating systems like Linux or Windows, I
could also use that.
So long,
Thomas
Steven T. Hatton
>>
>> I've been putting a lot of time into C++ lately, and I know there are
>> significant strength in the language that Java lacks. But they may not
>> be sufficient to keep anything but a niche in the emerging environment.
>> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
>> Borland, etc., are a bunch of idiots for shifting their focus to Java (or
>> C#).
>> There's not much to say to in response to such assertions. They seem to
>> speak for themselves.
>>
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
I can't say much for C#. I've never even written hello world in it. As for
Java. Java *_is_* a programming language. It has many very nice features.
One of the best things about Java is the significant structure it
manifests. Because of the clearly defined structure of packages
hierarchies, and the suite of intuitive tools to go with it, it really does
enhance a more abstract style of programming.
I really don't like to dwell on comparrisons, but some of them are worth
presenting as a means of suggesting improvements to the way C++ is
designed, supported, and used. One example that comes to mind from just
today's experiences is the difference between a typical make and Makefile
approach to building projects, and the javac and jakarta ant approach.
I've been using the gnu autotools for the better part of a decade, and I
still find most of my actions are based on guess work, and simply knowing
what worked in the past. I sat down with ant for a day, and understood the
basics.
C++ coders seem to accept these kinds of difficulties as being part of
working with the language. But the frequently presented rationalization
that the reason C++ is hard to used and learn is because it's powerful is
only partly valid. Certainly, there are capabilities in C++ that cause the
programmer to have a deeper understanding of what it actually taking place
at the level of memory mapping. And there are efficiency enhancing
features that require more care and understanding in C++ than in Java.
OTOH, the fact that Java provides a far more uniform infrastructure across
platforms and projects makes it far easier to create powerful tools for
supporting the programmer in these environments. I'm not just talking
about the JRE. I'm talking about a level of IDE support powerful enough
that I am virtually assured that my code will compile and run without
producing errors in the sense defined by the language specification.
Many of these features have their origins in C++, but for one reason or
another they have not gained the same level of effectiveness in C++ as they
have in Java.
> I don't think the C++ language should grow to the point of Java and C#.
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
One of the biggest problems I see is that people entering the industry are
presented with the alternatives of learning Java, C#, C++, or some less
popular language. C++ tends to be less well supported by the kinds of
tools that make it easy to learn the language, and to locate resources such
as classes in a library.
The C++ programmers who have a few more years of experience simply accept
that it was difficult to learn, and that's just the cost of using it. Many
of them don't seem interested in reducing the barriers to entry for the
people coming behind them. One thing these oldtimers fail to appreciate is
that there is far more to learn in order to produce software that matches
today's expectations, than there was 10 years ago.
I see that resistance to change as rather shortsighted. Leaving the
callousness of the attitude to the side, it is reasonable such an
indifference to the difficulties faced by new entrants in to the field will
reduce the number of new programmers who choose to focus on C++. That
could prove to have a significant cumulative impact. There will be fewer
people creating new libraries and technologies. There will be less
interest on the part of companies to invest in C++ related technologies,
while at the same time the financial and intellectual resources will be
diverted into the competing languages. That will result in a steady
improvement in those technologies while C++ loses ground.
There are people who will tell you they heard the same thing 10 years ago
about C++. 'It didn't happen then, and it won't happen now.' That may
well be true. But it certainly isn't the the credit of those peoples who
refuse to consider improvements and enhancements. The success of C++ is
not due to their resistance. It is despite it.
I certainly don't want to break the language, or make it just like Java, or
C#. I'm glad there are people with conservative leanings who provide a
counter force to that introduce by new suggestions. But I do believe there
is a lot of room for improvement.
---
Steven T. Hatton
> "Steven T. Hatton" <susu...@setidava.kushan.aa> wrote in message
> | C++ _*needs*_ some kind of module support.
>
> what do you mean? It already has namespaces which IMO are superior
> to packages.
I don't see C++ namespaces as being similar to Java packages other than a
vaguely similar notion of containment and hierarchy. I'm not sure Java
packages are an ideal solution to what I find problemmattic with C++. I
know a good deal of my hands-on time spent while learning C++ has involved
issues related to #includes and linking libraries. I find the CPP approach
to 'modularity' frustrating to put it mildly.
> | It probably also should have
> | checked exceptions.
>
> checked exceptions are a pain to use; I never use them. See eg.
I was trying to explain to someone why I rarely have to trace through code
with a debugger in Java because of the edit-time code verification JBuilder
provides. At first I didn't realize exactly what was keeping me safe. But
after thinking about it, I realized it was the use of checked exceptions.
With JBuilder, I am alerted to the existence of a /throws/ modifier I have
failed to handle. I can then highlight the selected statement, hit
Ctl+shift+C and the statement is automatically wrapped in a properly
constructed try/catch block handling each exception type explicitly.
That goes back to my belief that IDE support should be a consideration when
designing new language features. I would be loath to write all that code
by hand. Especially if I had to dig through reference documentation to
determine exactly what might be thrown by each function call.
> http://www.mindview.net/Etc/Discussions/CheckedExceptions
This is less than convincing to me. He basically says he taught people to do
it in the word possible way, and by golly, that's what they did!
"My theory is that when someone is trying to do something and you are
constantly prodding them with annoyances, they will use the quickest device
available to make those annoyances go away so they can get their thing
done, perhaps assuming they'll go back and take out the device later. I
discovered I had done this in the first edition of Thinking in Java:
...
} catch (SomeKindOfException e) {}
"And then more or less forgot it until the rewrite. How many people thought
this was a good example and followed it? I began seeing the same kind of
code, and realized people were stubbing out exceptions and then they were
disappearing. The overhead of checked exceptions was having the opposite
effect of what was intended, something that can happen when you experiment
(and I now believe that checked exceptions were an experiment based on what
someone thought was a good idea, and which I believed was a good idea until
recently)."
This is a complete working example of how I handle situations of this nature
in Java. It is far more verbose than it needs to be in oder to effectively
use Java's exception mechanism, but it demonstrate the general case:
package checkedexceptions;
/**
* Extended <code>Exception</code> for demonstration.
*/
public class MyException extends Exception {
public MyException() {}
public MyException(String message) {
super(message);
}
public MyException(String message, Throwable cause) {
super(message, cause);
}
public MyException(Throwable cause) {
super(cause);
}
}
package checkedexceptions;
import java.io.PrintStream;
/**
* A program to demonstreate exception handling in Java
*
*/
public class ExceptionChecker {
/**
* Added to make the example as general as possible.
*/
private PrintStream err;
/**
* Default constructor.
*/
public ExceptionChecker() {
this(System.err);
}
/**
* Constructor allowing the error stream to be specified.
* @param err Specified err <code>PrintStream</code>.
*/
public ExceptionChecker(PrintStream err) {
this.err = err;
}
/**
* Demonstrates throwing an <code>Exception</code> subclass.
* @throws MyException Deterministaclly throws
*/
void generateException() throws MyException {
throw new MyException("This was on purpose.");
}
/**
* Catches <code>MyException</code> and prints the stack
* trace to <code>err</code>.
*/
void tryIt(){
try {
generateException();
}
catch (MyException ex) {
ex.printStackTrace(this.err);
}
}
/**
* Catches and implicitly rethrows <code>MyException</code>
* @throws MyException
*/
void doubleTry() throws MyException {
this.tryIt();
}
/**
* Throws any <code>Exception</code> subclass as <code>Exception</code>
* @throws Exception
*/
void lazyTry() throws Exception {
this.doubleTry();
}
public static void main(String[] args) {
ExceptionChecker ec = new ExceptionChecker();
ec.tryIt();
try {
ec.doubleTry();
ec.lazyTry();
}
catch (MyException ex) {
ex.printStackTrace();
}
catch (Exception ex) {
ex.printStackTrace();
}
}
}
checkedexceptions.MyException: This was on purpose.
at
checkedexceptions.ExceptionChecker.generateException(ExceptionChecker.java:17)
at checkedexceptions.ExceptionChecker.tryIt(ExceptionChecker.java:22)
at checkedexceptions.ExceptionChecker.main(ExceptionChecker.java:35)
checkedexceptions.MyException: This was on purpose.
at
checkedexceptions.ExceptionChecker.generateException(ExceptionChecker.java:17)
at checkedexceptions.ExceptionChecker.tryIt(ExceptionChecker.java:22)
at checkedexceptions.ExceptionChecker.doubleTry(ExceptionChecker.java:30)
at checkedexceptions.ExceptionChecker.main(ExceptionChecker.java:38)
>http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
> and note that C# did not include them.
I don't see the two references you provided as a support for the status quo
in C++. The first article was simply not persuasive. The second merely
demonstrates that the notion of using checked exceptions needs refinement.
In both cases the argument that the exception /had/ to be "quietly
swallowed" is probably not correct.
> | Too often C++ programmers become defensive and dismissive of these
> strengths
> | of Java. If someone presents an I idea which even hints that it may
> | have been influence by java, it is automatically rejected.
>
> Some might do that. However AFAICT, the general opinion of the C++
> comittee is that C++ should be easier to use; some changes to the core
> language can help this and a larger std library can help this.
That kind of reminds me of an anecdote from the Army. When people suggested
certain things others would respoind "the General isn't gonna like that."
How do they know? Did they ask the General?
---
Thorsten Ottosen
news:86fzatq...@Zorthluthik.local.bar...
| nes...@cs.auc.dk ("Thorsten Ottosen") writes:
| [snip]
| > what do you mean? It already has namespaces which IMO are superior
| > to packages.
| [snip]
|
| What kind of 'packages' are you thinking of?
I was thinking of Java packages when Steven mentioned module support. They
exist primarily to group code together, just like namespaces.
| Why do you think
| namespaces are superior?
because you can
1. have your package spread freely over files and directories; you are not
forced to use one directory
2. you can use a short qualified notation
3. you can put together a new packages just by picking what to include from
an old
As an example of 2, consider
// java
package foo.bar.x.y.z;
public class X { .... }
// somewhere else
foo.bar.x.y.z.X x = new foo.bar.x.y.z.X();
[remark: so you are forced to make an import statement which won't work when
there is two X's flying around]
// C++
#include <foo/bar/x/y/z/X.hpp>
namespace foobar = foo::bar::x::y::z;
foobar::X x;
br
Thorsten
Thorsten Ottosen
===================================== MODERATOR'S COMMENT:
Warning -- topic drift.
===================================== END OF MODERATOR'S COMMENT
""Steven T. Hatton"" <hat...@globalsymmetry.com> wrote in message
news:YL2dnewENt-...@speakeasy.net...
| Thorsten Ottosen wrote:
|
| > "Steven T. Hatton" <susu...@setidava.kushan.aa> wrote in message
|
| > | C++ _*needs*_ some kind of module support.
| >
| > what do you mean? It already has namespaces which IMO are superior
| > to packages.
|
| I don't see C++ namespaces as being similar to Java packages other than a
| vaguely similar notion of containment and hierarchy. I'm not sure Java
| packages are an ideal solution to what I find problemmattic with C++. I
| know a good deal of my hands-on time spent while learning C++ has involved
| issues related to #includes and linking libraries.
was that because you had to learn it by yourself from scratch?
FWIW, it took me some time to set up a make-system for a large a java
project too.
Have you ever used bjam from boost?
| > | It probably also should have
| > | checked exceptions.
| >
| > checked exceptions are a pain to use; I never use them. See eg.
|
| I was trying to explain to someone why I rarely have to trace through code
| with a debugger in Java because of the edit-time code verification
JBuilder
| provides. At first I didn't realize exactly what was keeping me safe.
safe from what?
| But
| after thinking about it, I realized it was the use of checked exceptions.
| With JBuilder, I am alerted to the existence of a /throws/ modifier I have
| failed to handle.
how do you define "handle". e.printStackTrace() ?
| That goes back to my belief that IDE support should be a consideration
when
| designing new language features. I would be loath to write all that code
| by hand.
another reason why it might be wrong what you're doing.
| > http://www.mindview.net/Etc/Discussions/CheckedExceptions
|
| This is less than convincing to me. He basically says he taught people to
do
| it in the word possible way, and by golly, that's what they did!
yes indeed.
[snip example]
|
>http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsW
ereAMistake.html
|
| > and note that C# did not include them.
|
| I don't see the two references you provided as a support for the status
quo
| in C++.
wrt checked exceptions, then they probably do; together with C#'s decision
not to use them. They
remove flexibility of a program immensely (just consider the rules for
redefing a virtual function which throws a couple of
exceptions).
What I woul like to see in C++ is to change the current exception specs not
to do runtime-checks, but merely
to be a documentation feature that won't have anything to do with
overloading or redefinition.
| The first article was simply not persuasive. The second merely
| demonstrates that the notion of using checked exceptions needs refinement.
| In both cases the argument that the exception /had/ to be "quietly
| swallowed" is probably not correct.
Bruce Eckel don't advocate to swallow exceptions. He had a wrong example in
his first book.
On his page you can find a class that allows checked exceptions to be
rethrown as an unchecked.
br
Thorsten
Frank Buss
davide...@yahoo.com (David Eng) wrote:
> A thread library is different from a
> language which supports thread. In a thread library, lock and unlock
> must be called explicitly while they can be called implicitly in a
> language that supports thread. The system will be deadlock if
> something happens before the unlock is called explicitly in a thread
> library. It will never happen if the language support thread because
> the unlock will be called implicitly.
Java supports threads, but you can have deadlocks even if the language
supports threads, but perhaps do you have ideas how the language can
avoid it? With functional languages like Haskell and Parallel Haskell it
would be easier, because there are no side-effects so the compiler can
parallelize the program without the need to program it explicit, but
deadlocks are still possible, if you want explicit synchronisation.
> Besides, you have to deal with
> compiler, processor, and memory system if the language doesn't support
> thread to write multi-thread applications.
A standard library could hide it, like the STL library hides the
implementation details. I just can write vector<int> and don't need to
know anything about the memory system. The Boost library has cross
platform thread support:
http://www.boost.org/libs/thread/doc/index.html
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
ka...@gabi-soft.fr
> news:<ur7uh6...@boost-consulting.com>...
> > davide...@yahoo.com (David Eng) writes:
> > > We are moving to grid computing, yet C++ committee doesn't think
> > > it is important to standardize a thread library.
> > Please. Did you submit a proposal for a standard threads library?
> > Did anyone? [hint: the answer is no]
> > The "C++ committee thinks" (as though we are all of one mind, but
> > I'll play along) that a threading library is important. I don't
> > think we have any threading experts with the time to bring forward a
> > proposal on it. If you think you're qualified, please do it
> > yourself.
> No! I don't think I am qualified, but that doesn't mean I cannot have
> a opinion about thread. As a software engineer who make living by
> writing code, I feel strongly C++ should supports thread, especially,
> in a distributed environment. A thread library is different from a
> language which supports thread. In a thread library, lock and unlock
> must be called explicitly while they can be called implicitly in a
> language that supports thread.
In the Boost threading library, I believe that lock and unlock are
private functions, which cannot be called explicitly. In no C++
threading library that I am familiar with is it necessary to call unlock
explicitly. On the other hand, there are significant cases where the
lock does not obey normal scoping rules; the locking mechanisms built
into languages like Java don't work in such cases, and require
significant complications to work around their limits.
> The system will be deadlock if something happens before the unlock is
> called explicitly in a thread library.
A deadlock can occur whether the locks are part of the language, or in a
separate library.
> It will never happen if the language support thread because the unlock
> will be called implicitly.
Only when you leave the scope in which the lock is held. Exactly as in
C++.
> Besides, you have to deal with compiler, processor, and memory system
> if the language doesn't support thread to write multi-thread
> applications.
Memory synchronization issues is one reason why threading must be
treated at the language level. Things like initialization of local
statics is another. IMHO, the interface to the locking functions should
remain a library function.
--
James Kanze GABI Software mailto:ka...@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
ka...@gabi-soft.fr
"Steven T. Hatton" <susu...@setidava.kushan.aa> wrote in message
> David Eng wrote:
> > I blame this for C++. The thread mode should be built into C++
> > instead of CORBA. I still cannot understand why C++ doesn't have a
> > standard thread library. We are moving to grid computing, yet C++
> > committee doesn't think it is important to standardize a thread
> > library.
> Is the problem that the committee doesn't think it's important, or is
> it that the committee doesn't have the resources? What about
> http://www.boost.org/libs/thread/doc/index.html? That seems to have
> the unofficial blessing of the committee. I agree that C++ /seems/ a
> bit behind the times when it comes to threading, and many other
> issues. What about X509, and all the other crypto stuff. Take a look
> at the standard Java SDK, and compare that to what you can get with a
> 'standard' C++ setup. I haven't looked at C#'s offerings, but I
> gather it comes with a similar arsenal of libraries.
If not following every silly fad that comes along means being behind the
times, so be it. There is no particular reason to integrate everything
into the language standard; there are even several very good reasons not
to, if you want to remain a general purpose language, instead of
targetting just a few niches.
> > The [other] area bothers me is database access layer. All these
> > database vendors promote JDBC because there is no a standard C++
> > access library. If these vendors stop to support their proprietary
> > C++ API, who will use C++ in a distributed environment? I never
> > head C++ committee even has an initiative to standardize a database
> > access layer library.
> There are many open source libraries available, and for that matter,
> you could probably make a C++ to JDBC bridge. I suspect it's already
> been done. Nonetheless, I agree that standards are a good thing. I
> find myself spending a lot of time hunting around for solutions to
> things I get as part of Java either with the JSDK or as a freely
> available extension. And let us not forget XML.
For the equivalent of JDBC, there's always the OTL. I'm not sure that
it is the right solution: I have my doubts about ostreaming selection
parameters, and I haven't used it enough concretely to confirm or deny
them. But it looks like a good point to start discussions, and it
certainly does get the job done.
For the rest, I repeat: not everything belongs in a language standard.
Generally speaking, if you can implement it in standard C++, it only
belongs in a language standard if it is needed pretty universally:
std::vector, std::string or std::sort, for example. Otherwise, the
basic argument for is based on the fact that you cannot implement it, or
you cannot implement it efficiently, in standard C++. Threading
certainly qualifies, a data base bridge might. std::latest_in_format
doesn't. (Why XML, for example, and not BER encoded ASN.1? BER encoded
ASN.1 is probably more widely used, is certainly stabler, and has been
around a lot longer.)
> > No matter how great C++ is, without a standard thread and data
> > access libraries, C++ will have a hard time to survive in a
> > distributed computing. Just to imagine how C++ can survive in a
> > system computing without an I/O library! If the committee thinks
> > proprietary libraries can do the job, I am sure that C++ will not
> > be a mainstream programming language; it will downgrade to a third
> > class language doing some limited applications.
> I believe C++ has a lot of problems when it comes to competing with
> Java and C#. People who have never coded in Java (I can't comment on
> C# directly) really have no idea of the strengths Java has as far as
> ease of use.
Java's fine for some things, especially if you are working in one of the
niches where it is specialized. It doesn't cut it if you need
reliability or safety, though, and it doesn't lend itself to large scale
programming, nor to system level programming. (You can't implement a
JVM in Java, for example. And I've done some large scale work in Java
to know of its weaknesses there.)
> C++ _*needs*_ some kind of module support.
I think that there is a general consensus that textual inclusion is NOT
the ideal way of handling modules. Regretfully, there doesn't seem to
be much consensus as to what is the right way.
> It probably also should have checked exceptions.
I agree, but I suspect that I am in a very small minority.
It's worth noting, too, that most Java developers systematically derive
from RunTimeException to avoid the checking. In practice, Java doesn't
really have checked exceptions -- it just pretends it does. (In
practice, Java seems to have found an interesting compromize: all the
pains of checked exceptions, without any of the advantages.)
> I have the sense many C++ programmers don't really understand the
> concepts of listeners and events as they are used commonly in Java.
What makes you think this? I seems like a commonly used idiom in C++.
And a lot safer in C++ than in Java, at least in the typical uses I've
seen. Generally speaking, to use it well, you need multiple
inheritance. Or at least some way of enforcing a contract for an
interface. On the other hand, of course, it is a lot easier to use if
you have garbage collection, but since it typically doesn't involve
cycles, and uses objects that make no sense other than on the heap, you
can get by reasonably well with invasive reference counting. You also
need some sort of type safe container to hold your listeners, and that
is (or was until very recently) seriously lacking in Java.
> All one really needs to do is to pick up _The Java Programming
> Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
> chapters to see how much Java offers as core features.
Actually, if you don't get beyond the first 10 or so chapters, you'll
find more of what is missing. Practically speaking, in fact, unless you
get to libraries or infrastructure, you'll really only encounter things
that are missing. Java, the language, has a very few advantages over
C++: it's easier to parse, if you need to write a parser, it has garbage
collection, and it has real arrays, that act like first class objects.
On the other hand, you don't have any scope dependant user defined
types, and so no destructors or other clean-up mechanism, you don't have
any possibility of writing type safe containers, listern mechanisms,
etc., the language pretty much forbids writing strict interfaces (no
programming by contract), it has strange rules for the resolution of
virtual functions, which means that you often end up in a virtual
function on an object that hasn't been constructed. You complained
about the fact that C++ uses textual inclusion to separate interface
from implementation; Java doesn't even allow the separation. The
absense of any possibility to use programming by contract pretty much
excludes the use of Java for critical systems, and the lack of
separation between the class definition and its implementation pretty
much means you can't use it on large projects.
> Too often C++ programmers become defensive and dismissive of these
> strengths of Java. If someone presents an I idea which even hints
> that it may have been influence by java, it is automatically rejected.
Not at all. I've done some fairly large projects in Java, and at one
time, knew it at least as well as I know C++. The more I used it,
however, the more I realized that it simply wasn't appropriate for the
type of work I do (large scale servers), nor for the type of work I'd
done a lot of in the past (real time industrial systems and system level
programming). It would be my first choice for a web page server (based
on JSP), and despite all of the problems due to the lack of type safe
containers and multiple inheritance, I really liked Swing. But in both
cases, it isn't the language which is determinating, it is the
infrastructure or the library.
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may
> not be sufficient to keep anything but a niche in the emerging
> environment.
In which environment. There are certain environments in which C++ has
pratically disappeared (if it was ever present). They are very much in
view, but taken globally, I don't know if they represent that big of a
percentage of actual software.
> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
> Borland, etc., are a bunch of idiots for shifting their focus to Java
> (or C#). There's not much to say to in response to such assertions.
> They seem to speak for themselves.
Hmmm. Microsoft seems to have moved its focus from Java, and at least
for the moment, C# or not, seems to take the attitude that C++ will be
around for a long time as well, and has a place in their plans. Borland
seems to prefer Delphi. But that is neither here nor there. There is
definitly a market for the latest fad; it would be silly for any of the
above named companies to ignore it. Just as it would be silly for them
to put all of their eggs in the Java basket. IMHO, Microsoft seems to
have understood this, and is steering a middle ground. Sun seems to
have shot itself in the foot, not so much because it supported and
pushed Java, but because it forgot its bread and butter products (Unix
based workstations) in doing so. (Note that Microsoft hasn't slowed
down developments on Windows or MS-Office simply because they have C#.)
--
James Kanze GABI Software mailto:ka...@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
Le Chaud Lapin
na...@animats.com (John Nagle) wrote in message news:<NqAhc.53906>
> But if the compiler is going to help with locking, language
> support is needed.
Why?
> Some things only the compiler can do:
>
> - generate direct locking instructions inline when
> appropriate.
> - lock at every entry to an object from the outside
> - optimize out unneeded locks
> - Calls to a public function from inside an
> object may not need a relock.
> - access functions that retrieve a single
> value using an atomic machine operation
> may not need locking. (Yes, you have
> to check for the case where a value is
> updated twice within a member function, offering
> the possibility of a transient value.)
> - Functions that don't access member data or functions
> don't need locking.
Again, why? By locking, do you mean bus locking, spin locks, or
mutex-type locks. I am thinking you mean mutex type locks. If so,
certainly you are aware that there is some non-trivial overhead
involved in performing the lock.
Is it so hard to make a portable mutex class and call ::lock() and
::unlock()?
-Chaud Lapin-
---
llewelly
[snip]
> platforms and projects makes it far easier to create powerful tools for
> supporting the programmer in these environments. I'm not just talking
> about the JRE. I'm talking about a level of IDE support powerful enough
> that I am virtually assured that my code will compile and run without
> producing errors in the sense defined by the language specification.
>
> Many of these features have their origins in C++, but for one reason or
> another they have not gained the same level of effectiveness in C++ as they
> have in Java.
IMO, the primary reason C++ environments typically do not provide
that level of support for writting code which is correct w.r.t
the langauge definition has everything to do with the incredible
complexity of parsing C++, and very little to do what gets
bundled into the standard library. (Short of a complete library
for parsing and transforming C++ source code, that is.)
ka...@gabi-soft.fr
Frank Buss <f...@frank-buss.de> wrote in message
news:<c6h93m$5r8$1...@newsreader2.netcologne.de>...
> davide...@yahoo.com (David Eng) wrote:
[...]
> > Besides, you have to deal with
> > compiler, processor, and memory system if the language doesn't support
> > thread to write multi-thread applications.
> A standard library could hide it, like the STL library hides the
> implementation details.
Not completely. What happens if some of the generated code uses static
variables. An obvious candidate would be exception processing, and at
least one compiler I have used does fail if two threads throw an
exception at the same time.
Generally speaking, threading is a special case, because it must be
recognized by the basic language. Today, in the Unix world, we count on
compilers being not just standard C++ compliant, but also Posix
compliant (and Posix does recognize threads). It's a bit awkward, since
Posix compliance doesn't say anything about threads, but we can
exterpolate most things rather intuitively -- the main unanswered
question concerns the initialization of local static variables (or even
global statics, if a constructor of a global static starts a thread).
> I just can write vector<int> and don't need to know anything about the
> memory system. The Boost library has cross platform thread support:
> http://www.boost.org/libs/thread/doc/index.html
Except that it doesn't work for the most important platform: mine:-).
At least if I understand the documentation correctly, it also can't be
used directly for what is one of the more common locking idioms in my
code: the lock is acquired in a function and is returned as part of the
return value. (Typically in a sort of a smart pointer -- I acquire
access to the object and a lock for it from a single function, and
automatically free the lock when the access goes out of scope. The
entire thing works a lot like auto_ptr, with the addition that which
ever object holds the valid pointer also holds the lock.)
--
James Kanze GABI Software mailto:ka...@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
ka...@gabi-soft.fr
Hyman Rosen <hyr...@mail.com> wrote in message
news:<10826536...@master.nyc.kbcfp.com>...
> Jim Melton wrote:
> > Writing distributed programs is hard.
> And yet, Ada supports it as a built-in feature of
> the language, in compilers which support the
> Distributed Systems Annex E.
> <http://www.adaic.org/standards/95lrm/html/RM-E.html>
That doesn't mean that writing distributed programs isn't hard. It
might mean that if you want to do hard things, you need Ada:-).
Seriously, I'm not sure what a language should do to support distributed
programming. The problem is that so many things that we do which have
negligible cost (for most people) don't have negligible cost when you
distribute. When the cost of calling a function goes up to 10-100
milliseconds, regardless of what you do in the function, you really have
to think about doing as much as possible, in a single function. If I'm
developping in C++, on a single machine, I won't hesitate to use getters
for each individual piece of data. If I'm working over a Corba
interface to a remote machine, however, I'll design a custom function:
getWhatINeed -- the server must know enough about me to send everything
in one go (in a specialized struct which contains everything that I
need, typed).
--
James Kanze GABI Software mailto:ka...@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
David Abrahams
ka...@gabi-soft.fr wrote in message news:<d6652001.04042...@posting.google.com>...
> David Abrahams <da...@boost-consulting.com> wrote in message
> news:<ur7uh6...@boost-consulting.com>...
> > davide...@yahoo.com (David Eng) writes:
>
> > > We are moving to grid computing, yet C++ committee doesn't think it
> > > is important to standardize a thread library.
>
> > Please. Did you submit a proposal for a standard threads library?
> > Did anyone? [hint: the answer is no]
>
> I was under the impression that the Boost threading library was being
> discussed. Internally, of course, and only for inclusion in the next
> version of the standard.
Someone may be discussing it, but if so only in the hallways between
sessions. And we don't have a proposal. Without a proposal, hallway
discussion is not very meaningful.
--
David Abrahams
Boost Consulting
http://www.boost-consulting.com
David Abrahams
> > The "C++ committee thinks" (as though we are all of one mind, but I'll
> > play along) that a threading library is important. I don't think we
> > have any threading experts with the time to bring forward a proposal
> > on it. If you think you're qualified, please do it yourself.
>
> No! I don't think I am qualified, but that doesn't mean I cannot have
> a opinion about thread.
You're perfectly qualfied to have an opinion about threads. You're
not qualified to make pronouncements about what the committee thinks
is important.
<snip reasons threads are important>
> For all these reasons, C++ standard
> committee shall consider next standard shall support thread.
Sorry, the committee doesn't work that way. Things don't get
considered just because they're important. It's a volunteer
organization, and topics are only considered when there are people
with the energy and expertise to lead the way. If nobody who can do
that for threads shows up, nothing's going to happen.
--
David Abrahams
Boost Consulting
http://www.boost-consulting.com
John Torjo
I'm not sure I follow. Should C++ change in order to fit
ADO,ODBC,COM,XML (if you think that's a technology) or who knows what
other technology?
The point is technologies come and go. Should we have C++ features
that just come and go? I think the only thing C++ should do is allow a
technology to be mapped as a library in C++. And I think existing C++
is doing quite a good job at it.
Best,
John
John Torjo
Freelancer
-- jo...@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
John Torjo
> Jorge Rivera wrote:
>
> >>
> >> I've been putting a lot of time into C++ lately, and I know there are
> >> significant strength in the language that Java lacks. But they may not
> >> be sufficient to keep anything but a niche in the emerging environment.
> >> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
> >> Borland, etc., are a bunch of idiots for shifting their focus to Java (or
> >> C#).
> >> There's not much to say to in response to such assertions. They seem to
> >> speak for themselves.
> >>
> >
> > I agree that both Java and C# provide more pacakges. However, to me,
> > part of the beaty of C++ is that it is a programming language, not a set
> > of technologies.
>
> I can't say much for C#. I've never even written hello world in it. As for
> Java. Java *_is_* a programming language. It has many very nice features.
> One of the best things about Java is the significant structure it
> manifests. Because of the clearly defined structure of packages
> hierarchies, and the suite of intuitive tools to go with it, it really does
> enhance a more abstract style of programming.
>
> I really don't like to dwell on comparrisons, but some of them are worth
> presenting as a means of suggesting improvements to the way C++ is
> designed, supported, and used. One example that comes to mind from just
> today's experiences is the difference between a typical make and Makefile
> approach to building projects, and the javac and jakarta ant approach.
>
makefiles are a thing of the past.
Usually every IDE has its own way of handling projects (take for
instance msvc).
However, you should try boost bjam. Very easy - sort of a java ant.
>
> OTOH, the fact that Java provides a far more uniform infrastructure across
> platforms and projects makes it far easier to create powerful tools for
> supporting the programmer in these environments. I'm not just talking
> about the JRE. I'm talking about a level of IDE support powerful enough
> that I am virtually assured that my code will compile and run without
> producing errors in the sense defined by the language specification.
>
> Many of these features have their origins in C++, but for one reason or
> another they have not gained the same level of effectiveness in C++ as they
> have in Java.
>
True. I do think that in the near future (3-5 years), someone (maybe
me :D) with a lot of C++ experience should sit down and learning from
C++ mistakes, make a new language.
Best,
John
John Torjo
Freelancer
-- jo...@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
---
Francis Glassborow
In message <6b74193f.04041...@posting.google.com>, David Eng
<davide...@yahoo.com> writes
>As I posted in CORBA group, I believe the future of C++ depends on
>CORBA (the same is true that the future of CORBA depends on the future
>of C++). Applications are built today are distributed applications
>instead of stand alone applications.
There is a common trap that assumes that an individuals view of
something is the same as everyone else's. There are many things done
with C++ that have nothing to do with distributed systems/processes.
Indeed most of the applications I use actually have to be protected from
interference from elsewhere, they are essentially single system, local
applications. For example, when editing digital video I have absolutely
no need for any kind of distributed process and will probably disconnect
from the outside world so as to ensure that nothing interrupts the flow
of data from, for example, camera to hard drive.
In the same way, if CORBA was mainly concerned with C++ it would have no
future. Its strength is exactly that it is multi-platform,
multi-language. It would be a mistake for CORBA to tie itself to C++.
Now, unless some positive suggestions surface I do not intend to further
participate in this dialogue which seems to consist of a good number of
assertions and basically 'X ought to do something about this.' I have
long been a practitioner of the dictum 'Put up, or shut up.' I.e. if you
(generic usage) are not willing to act stop telling other people what
they should do.'
--
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 ]
John Torjo
> >
> > significant strength in the language that Java lacks. But they may not be
> > sufficient to keep anything but a niche in the emerging environment. One
> > view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> > etc., are a bunch of idiots for shifting their focus to Java (or C#).
> > There's not much to say to in response to such assertions. They seem to
> > speak for themselves.
> >
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
>
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
>
Another thing: generics have a reusability at an order of magnitude
higher that OOP (IMO).
So a good library in C++ is worth 20 of Java or so ;)
Best,
John
John Torjo
Freelancer
-- jo...@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
---
Frank Buss
ka...@gabi-soft.fr wrote:
> Not completely. What happens if some of the generated code uses
> static variables. An obvious candidate would be exception processing,
> and at least one compiler I have used does fail if two threads throw
> an exception at the same time.
You are right, the standard must say something about threads to ensure a
compiler, which works with threads, but the language needs not to be
changed, only some definitions for thread safety needs to be added, I
think.
This is not easy, because your problem with static variables and the like
is a general problem of imperative programming languages. The best
solution would be to start threads without manual programming it, which
is possible with referential transparency, because every part of an
expression can be evaluated without side effects:
http://c2.com/cgi/wiki?ReferentialTransparency
But would be nice to have explicit thread support for C++, because
writing imperative programs is easier, at least for me.
> At least if I understand the documentation correctly, it also can't be
> used directly for what is one of the more common locking idioms in my
> code: the lock is acquired in a function and is returned as part of
> the return value. (Typically in a sort of a smart pointer -- I
> acquire access to the object and a lock for it from a single function,
> and automatically free the lock when the access goes out of scope.
> The entire thing works a lot like auto_ptr, with the addition that
> which ever object holds the valid pointer also holds the lock.)
Looks like a mutex is what you are searching for, perhaps wrapped in a
small class with overloaded operator= etc., something like a smart
pointer which wraps a mutex.
ka...@gabi-soft.fr
> ka...@gabi-soft.fr wrote:
[...]
> > At least if I understand the documentation correctly, it also can't
> > be used directly for what is one of the more common locking idioms
> > in my code: the lock is acquired in a function and is returned as
> > part of the return value. (Typically in a sort of a smart pointer
> > -- I acquire access to the object and a lock for it from a single
> > function, and automatically free the lock when the access goes out
> > of scope. The entire thing works a lot like auto_ptr, with the
> > addition that which ever object holds the valid pointer also holds
> > the lock.)
> Looks like a mutex is what you are searching for, perhaps wrapped in a
> small class with overloaded operator= etc., something like a smart
> pointer which wraps a mutex.
I know what I am looking for; I've even written it for Posix compatible
platforms:-). You cut the sentence I was responding to: a
recommendation to use Boost's threading package. Boost's threading
package requires the lock on a mutex to have lexical scope; there are a
lot of times when my locks don't -- the respect transfer of ownership
rules much like those of auto_ptr. And I could imagine that there are
cases where one might want shared ownership as well; after all, most of
the time, you lock to protect access to memory, so it isn't surprising
to find the same idioms for possession of locks as for possession of
memory.
--
James Kanze GABI Software mailto:ka...@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
David Abrahams
ka...@gabi-soft.fr writes:
> Frank Buss <f...@frank-buss.de> wrote in message
> news:<c7392u$88v$1...@newsreader2.netcologne.de>...
>
>> ka...@gabi-soft.fr wrote:
>
> [...]
>> > At least if I understand the documentation correctly, it also can't
>> > be used directly for what is one of the more common locking idioms
>> > in my code: the lock is acquired in a function and is returned as
>> > part of the return value. (Typically in a sort of a smart pointer
>> > -- I acquire access to the object and a lock for it from a single
>> > function, and automatically free the lock when the access goes out
>> > of scope. The entire thing works a lot like auto_ptr, with the
>> > addition that which ever object holds the valid pointer also holds
>> > the lock.)
>
>> Looks like a mutex is what you are searching for, perhaps wrapped in a
>> small class with overloaded operator= etc., something like a smart
>> pointer which wraps a mutex.
>
> I know what I am looking for; I've even written it for Posix compatible
> platforms:-). You cut the sentence I was responding to: a
> recommendation to use Boost's threading package. Boost's threading
> package requires the lock on a mutex to have lexical scope; there are a
> lot of times when my locks don't -- the respect transfer of ownership
> rules much like those of auto_ptr.
That's why we didn't prohibit dynamic allocation of locks ;-)
Yes, a moveable but non-copyable lock would be better.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
ka...@gabi-soft.fr
> ka...@gabi-soft.fr writes:
> > Frank Buss <f...@frank-buss.de> wrote in message
> > news:<c7392u$88v$1...@newsreader2.netcologne.de>...
> >> ka...@gabi-soft.fr wrote:
> > [...]
> >> > At least if I understand the documentation correctly, it also
> >> > can't be used directly for what is one of the more common
> >> > locking idioms in my code: the lock is acquired in a function
> >> > and is returned as part of the return value. (Typically in a
> >> > sort of a smart pointer -- I acquire access to the object and a
> >> > lock for it from a single function, and automatically free the
> >> > lock when the access goes out of scope. The entire thing works
> >> > a lot like auto_ptr, with the addition that which ever object
> >> > holds the valid pointer also holds the lock.)
> >> Looks like a mutex is what you are searching for, perhaps wrapped
> >> in a small class with overloaded operator= etc., something like a
> >> smart pointer which wraps a mutex.
> > I know what I am looking for; I've even written it for Posix
> > compatible platforms:-). You cut the sentence I was responding to:
> > a recommendation to use Boost's threading package. Boost's
> > threading package requires the lock on a mutex to have lexical
> > scope; there are a lot of times when my locks don't -- the respect
> > transfer of ownership rules much like those of auto_ptr.
> That's why we didn't prohibit dynamic allocation of locks ;-)
Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
I originally started thinking about the issue during an email discussion
with Scott Meyers over the double checked locking idiom for a
singleton. The fact is that there is no correct implementation which
doesn't either lock on every call to Singleton::instance, or use
assembler or some other very special code to implement memory barriers.
But it occured to me that very often, using the singleton, once you
acquired the reference to it, would also require a lock, and that in
such cases, if you used the same lock when accessing the singleton AND
in Singleton::instance(), you don't pay any more for locking than if
Singleton::instance() wasn't locked -- all you've done is move the
acquisition of the lock necessary to use the singleton forward.
And while using
std::auto_ptr< boost::lock >( new boost::lock( someMutex ) )
would certainly fulfil the desired semantics, I suspect that most
implementations of operator new will also acquire a lock, which defeats
the whole purpose of the exercise.
Now, I basically think that the "correct" solution is to just lock in
Singleton::instance(), and then lock when you access the object, using
two separate lock/unlock sequences, at least until the profiler says
otherwise. And that when the profiler says otherwise, the simplest
solution is just to drop the locks in Singleton::instance(), and ensure
that Singleton::instance() is called at least once before threading is
started. But the context of the discussion was saving a lock, and the
problem is intellectually stimulating, even if it is of no practical
interest:-).
And finally, having thought about all this, it occured to me that we do
something similar in our current application. In our case, it isn't
singletons, but objects acquired from our data base -- we acquire an
object through a smart pointer, which also manages a lock on the
object. Here too, I'm not convinced that this is the right solution --
we now access several different objects in the same transaction, which
requires some special, and fairly complex, code to avoid deadlocks. But
it was a very elegant solution for the initial requirements, where the
code never accessed more than one object at a time.
> Yes, a moveable but non-copyable lock would be better.
Or maybe a lock-ownership policy:-). I can imagine that there are a few
cases where reference counted locks might be reasonable too.
Seriously, I'm against over complexity. The Boost solution is right
something between 90-95% of the time. All I'd ask for is access to the
underlying lock()/unlock() functions on mutex, so I can provide a custom
solution for the few remaining cases.
--
James Kanze GABI Software mailto:ka...@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
Alexander Terekhov
ka...@gabi-soft.fr wrote:
[...]
> I originally started thinking about the issue during an email discussion
> with Scott Meyers over the double checked locking idiom for a
> singleton. The fact is that there is no correct implementation which
> doesn't either lock on every call to Singleton::instance, or use
> assembler or some other very special code to implement memory barriers.
Thread-specific data can be used instead of atomic<>-with-membars.
> But it occured to me that very often, using the singleton, once you
> acquired the reference to it, would also require a lock,
Not if it's immutable (or uses atomic<> internally).
regards,
alexander.
David Abrahams
ka...@gabi-soft.fr writes:
> > That's why we didn't prohibit dynamic allocation of locks ;-)
>
> Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
>
> I originally started thinking about the issue during an email discussion
> with Scott Meyers over the double checked locking idiom for a
> singleton. The fact is that there is no correct implementation which
> doesn't either lock on every call to Singleton::instance, or use
> assembler or some other very special code to implement memory barriers.
You use boost::call_once and that problem goes away.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Michael Glassford
<ka...@gabi-soft.fr> wrote in message
news:d6652001.04050...@posting.google.com...
[snip discussion of std::auto_ptr< boost::lock >(...), etc.]
> Seriously, I'm against over complexity. The Boost solution is right
> something between 90-95% of the time. All I'd ask for is access to
> the underlying lock()/unlock() functions on mutex, so I can provide
a
> custom solution for the few remaining cases.
I'll add it to my list of things to think about. As a quick idea,
would adding protected lock() and unlock() members to the mutex
classes work? (Not public so they can't be called accidentally by
users of the class, not private so you can create a derived mutex
class that works in conjunction with a lock class that you design).
Mike
Matt Austern
da...@boost-consulting.com (David Abrahams) writes:
> ka...@gabi-soft.fr wrote in message news:<d6652001.04042...@posting.google.com>...
> > David Abrahams <da...@boost-consulting.com> wrote in message
> > news:<ur7uh6...@boost-consulting.com>...
> > > davide...@yahoo.com (David Eng) writes:
> >
> > > > We are moving to grid computing, yet C++ committee doesn't think it
> > > > is important to standardize a thread library.
> >
> > > Please. Did you submit a proposal for a standard threads library?
> > > Did anyone? [hint: the answer is no]
> >
> > I was under the impression that the Boost threading library was being
> > discussed. Internally, of course, and only for inclusion in the next
> > version of the standard.
>
> Someone may be discussing it, but if so only in the hallways between
> sessions. And we don't have a proposal. Without a proposal, hallway
> discussion is not very meaningful.
We don't have a proposal yet, but my understanding is the same as
James's: that there's discussion going on, with the intention that
a proposal be submitted.
At the moment I believe that Boost threading library is the only
threading library that's likely to be proposed any time soon. So if
anyone here has an alternative threading approach that they prefer,
now's the time to start working on a proposal.
ka...@gabi-soft.fr
Alexander Terekhov <tere...@web.de> wrote in message
news:<409BB6F4...@web.de>...
> ka...@gabi-soft.fr wrote:
> [...]
> > I originally started thinking about the issue during an email
> > discussion with Scott Meyers over the double checked locking idiom
> > for a singleton. The fact is that there is no correct
> > implementation which doesn't either lock on every call to
> > Singleton::instance, or use assembler or some other very special
> > code to implement memory barriers.
> Thread-specific data can be used instead of atomic<>-with-membars.
The problem is that at least on some systems, accessing thread specific
data involves acquiring a lock, so you don't gain anything. If an
implementation has a good implementation of thread specific data, of
course, it is an alternative.
> > But it occured to me that very often, using the singleton, once you
> > acquired the reference to it, would also require a lock,
> Not if it's immutable (or uses atomic<> internally).
But if it's immutable, it is sufficient to ensure that it is created
before starting threading, and you don't need a lock anywhere. (Hmmm.
I suppose if you had a data base in which you could create and destroy
objects, but not modify them, the case might occur.)
--
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
ka...@gabi-soft.fr
Michael Glassford <nos...@hotmail.com> wrote in message
news:<1dGdnXyKGfX...@adelphia.com>...
> [snip discussion of std::auto_ptr< boost::lock >(...), etc.]
> > Seriously, I'm against over complexity. The Boost solution is right
> > something between 90-95% of the time. All I'd ask for is access to
> > the underlying lock()/unlock() functions on mutex, so I can provide
> > a custom solution for the few remaining cases.
> I'll add it to my list of things to think about. As a quick idea,
> would adding protected lock() and unlock() members to the mutex
> classes work? (Not public so they can't be called accidentally by
> users of the class, not private so you can create a derived mutex
> class that works in conjunction with a lock class that you design).
That sounds like a very good compromize; about the only possible
objection I can see is that it requires an abuse of derivation to use
the special functions.
In one project I worked on in the past, dangerous functions were
qualified with names beginning with "unsafe_"; what about calling them
"unsafe_lock" and "unsafe_unlock"? (OK, it's just an idea. I'm not
fully convinced myself.)
The real problem, I think, is that we are dealing with two levels of
abstraction, one very low level, where you are on your own, and one at a
higher level, which should be used most of the time. Normally, that
would be two, apparently separate classes, and as long as you dealt
strictly at the higher level, you wouldn't need to even be aware of the
lower level. That doesn't quite work here, because even as a client of
the higher level, you have to manage the lifetime and the sharing of the
lower level object; it would be very hard to use Lock if you couldn't
refer to the mutex it should lock on.
So even from a purely abstract design level, I'm not sure what the most
elegant solution would be. What I want is a low level interface that is
not normally available, but that can be made available if I do something
intentional to get to it. And in fact, the only solution I can think of
which meets exactly those requirements is protected. Even if that
wasn't really the original use protected was designed for. Who knows,
maybe we're even creating a new idiom. (It will be an easy idiom to
recognize. How often do you see protected elements in a class with no
virtual functions?)
--
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
John Nagle
> ka...@gabi-soft.fr writes:
>>Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
Somehow, I have the horrible feeling that will break in
an obscure way which will not be discovered until it's too late.
John Nagle
Animats
---
Pete Becker
ka...@gabi-soft.fr wrote:
>
> So even from a purely abstract design level, I'm not sure what the most
> elegant solution would be. What I want is a low level interface that is
> not normally available, but that can be made available if I do something
> intentional to get to it.
Sort of like FILE*, from which (with most implementations) you can drop
down to a file descriptor to do lower level reads and writes.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Alexander Terekhov
ka...@gabi-soft.fr wrote:
[...]
> > > But it occured to me that very often, using the singleton, once you
> > > acquired the reference to it, would also require a lock,
>
> > Not if it's immutable (or uses atomic<> internally).
>
> But if it's immutable, it is sufficient to ensure that it is created
> before starting threading, and you don't need a lock anywhere. ...
But that defeats the purpose (save on memory and/or processor
cycles needed to initialize the thing until the first use...
which may never occur).
regards,
alexander.
ka...@gabi-soft.fr
> ka...@gabi-soft.fr wrote:
> [...]
> > > > But it occured to me that very often, using the singleton, once
> > > > you acquired the reference to it, would also require a lock,
> > > Not if it's immutable (or uses atomic<> internally).
> > But if it's immutable, it is sufficient to ensure that it is
> > created before starting threading, and you don't need a lock
> > anywhere. ...
> But that defeats the purpose (save on memory and/or processor cycles
> needed to initialize the thing until the first use... which may never
> occur).
That's not the purpose; if an object such as std::string is to be
immutable, it must be constructed before the first user thread is
created. The problem is that if you have something like:
static std::string const ref( "someText" ) ;
void
f( std::string const& param )
{
if ( param == ref ) ...
}
you need a lock around the if. Whereas if I do the same thing with char
const[]/char const* and strcmp, I don't. (I am assuming, of course,
that param is only visible in the calling thread, and that f can be
called from more than one thread.)
This seems counter-intuitive; one expects user defined types, especially
such low level user defined types, to behave more or less like built-in
types.
--
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
Alexander Terekhov
ka...@gabi-soft.fr wrote:
[...]
> That's not the purpose; if an object such as std::string is to be
> immutable, it must be constructed before the first user thread is
> created.
It must not.
> The problem is that if you have something like:
>
> static std::string const ref( "someText" ) ;
>
> void
> f( std::string const& param )
> {
> if ( param == ref ) ...
> }
>
> you need a lock around the if.
You need not.
> Whereas if I do the same thing with char
> const[]/char const* and strcmp, I don't. (I am assuming, of course,
> that param is only visible in the calling thread, and that f can be
> called from more than one thread.)
You don't need a lock if you do the same thing with std::string.
>
> This seems counter-intuitive; one expects user defined types, especially
> such low level user defined types, to behave more or less like built-in
> types.
I agree that the following is kinda counter-intuitive.
int thing[123];
int read_global_thing() {
return thing[0]; // non-modifying access
}
vs
std::string thing;
int read_global_thing() {
return thing[0]; // modifying access
}
But the problem doesn't arise if you access it via "const &".
regards,
alexander.