next ISO/ANSI standard for C++

[skoco]

Hello!
Do you know when will be the new standard for c++ approved? And WHAT
will be inside? Hope there will be some thread and synchro classes,
text and XML parsing, new containers and other new things. God save me
from coding in boring & slow & no pointers java!!
p.s.: how much time usually needs the compiler vendors to implement
new standards?
p.s.2: anybody knows which compiler supports export keyword?

Thanks to you all.

 

[Sharad Kala]

Hello!
Do you know when will be the new standard for c++ approved? And WHAT
will be inside? Hope there will be some thread and synchro classes,
text and XML parsing, new containers and other new things. God save me
from coding in boring & slow & no pointers java!!
p.s.: how much time usually needs the compiler vendors to implement
new standards?
p.s.2: anybody knows which compiler supports export keyword?

I don't know when C++ standard is going to be revised again. But I really wish
that things you mentioned like threads, XML parsing etc are included this time.
Now that jdk1.5 is out and it has generics support (on template lines), C++
should also get rich enough with other things in a standard way.
No idea how much time our compiler vendors will take to adopt the new additions.
May be people like Greg Comeau can comment on this
Right now only Comeau has proper support for export keyword AFAIK.

-Sharad

 

[Wolfgang Kaufmann]

* Thus spoke skoco <[email protected]>:

Hallo,

Do you know when will be the new standard for c++ approved?

No. My guess is that we won't be seeing it any time soon. (2006-2009)

And WHAT will be inside?

p.s.: how much time usually needs the compiler vendors to implement
new standards?

Too long. ;-)


Wolfgang.

 

[Claudio Puviani]

I don't know when C++ standard is going to be revised again. But I really wish
that things you mentioned like threads, XML parsing etc are included this time.
Now that jdk1.5 is out and it has generics support (on template lines), C++
should also get rich enough with other things in a standard way.
No idea how much time our compiler vendors will take to adopt the new additions.
May be people like Greg Comeau can comment on this
Right now only Comeau has proper support for export keyword AFAIK.

I don't mean this deprecatingly, but the you both seem to be new to C++ and
unaware of the underlying philosophy of the language. C++, like C, takes a
minimalist approach to language features and standard libraries, which is what
has allowed C and C++ to be so easily ported to a large number of vastly
different platforms. Let's look at your wish list point by point:

1) Threads - threads are a concept that doesn't exist on every platform. Many
embedded systems don't have threads. Some older, but still supported systems,
also don't have threads. For this reason alone, adding threads to the language
is dangerous. But to make things worse, threads don't work the same way on all
operating systems. Some allow different scheduling strategies, some don't. Some
allow time slice quantization, some don't. Some allow scheduling priorities,
some don't. Some allow signals to go to any thread, some force signals to go to
specific threads, some have no signals at all. The Standards committee isn't
about to jump in that tar pit when they can just waggle their finger in the
direction of pthreads.

2) Synchronization mechanisms - even if we ignore point 1, which would make this
point moot, and look at the simplest of synchronization mechanisms: the mutex.
Even lowly mutexes are different across platforms. On some platforms, mutexes
are recursive, on others, recursive calls deadlock you. On some platforms,
mutexes can be shared across processes, on others, you have different promitives
to do that. And then, the poor Standards critters would have to choose what
primitives to include. Semaphores? Condition variables? Events? Mailboxes? FIFO
queues? Atomic integer operations? And do you emulate them on platforms that
don't support them natively? With all respect due to the immensely competent
people on the committee, I wouldn't trust even them to make that choice for me.

3) XML - now this one's easy. XML is an application-specific data
representation. That has no business being shoehorned into a language
specification. Again, the Standards committee would correctly point you to one
of the many existing libraries.

This keeps coming back, but the C++ community just doesn't want a Java-like,
bloated, jack-of-all-trades-but-master-of-none standard library.

Claudio Puviani

 

[Sharad Kala]

I don't mean this deprecatingly, but the you both seem to be new to C++ and
unaware of the underlying philosophy of the language. C++, like C, takes a
minimalist approach to language features and standard libraries, which is what
has allowed C and C++ to be so easily ported to a large number of vastly
different platforms. Let's look at your wish list point by point:

Don't want to sound cheeky, cocky or start a flame war but seems like you think
you are expert enough to judge other people. I personally think one should
refrain from it unless you like to argue much.

Most of the projects I have worked on have required XML somewhere or the other.
You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.
Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere or the other
and then you include #ifdefs for your platform in your code because your product
runs on various platforms. Wouldn't it be good to just provide a standard way of
making the calls and let the compiler decide what to do under the hood?

Though I agree with you that the minimalist approach has made C and C++ to be
easily portable across platforms and extending the library would require more
work to be done by our compiler vendors. I have been reading about the
possibilities of library getting extended for quite some time and just voiced
what I felt would make life of a developer to concentrate more on standard ways
rather than deal with 3rd party or OS intricacies.

-Sharad

 

[Victor Bazarov]

Don't want to sound cheeky, cocky or start a flame war but seems like you think
you are expert enough to judge other people. I personally think one should
refrain from it unless you like to argue much.

Everybody is allowed to judge other people, and one doesn't have to be
an expert to do that (at least according to my experience). This is
a public forum and I personally think one should refrain from telling
others what they should refrain from (although I don't always follow
my own advice either).

Most of the projects I have worked on have required XML somewhere or the

other.

So what? Out of twenty-plus years I've been programming, only about
two years total I did some work involving XML. Doesn't at all speak
to XML widespread-ness, but mostly to the length of one's career, no?

You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.
Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

No, it wouldn't. Just like it wouldn't to have some kind of networking
or GUI capability.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere

Got any statistics about that?

or the other
and then you include #ifdefs for your platform in your code because your product
runs on various platforms. Wouldn't it be good to just provide a standard way of
making the calls and let the compiler decide what to do under the hood?

No. The more the compiler has to decide, the less probable it is to
have a decent compiler or a compiler that satisfies enough people for
it to be a viable product. By the time such compiler comes out, the
language will have died.

Though I agree with you that the minimalist approach has made C and C++ to be
easily portable across platforms and extending the library would require more
work to be done by our compiler vendors. I have been reading about the
possibilities of library getting extended for quite some time and just voiced
what I felt would make life of a developer to concentrate more on standard ways
rather than deal with 3rd party or OS intricacies.

Please voice it in comp.std.c++ and see what kind of reaction you get.

"OS intricacies" are not going away any time soon, and are becoming more
and more numerous every year. How do you really expect language creators
to follow those and integrate them into the language? And (for the sake
of argument) if the Committee does catch up with OS changes and other new
technologies (like XML) popping up here and there, you would also need
compiler developers to catch up, and they cannot do it without the language
being fully defined.

The only way to standardise C++ way of treating things like network, GUI,
XML, threads, OS-specific stuff, etc., is to make them standard as well.
How long will that take and how rigid will they become?

V

 

[Jason]

Most of the projects I have worked on have required XML somewhere or the
other.

You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.
Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

There are many 3rd party libraries, or you can even write your own XML
parser (gasp!). C++ is used because it, as a "core entity", is portable. If
you add too many features too quickly it is hard to find conforming
compilers. With Java this isn't the case, because Sun make Java and it's
class libraries, and that is the end of things; there is no need for vendor
agreement. What I am trying to say is C++ is borne out of a different
community ethic.

Anyway, what about ASN.1. I want ASN.1 support in C++ not pesky XML.

.... these are my thoughts anyway, and of course they are not correct in any
formal sense.

 

[Peter van Merkerk]

Don't want to sound cheeky, cocky or start a flame war but seems like you think
you are expert enough to judge other people. I personally think one should
refrain from it unless you like to argue much.

Most of the projects I have worked on have required XML somewhere or the

other.

Your experience is not necessarilly representative for the rest of the
world. The majority of projects I have done many projects that didn't
involve XML. What people use most is highly dependant on the kind of
projects they do and what kind of business they are in.

You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.

I would not like to see standard C++ become as bloated as Java. I would
like to see (interface) standardization for libraries in some areas, but
not as part of the C++ standard.

Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

The way I see it is best to keep the core of C++ lean and mean. The more
features that are added to core definition the less portable the language
becomes, simply because some features are not available on every
conceivable platform. For areas that tend to be domain specific I prefer to
see separate standards, rather than a single standard that covers
everything-but-the-kitchen-sink.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere or the other
and then you include #ifdefs for your platform in your code because your product
runs on various platforms. Wouldn't it be good to just provide a standard way of
making the calls and let the compiler decide what to do under the hood?

Yes, but what if the compiler cannot make that decision? How to overcome
conceptual differences? Often the differences are more than just different
names for functions that do the same thing. Just letting the compiler deal
with it (emulating things in case of semantic differences) would lead to
suboptimal results, less programmer control and more likely to lead to
unexpected behaviour.

Don't get me wrong, I would like to see standardization in this area. I
write software that has to run on multiple platforms, and I know that it is
a real pain to get software to do compile and do the right thing on all
platforms. But the problems described above are based on experiences with
libraries that hide platform differences (with varing success).

Though I agree with you that the minimalist approach has made C and C++ to be
easily portable across platforms and extending the library would require more
work to be done by our compiler vendors. I have been reading about the
possibilities of library getting extended for quite some time and just voiced
what I felt would make life of a developer to concentrate more on standard ways
rather than deal with 3rd party or OS intricacies.

Maybe you feel more comfortable with Java (not flame, just a suggestion).

 

[Sharad Kala]

Everybody is allowed to judge other people, and one doesn't have to be
an expert to do that (at least according to my experience). This is
a public forum and I personally think one should refrain from telling
others what they should refrain from (although I don't always follow
my own advice either).

I never asked anyone not to refrain. I cannot stop anyone as you correctly
pointed out it's a public forum.
I just said that "I personally think...". I just told that one should be careful
enough while making statements
if one wants to have healthy discussions rather than ego-clashes.

other.

So what? Out of twenty-plus years I've been programming, only about
two years total I did some work involving XML. Doesn't at all speak
to XML widespread-ness, but mostly to the length of one's career, no?

XML has become popular only in recent years.
I may be near about your half age and cannot claim to say that this has been in
use for 20 yrs. But in the recent times XML has become an important form of data
exchange. There are even industry-wide protocols that are entirely XML based.
Atleast it has so happened that I have had to deal with XML in all my projects.

No, it wouldn't. Just like it wouldn't to have some kind of networking
or GUI capability.

Getting offtopic..Just the other day I helped someone with Xerces because it has
peculiarity with treating whitespaces as text nodes.
There is a transcode API that allocates memory and expects user to free it.
Point is there are so many intracacies in handling with these
3rd party libraries.

Got any statistics about that? Nope.


No. The more the compiler has to decide, the less probable it is to
have a decent compiler or a compiler that satisfies enough people for
it to be a viable product. By the time such compiler comes out, the
language will have died.

Agreed. As I said earlier too that writing thread code in a standard way would
be tricky. Thread started with what *would* be good to have in a standard
library.
But I do agree that it's a lot of work for compiler vendors.Don't think though
it's the case with XML though.

Please voice it in comp.std.c++ and see what kind of reaction you get.

"OS intricacies" are not going away any time soon, and are becoming more
and more numerous every year. How do you really expect language creators
to follow those and integrate them into the language? And (for the sake
of argument) if the Committee does catch up with OS changes and other new
technologies (like XML) popping up here and there, you would also need
compiler developers to catch up, and they cannot do it without the language
being fully defined.

The only way to standardise C++ way of treating things like network, GUI,
XML, threads, OS-specific stuff, etc., is to make them standard as well.
How long will that take and how rigid will they become?

I see your point and do agree to many extents with even what Claudio has to say.
Let me clearify here. I just meant it would have been good had there been
standard ways
to do things. Never meaning that it *should* be the case or that there are no
issues with extending the library.

 

[Sharad Kala]

other.

Your experience is not necessarilly representative for the rest of the
world. The majority of projects I have done many projects that didn't
involve XML. What people use most is highly dependant on the kind of
projects they do and what kind of business they are in.

True..I can only voice my opinions.

I would not like to see standard C++ become as bloated as Java. I would
like to see (interface) standardization for libraries in some areas, but
not as part of the C++ standard.

Yes, there needs to be some kind of standardization if not in standard then with
3rd library interfaces.

The way I see it is best to keep the core of C++ lean and mean. The more
features that are added to core definition the less portable the language
becomes, simply because some features are not available on every
conceivable platform. For areas that tend to be domain specific I prefer to
see separate standards, rather than a single standard that covers
everything-but-the-kitchen-sink.

Yes, but what if the compiler cannot make that decision? How to overcome
conceptual differences? Often the differences are more than just different
names for functions that do the same thing. Just letting the compiler deal
with it (emulating things in case of semantic differences) would lead to
suboptimal results, less programmer control and more likely to lead to
unexpected behaviour.

Don't get me wrong, I would like to see standardization in this area. I
write software that has to run on multiple platforms, and I know that it is
a real pain to get software to do compile and do the right thing on all
platforms. But the problems described above are based on experiences with
libraries that hide platform differences (with varing success).


Maybe you feel more comfortable with Java (not flame, just a suggestion).

Not actually. C++ has been my 1st love as far as PLs go

I am aware with the issues in having a standard with everything.
When I replied to the OP I just supported the *wish* to point out the numerous
differences one has
to deal with different OS/libraries. I know that it isn't actually actually
feasible to have a standard for everything
unless one is ready to compromise with efficiency and performance.

 

[tom_usenet]

Don't want to sound cheeky, cocky or start a flame war but seems like you think
you are expert enough to judge other people. I personally think one should
refrain from it unless you like to argue much.

Most of the projects I have worked on have required XML somewhere or the other.
You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.
Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

Indeed, but the place for such standardization isn't the C++ standard,
which is already getting too big and complex.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere or the other
and then you include #ifdefs for your platform in your code because your product
runs on various platforms. Wouldn't it be good to just provide a standard way of
making the calls and let the compiler decide what to do under the hood?

Indeed - pthreads already exists, and a C++ interface would be a good
thing for standardization. I'm not at all convinced that the C++
standard is the place for that though.

Though I agree with you that the minimalist approach has made C and C++ to be
easily portable across platforms and extending the library would require more
work to be done by our compiler vendors. I have been reading about the
possibilities of library getting extended for quite some time and just voiced
what I felt would make life of a developer to concentrate more on standard ways
rather than deal with 3rd party or OS intricacies.

Standardization good; enormous, monolithic, hard-to-reach-consensus-on
C++ standard bad.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

 

[Mike Smith]

Most of the projects I have worked on have required XML somewhere or the other.

That's nice. I've been doing C and C++ development for 13 years and
I've never used XML on any professional project I've worked on. (I've
been playing with it on my own time recently.)

You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.

If you want a standard - pick one library and stick to it.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere or the other

There are many platforms that do not support threads at all. They're in
your car, your coffee maker, the thermostat in your house, etc.
"Desktop" type applications are only piece of the picture. There's a
whole embedded world out there that doesn't know from threads.

 

[Mike Smith]

I never asked anyone not to refrain. I cannot stop anyone as you correctly
pointed out it's a public forum.
I just said that "I personally think...". I just told that one should be careful
enough while making statements
if one wants to have healthy discussions rather than ego-clashes.

Or maybe you could just grow a thicket skin, and not let yourself be led

XML has become popular only in recent years.
I may be near about your half age and cannot claim to say that this has been in
use for 20 yrs. But in the recent times XML has become an important form of data
exchange. There are even industry-wide protocols that are entirely XML based.
Atleast it has so happened that I have had to deal with XML in all my projects.

Fine. That's you. It's not true for everyone. Not everyone is even in
agreement that XML is such a great thing. There are some valid
arguments that XML is fundamentally broken, and that it doesn't live up
to its promises. If I had a nickel for every time I've heard someone
say they've come up with a brilliant idea for a data representation that
will solve all the problems of past representations... well, I'm sure
I'd have at least a buck or two.

 

[Attila Feher]

Don't want to sound cheeky, cocky or start a flame war but seems like
you think you are expert enough to judge other people. I personally
think one should refrain from it unless you like to argue much.

It is not a question of being an expert or not. I happen to sit at the
committee meetings (I say at and not in/on because I am an observer only) so
I can tell you: It seems so that it is not going to happen that you get XML
support into ISO C++ itself. However, since XML *is* a standard and C++ has
a standard there is no problem in creating a sort of binding. But - I am
afraid - that first such library has to be made, I do not think that an XML
library entirely designed by a committee would make you any happier than the
existing ones.

Most of the projects I have worked on have required XML somewhere or
the other. You need to resort to 3rd party libraries like
Xerces/MSXML etc and their intricacies each time you switch to a new
library.
Wouldn't be good if there was a standard way to write the code and it
would have been portable too.

Then again, if you so much want XML support into C++ and work out one! The
point is, what some people cannot always get, that C++ is standardized in
these committee meetings. It is not a visionary shop as such. While with
C++ it has some of the latter, it is still a place where users of the
language and vendors of the language related tools gather together to
standardize existing practice. So if you want an XML library, you will need
to propose one.

I know writing programs involving threads in a standard way is
tricky, owing to OS differences.

Yeah. You know where is it the most trickier? On those OSes/platforms,
where there is no threading and it does not make sense either.

But now that most of the major projects require threads somewhere or
the other and then you include #ifdefs for your platform in your code
because your product runs on various platforms.

We make a quite large threaded application. Handling video calls and other
kind of magic. You cannot find *one* ifdef in the code due to threading.

Wouldn't it be good
to just provide a standard way of making the calls and let the
compiler decide what to do under the hood?

It is called POSIX threads.

Though I agree with you that the minimalist approach has made C and
C++ to be easily portable across platforms and extending the library
would require more work to be done by our compiler vendors. I have
been reading about the possibilities of library getting extended for
quite some time and just voiced what I felt would make life of a
developer to concentrate more on standard ways rather than deal with
3rd party or OS intricacies.

While these might be all well true and frustrating for you, none of the
above matters in my work. This is no attack. Simply you have to
understand that the standardization process is not a restaurant, where you
order, and the waiter brings you a standard XML library, or C++ threading.
So if you need these, you need to either make proposals yourself (preferably
with a working, existing practice behind) or start kicking your
compiler/library vendors to come up with one and standardize it.

And I have to agree with Claudio, that you have a rather naive view of this
process. Which I had as well, before people put me to my place. You
seem to think that there is the committee, all mighty, and what he says
shall happen, and him and only him governs the future of C++ and what the
vendors will actually implement. It is quite the other way around. The
committee is mainly made from those guyss writing compilers. So they decide
what will be made. And they decide based on both technical data and
customer demand. So you need to demand XML and threading from the guys
providing you with the C++ compiler and library. Or come up with a
solution. I guess the former is easier.

 

[Attila Feher]

tom_usenet wrote:
[SNIP]

Standardization good; enormous, monolithic, hard-to-reach-consensus-on
C++ standard bad.

And The Committee said, "Let there be thread support!"; and there was thread
support. And The Committee saw that the thread support was good; by 5 voting
strongly in favour, 4 weakly in favour, 2 weakly against and one strongly
against. ;-)

 

[Chris Theis]

[SNIP]
I am aware with the issues in having a standard with everything.
When I replied to the OP I just supported the *wish* to point out the numerous
differences one has
to deal with different OS/libraries. I know that it isn't actually actually
feasible to have a standard for everything
unless one is ready to compromise with efficiency and performance.

IMHO one has to keep in mind that the C++ standard deals with language
specific issues, whereas 3rd party libraries are solution oriented. Thus,
standardization of the language should not be intermixed with incorporating
APIs or libraries that are meant to facilitate the developer's life (be it
XML, or any kind of GUI, or any file format). This of course doesn't mean
that standardization is not of concern for these "helpers", but it must be
done seperately. Otherwise, one day we will end up with a standard (probably
requiring a whole library) which covers everything and can be used for
nothing.

Cheers
Chris

 

[Attila Feher]

[SNIP]
I am aware with the issues in having a standard with everything.
When I replied to the OP I just supported the *wish* to point out
the numerous differences one has
to deal with different OS/libraries. I know that it isn't actually
actually feasible to have a standard for everything
unless one is ready to compromise with efficiency and performance.

IMHO one has to keep in mind that the C++ standard deals with language
specific issues, whereas 3rd party libraries are solution oriented.
Thus, standardization of the language should not be intermixed with
incorporating APIs or libraries that are meant to facilitate the
developer's life (be it XML, or any kind of GUI, or any file format).
This of course doesn't mean that standardization is not of concern
for these "helpers", but it must be done seperately. Otherwise, one
day we will end up with a standard (probably requiring a whole
library) which covers everything and can be used for nothing.

Actually I was thinking a bit (did not get far with it) if it would make
*some* sense at least (enough to think more about) to make a study, helping
library implementors to make good libraries. Something along the lines of
the C++ Performance TR. Of course, this could only cover some guidelines
and such...

Another possible thing is to create official ways of creating bindings (for
sort of optional things). I mean the official kind of part of it. To
ensure that bindings will not just go against the original language, I mean
that WG21/J16 will have ways to contribute/audit/comment...

Along the same lines a technical report could be done on acceptable binding
techniques...

If those has been done already, we would have less hassle now with the
C++/CLI binding. I guess.

 

[Sharad Kala]

And I have to agree with Claudio, that you have a rather naive view of this

process. Which I had as well, before people put me to my place. You
seem to think that there is the committee, all mighty, and what he says
shall happen, and him and only him governs the future of C++ and what the
vendors will actually implement. It is quite the other way around. The
committee is mainly made from those guyss writing compilers. So they decide
what will be made. And they decide based on both technical data and
customer demand. So you need to demand XML and threading from the guys
providing you with the C++ compiler and library. Or come up with a
solution. I guess the former is easier.

Thanks Attila for giving that insight into how the C++ committee works.
Yes, I do agree with you that given the facts you presented it's not right
to think about standradizations for these *helper* classes in the standard.

Personally I do not credit/value myself at all for knowing things like MFC,
Xerces,
MSXML, Winsocks etc (I don't mention pthreads here ;-)) Because I know these
would have
little value if my project demanded me to use some other 3rd party/OS and I
would need
to re-learn everything again. But I guess it is the case with most of us. What
is _always_ going
to help me is some of the good literature by Meyers, Sutter, Alexandrescu,
Josuttis, GoF etc.
People agree that C++ standard is getting large and complex. So can't there be
a way to keep things
simple somewhere ( i mean these helper classes)? I don't mean that it's very
tough to handle them but
let there be some convergence somewhere. Let people focus more on the *core*
language rather than
some unique peculiarity/intricacy which doesn't actually value much in the long
run.
Ofcourse this is my personal opinion ;-)
Even if there were some implementation standardization across these helper
classes, who is going to mandate them?

I agree with you that may be I don't understand the issues with standardization
quite well
I can relate to your points and really like the way you have put them across.
But sorry to say but I think that may be some of us don't actually phrase
ourself quite good here.

Best regards,
Sharad

 

[Ruediger Knoerig]

Although I generally support the attitude of a minimalistic but unbound
language (which can doom a language to die with the techniques integrated)
There should be extensions to the standard library (_not_ the language
itself!) for these purposes (threads, XML). The argument that some
plattforms doesn't have threads and thread support is not so a strong point
since C++ supports floating points despite of the fact that there are still
machines without floating-point support out there. The impact of such
extensions is still "experiable" when you use Trolltech's Qt library
(www.trolltech.com). Some people state that they couldn't imagine C++
without Qt no longer. And Qt promises to provide the support you need for
real cross-plattform programming with C++ power. If you look at the thread
classes in Qt you see that it wouldn't provide full support for all
features you have on different plattforms - but finally you can write
threaded programs cross-plattform with a unified interface thus starting to
use threads! IMHO that's the point - nothing else.

 

[Ruediger Knoerig]

Did you have had a look at Trolltech's Qt?
www.trolltech.com
It may became a nearly-by-standard since it's very intuitive.