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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 47  3589 
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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
"David Eng" <da**********@yahoo.com> wrote in message
news:6b**************************@posting.google.c om... > 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.
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?
...
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**********@yahoo.com (David Eng) wrote in message news:<6b**************************@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
of C++). [snip]
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...
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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++?
<snip>
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.
-- http://www.it-is-truth.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Thomas Richter <th**@cleopatra.math.tu-berlin.de> wrote in message news:<c6**********@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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
"David Eng" <da**********@yahoo.com> wrote Thomas Richter <th**@cleopatra.math.tu-berlin.de> wrote > 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.
Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.
I still cannot understand why C++ doesn't have a standard
thread library.
Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that Mr.
Eng favors.
We are moving to grid computing, yet C++ committee doesn't
think it is important to standardize a thread library.
That's because they're not idiots. And grid computing has nothing to do with
threads, which you'd know if you had a clue as to the meaning of grid
computing.
The another area bothers me is database access layer.
Why, you're just full of little irritants, aren't you?
All these database vendors promote JDBC because there is no
a standard C++ access library.
They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.
If these vendors stop to support their proprietary C++ API,
who will use C++ in a distributed environment?
Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even have
a passing thought about it.
I never head C++ committee even has an initiative to
standardize a database access layer library.
Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.
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.
It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.
Just to imagine how C++ can survive in a system computing
without an I/O library!
Just imaging how well we'd survive without imbeciles spamming our newsgroup
with their drivel.
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.
Hold your breath. Please!
Claudio Puviani
* "Claudio Puviani" write in reply to David Eng:
Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.
Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that Mr.
Eng favors.
Why, you're just full of little irritants, aren't you?
They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.
Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even have
a passing thought about it.
Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.
It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.
Just imaging how well we'd survive without imbeciles spamming our newsgroup
with their drivel.
Hold your breath. Please!
I read the above as personal attack only -- please read the FAQ, Claudio.
It seems you do not have a point at all, and know it.
E.g., as you well know, Boost.Threads may just make it into C++0x.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
I read the above as personal attack only -- please read the FAQ, Claudio.
I disagree. He does have some points scattered in the angry response...
It seems you do not have a point at all, and know it.
????? The point is simple enough. C++ does not need more libraries to
survive. Just because Java and MS gigantic .NET framework have a lot of
external libraries does not mean that C++ will not survive.
"Claudio Puviani" <pu*****@hotmail.com> wrote in message news:<5E**********************@news4.srv.hcvlny.cv .net>... I blame this for C++. The thread mode should be built into C++
instead of CORBA.
Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.
It is fortunate that the people on the standards committee are
competent enough to understand the importance of thread. I am pretty
sure that the next C++ standard will include thread mode. So who has
absurd idea? I still cannot understand why C++ doesn't have a standard
thread library.
Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that
Mr. Eng favors.
What a fatuous statement! Does every platform support templates or
support in the same way? What a language feature does on a platform
is through the compiler. A language supports a feature so that the
compiler can generate code for underline platform. It is nothing to
do with (a) or (b) Mr. Claudio Puviani stated above. If a platform
doesn't support thread, that means it cannot run thread program. If
it supports thread, the compiler will generate code for the platform
to run the thread. I just want to see thread can built into language
so that compiler can generate more efficient code instead of putting
burden on developers. If C++ has a standard thread library, it also
promote code reuse and portability, instead of each platform
implementing its own libraries. When you switch platform, you only
need recompile instead of rewriting. We are moving to grid computing, yet C++ committee doesn't
think it is important to standardize a thread library.
That's because they're not idiots. And grid computing has nothing to do with
threads, which you'd know if you had a clue as to the meaning of grid
computing.
The main theme of grid computing is parallel and distributed
computing. Thread is one of the most important features to support
grid computing. That's why thread mode will be in the next C++
standard. I don't know who is idiot and doesn't have a clue? The another area bothers me is database access layer.
Why, you're just full of little irritants, aren't you?
All these database vendors promote JDBC because there is no
a standard C++ access library.
They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.
If these vendors stop to support their proprietary C++ API,
who will use C++ in a distributed environment?
Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even
have a passing thought about it.
I never head C++ committee even has an initiative to
standardize a database access layer library.
Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.
First, there are no major database vendors support ODBC interface,
they only support ODBC drivers. Most of them provide their own API
instead of ODBC API. Second, ODBC is a C based interface and is
poorly designed by Microsoft (maybe designed by Mr. Claudio Puviani
-:). There are proprietary libraries to wrap ODBC into C++ API. The
problem is most companies use several database engines and change
these database engines quite often. If there is no a standard C++
interface, you have to write different code for different database
engines. When a database engine is changed, you have to rewrite your
code. That's why all the major database vendor promote Java instead
of C++. If C++ has a standard database access library, thing will be
different. Database is so important in enterprise environment. A
database access library is analogous to file access library I/O. I am
confident that the C++ standard committee are smart enough to listen
to this suggestion. 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.
It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.
Let us see who is paranoid. I can hardly imagine my post will cause
you such anger and hysteric. This is a public forum. People can
voice their opinions. If you don't like it, that fine. What you did
here is personal attack. I don't think a decent person will act like
you. I wish you learn some basic decency before debating a issue.
On 22 Apr 2004 06:56:20 -0700, da**********@yahoo.com (David Eng) wrote: "Claudio Puviani" <pu*****@hotmail.com> wrote in message news:<5E**********************@news4.srv.hcvlny.cv .net>...
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA.
Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.
It is fortunate that the people on the standards committee are
competent enough to understand the importance of thread. I am pretty
sure that the next C++ standard will include thread mode. So who has
absurd idea?
Just a note: It is common but incorrect to confuse "standards committee"
with "design team." I frequently see the C++ committee referred to as
though it were the latter, and it really isn't.
In particular, a design team is responsible for making sure important
areas get covered, is much more cohesively organized, and is led by
someone who makes final decisions. A standards committee is driven by
proposals from its members and as a group considers and refines/rejects
such proposals, it is looser, and it makes decisions only by group
consensus. The process generally works well because of the diversity of
the membership which to helps ensure that someone somewhere is likely to
be interested in each of the important things, and because the membership
includes active participation and direction from Bjarne which also helps
avoid "holes" in the design. But the process still can leave holes in
that, if no one has the interest, time, or expertise to write up a
proposal about feature X, then X won't be in the standard no matter how
important it may seem to be.
Besides that, speaking to threading in particular, there's also the
consideration that it's difficult or impossible to standardize something
that varies too greatly across the industry. Threading may or may not fall
into that category.
Herb
---
Herb Sutter ( http://blogs.gotdotnet.com/hsutter) ( www.gotw.ca)
Convener, ISO WG21 (C++ standards committee) ( www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal ( www.gotw.ca/cuj)
Visual C++ architect, Microsoft ( www.gotw.ca/microsoft) da**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
"Thomas Richter" <th**@cleopatra.math.tu-berlin.de> wrote in message
news:c6**********@mamenchi.zrz.TU-Berlin.DE...
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.
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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>
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**********@yahoo.com (David Eng) wrote in message news:<6b**************************@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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
David Abrahams <da**@boost-consulting.com> wrote in message
news:<ur***********@boost-consulting.com>... da**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Thomas Richter <th**@cleopatra.math.tu-berlin.de> wrote in message news:<c6**********@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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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
--
STH http://www.kdevelop.org http://www.suse.com http://www.mozilla.org
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Jim Melton <ji********@lmco.com> wrote in message news:<c6*********@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?
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
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/
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
David Abrahams <da**@boost-consulting.com> wrote in message news:<ur***********@boost-consulting.com>... da**********@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. 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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:<Fs********************@speakeasy.net>... 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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**********@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ß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**********@yahoo.com (David Eng) wrote in message
news:<6b**************************@posting.google. com>... David Abrahams <da**@boost-consulting.com> wrote in message
news:<ur***********@boost-consulting.com>... da**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Frank Buss <fb@frank-buss.de> wrote in message
news:<c6**********@newsreader2.netcologne.de>... da**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Hyman Rosen <hy*****@mail.com> wrote in message
news:<10***************@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**********@yahoo.com (David Eng) wrote in message news:<6b**************************@posting.google. com>... David Abrahams <da**@boost-consulting.com> wrote in message news:<ur***********@boost-consulting.com>...
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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] ka***@gabi-soft.fr wrote in message news:<d6**************************@posting.google. com>... David Abrahams <da**@boost-consulting.com> wrote in message
news:<ur***********@boost-consulting.com>... da**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
In message <6b**************************@posting.google.com >, David Eng
<da**********@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 ]
[ your news-reader. If that fails, use mailto:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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.
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Frank Buss <fb@frank-buss.de> wrote in message
news:<c7**********@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. 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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] ka***@gabi-soft.fr writes: Frank Buss <fb@frank-buss.de> wrote in message
news:<c7**********@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 ]
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
David Abrahams <da**@boost-consulting.com> wrote in message
news:<ui***********@boost-consulting.com>... ka***@gabi-soft.fr writes:
Frank Buss <fb@frank-buss.de> wrote in message
news:<c7**********@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
<ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om...
[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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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 ]
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] da**@boost-consulting.com (David Abrahams) writes: ka***@gabi-soft.fr wrote in message news:<d6**************************@posting.google. com>... > David Abrahams <da**@boost-consulting.com> wrote in message
> news:<ur***********@boost-consulting.com>... > > da**********@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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Alexander Terekhov <te******@web.de> wrote in message
news:<40***************@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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Michael Glassford <no****@hotmail.com> wrote in message
news:<1d********************@adelphia.com>... <ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om...
[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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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)
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Alexander Terekhov <te******@web.de> wrote in message
news:<40***************@web.de>... 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
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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.
[ 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:st*****@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: GTO |
last post by:
I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is...
|
by: Lyle Fairfield |
last post by:
It's confusing. Many people here and elsewhere make many different
predictions:
There's an introduction mentioning some aspects of this at...
|
by: |
last post by:
Everything seems to be moving to .NET and VC++ seems to be adding a lot of
managed code support every new release.
The questions: is unmanaged code in VC++ beeing phased out in favour of
managed...
|
by: Fuzzyman |
last post by:
Hello all,
The following is a copy of a blog entry. It's asking a question about
future statements and the built in compile function. I'd appreciate any
pointers or comments about possible...
|
by: Zootal |
last post by:
My apologies if this gets asked/discussed a lot. With c# rampaging through
corporate USA (and other countries), what impact will this have on the usage
and future of c++? I've used both of them a...
|
by: rohayre |
last post by:
Im a long time java developer and actually have never done anything
with java scripting. I'd like to write a short simple script for
calculating a date in the future based on today's date and a...
|
by: blangela |
last post by:
If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.
I have been teaching...
|
by: KimmoA |
last post by:
Does C have a future? I'd like to think so, but nobody seems to agree
with me. Of course, I don't use C in my profession, and maybe I
wouldn't be using it if I had the pressure to actually produce...
|
by: Jon Harrop |
last post by:
If Microsoft turn F# into a product and place it alongside C# and VB, will
many people migrate from C# to F#?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
