The future of C++ - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

The future of C++
Goto page 1, 2, 3, 4, 5 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

David Eng
Guest

Posted: Wed Apr 14, 2004 2:39 pm Post subject: The future of C++

Quote:

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.
CORBA's strength is built on programming language independence. There
is need for Java or C# to talk to C++. If C++ doesn't have a future,
why applications need to talk to C++? If no applications talk to C++,
then why people need to use CORBA since Java has EJB middleware and C#
has .NET? The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA. They must understand that the future of C++ and CORBA
is dependent on each other. If they realize this relationship, I
believe the future of C++ and CORBA is bright. The reason is simple:
together, C++ and CORBA can build mission critical applications which
Java and C# cannot even think about.

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

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

Edward Diener
Guest

Posted: Thu Apr 15, 2004 9:21 pm Post subject: Re: The future of C++

David Eng wrote:

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bryan Bullard
Guest

Posted: Thu Apr 15, 2004 9:21 pm Post subject: Re: The future of C++

"David Eng" <davideng2004 (AT) yahoo (DOT) com> wrote

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Le Chaud Lapin
Guest

Posted: Fri Apr 16, 2004 4:07 pm Post subject: Re: The future of C++

[email]davideng2004 (AT) yahoo (DOT) com[/email] (David Eng) wrote in message news:<6b74193f.0404130754.5c40f511 (AT) posting (DOT) google.com>...

Quote:

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

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Asfand Yar Qazi
Guest

Posted: Sat Apr 17, 2004 10:54 pm Post subject: Re: The future of C++

David Eng wrote:

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Steven T. Hatton
Guest

Posted: Sun Apr 18, 2004 6:03 am Post subject: Re: The future of C++

Bryan Bullard wrote:

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

John Nagle
Guest

Posted: Mon Apr 19, 2004 5:34 pm Post subject: Re: The future of C++

There's something to be said for providing C++ with
enough introspection to allow generation of marshalling code
via suitable templates. Currently, you have to define
interfaces for CORBA, OpenRPC, or DCOM in an external
language which is then processed into C source by an
interface generator.

This direction might give the template fanatics something
useful to do.

Actually, RMI is part of the "core Java" specification.

John Nagle
Animats

Steven T. Hatton wrote:

Quote:

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.

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

Thomas Richter
Guest

Posted: Tue Apr 20, 2004 2:28 pm Post subject: Re: The future of C++

Hi,

Quote:

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.

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

David Eng
Guest

Posted: Wed Apr 21, 2004 3:48 pm Post subject: Re: The future of C++

Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

John Nagle
Guest

Posted: Wed Apr 21, 2004 8:55 pm Post subject: Threads/locking [Was: The future of C++]

If you think of threads in terms of a library, that's not
a matter for C++ standardization. We already have POSIX threads,
which are available across multiple platforms.

But if the compiler is going to help with locking, language
support is needed.

Some things only the compiler can do:

- generate direct locking instructions inline when
appropriate.
- lock at every entry to an object from the outside
- optimize out unneeded locks
- Calls to a public function from inside an
object may not need a relock.
- access functions that retrieve a single
value using an atomic machine operation
may not need locking. (Yes, you have
to check for the case where a value is
updated twice within a member function, offering
the possibility of a transient value.)
- Functions that don't access member data or functions
don't need locking.

So there's a real payoff to making the compiler knowledgeable about
locking.

John Nagle
Animats

David Eng wrote:

Quote:

Thomas Richter <thor (AT) cleopatra (DOT) 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. 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.

David Abrahams
Guest

Posted: Thu Apr 22, 2004 4:29 pm Post subject: Re: The future of C++

[email]davideng2004 (AT) yahoo (DOT) com[/email] (David Eng) writes:

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Jim Melton
Guest

Posted: Thu Apr 22, 2004 4:29 pm Post subject: Re: The future of C++

"Thomas Richter" <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

John Nagle
Guest

Posted: Thu Apr 22, 2004 5:45 pm Post subject: Re: The future of C++

David Abrahams wrote:

Quote:

davideng2004 (AT) yahoo (DOT) com (David Eng) writes:

We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library.

Actually, "grid computing", even if it happens, is independent
of threads. Threads are a local issue. Things like CORBA
need marshalling support, not threading. An introspection
mechanism good enough to do that would be helpful. The
ability to iterate through the data members of an object at
template instantiation time would be helpful.

A good metric for template/instrospection interaction is
whether you can write a template that generates efficient
marshalling code for an object. If one could write different templates
that generated marshalling for a few common protocols (OpenRPC,
Java RMI, Microsoft DCOM, SOAP), that would be a big win.

Quote:

I'd put locking in the language, but leave threading to POSIX.
I've discussed an approach to object-level safe locking before.
If someone wants to solicit me to write a formal proposal,
I'd be willing to do it.

John Nagle
Animats

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

David Eng
Guest

Posted: Thu Apr 22, 2004 8:56 pm Post subject: Re: Threads/locking [Was: The future of C++]

[email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote in message news:<NqAhc.53906$Nn7.33879 (AT) newssvr25 (DOT) news.prodigy.com>...

Quote:

That what I mean. Compilers shall handle the synchronous primitives.
Puting a library into C++ standard have two purposes. First, if
compilers can generate better code, the compilers shall do it.
Second, the compilers shall enforce error checking. If it is just a
thread library, it will put all responsibility to developers. The
developers have to make correct library calls. BTW, pthread is C
based and only for Unix platform. In a distributed environment, we
need an object mode for distributed computing. That's why C++ thread
mode is needed in the C++ standard.

David Eng

Quote:

David Eng wrote:
Thomas Richter <thor (AT) cleopatra (DOT) 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. 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.

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

Thomas Richter
Guest

Posted: Fri Apr 23, 2004 2:34 pm Post subject: Re: The future of C++

Hi,

Quote:

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.

Quote:

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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page 1, 2, 3, 4, 5 Next
Page 1 of 5

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum