What's about the future of C++?

[VirtualDev]

What is the future of C++?, and what is the C++0x? and is it really
going to include a standard portable libraries for GUI, networking,
embedded systems and so on?

[Roland Pibinger]

On 31 May 2006 03:17:34 -0700, "VirtualDev" <aq*****@gmail.com> wrote:

What is the future of C++?, and what is the C++0x? and is it really
going to include a standard portable libraries for GUI, networking,
embedded systems and so on?

Don't expect anything from new standards. Often a new standard makes
the language (any language) and the environment more complicated and
less tangible for users. Better try to understand the core concepts of
programming in general and the tried C++ idioms in particular.

Best wishes,
Roland Pibinger

[Olex]

VirtualDev wrote:

What is the future of C++?, and what is the C++0x? and is it really
going to include a standard portable libraries for GUI, networking,
embedded systems and so on?
Well, one thing you can count for, is that some parts of boost C++
library are going to make it in.From http://www.boost.org/ We aim to establish "existing practice" and provide reference implementations so that Boost
libraries are suitable for eventual standardization. Ten Boost libraries are already included in the
C++ Standards Committee's Library Technical Report ( TR1) as a step toward becoming part of
a future C++ Standard. More Boost libraries are proposed for the upcoming TR2.

[Earl Purple]

VirtualDev wrote:

What is the future of C++?, and what is the C++0x? and is it really
going to include a standard portable libraries for GUI, networking,
embedded systems and so on?

None of these libraries. There will be some syntactic changes to allow,
for example vector<vector<int>> without a space between the closing .>
characters.

You will be allowed to define a type as auto when the compiler can
deduce what type you want. So

auto myIter = myMap.find( "hello" );

instead of having to churn through templates to define the iterator.
(Ever tried it with equal_range?)

Not sure if they will allow template typedefs - they might, I know Herb
Sutter wants them.

Library additions will go include the shared_ptr and scoped_ptr from
boost. Not sure about any of their other libraries. (Others can fill me
in). Would be nice to see bind in there, although some would propose
some language changes to aid that.

That a library is not in the standard does not stop you using it. There
are loads of open-source libraries that are in common use but not
standard. And they're not all in boost.

[Luke Meyers]

Roland Pibinger wrote:

On 31 May 2006 03:17:34 -0700, "VirtualDev" <aq*****@gmail.com> wrote:

What is the future of C++?, and what is the C++0x? and is it really
going to include a standard portable libraries for GUI, networking,
embedded systems and so on?

Don't expect anything from new standards. Often a new standard makes
the language (any language) and the environment more complicated and
less tangible for users.

Not that this isn't true in many cases, but unless you feel that this
applies specifically to C++0x (there is public information available on
it), I think it does a disservice to the work of the good people on the
standards committee and in working groups to dismiss it so offhandedly.

Not every new standard is about adding flashy new crap. This ain't
Java, kiddies.

Luke

[homsan toft]

VirtualDev wrote:

What is the future of C++?,
Probably busy.
and what is the C++0x?
An updated standard that they hope to finish before 2010.
There are several groups working on various parts of it, see
http://www.open-std.org/jtc1/sc22/wg...s/papers/2006/
for a bunch of proposals in various stage of processing,
and notes on how the various groups are doing.

Paper N2009 is a PDF with the draft version of the standard.
and is it really going to include a standard portable libraries
Yes, several. Filesystem, Regex and others are already accepted.
See the draft standard, and various "TR2" and "TR3" proposals
(TR for "Technical Report")
for GUI,
No, probably not.
networking,
One design was recently accepted into Boost after review. http://boost.org
Not yet released, but may be in next release (in a month or two?)
A library in Boost is often accepted as, or an influence on a later standard proposal.
But they are distinct, several Boost libraries would never go into the standard,
they're just good useful libraries.
embedded systems and so on?

See http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
esp the "final draft" http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

It contains several discussions on performance, and some headers that
define types (structs and enums etc) which would allow processor-specific
and other system-specific features to be described in a standard notation.
Eg endianness, bus data width, maybe some port mapping etc etc.

This would be useful both for writing drivers etc for similar but distinct systems,
and for library code - eg when processing various binary file formats.
homsan

[Phlip]

homsan toft wrote:

An updated standard that they hope to finish before 2010.

....

for GUI,

No, probably not.

There's the slight problem of hitting a fast-moving target with a
slow-moving projectile there...

;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[benben]

Phlip wrote:

homsan toft wrote:

An updated standard that they hope to finish before 2010.

...

for GUI,

No, probably not.

There's the slight problem of hitting a fast-moving target with a
slow-moving projectile there...

;-)

Agree.

On the other hand we can imagine what a standard GUI library would be
like. My guess is much of a compromise since we all want (don't deny)
those fancy platform dependent sweeties, don't we?

Ben

[kwikius]

Phlip wrote:

homsan toft wrote:

An updated standard that they hope to finish before 2010.

...

for GUI,

No, probably not.

There's the slight problem of hitting a fast-moving target with a
slow-moving projectile there...

;-)

Which major parts of GUI technology are moving so fast? Is the current
point and click widget on desktop metaphor going to be redundant. Will
we all be wearing VR suits ? Au contraire the 2D desktop widget
metaphor seems to be well established across Operating systems large
and small. In fact it is now surprisingly easy to move between
operating systems with a GUI frontend, because they all work so
similarly, as has been the case for quite a few years.

regards
Andy Little

[Phlip]

benben wrote:

On the other hand we can imagine what a standard GUI library would be
like. My guess is much of a compromise since we all want (don't deny)
those fancy platform dependent sweeties, don't we?

I can imagine auditioning a new program, growing disgusted with its
restricted and primitive look and feel, and rejecting it as "just another of
those crappy C++ GUIs!"

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Earl Purple]

kwikius wrote:

Which major parts of GUI technology are moving so fast? Is the current
point and click widget on desktop metaphor going to be redundant. Will
we all be wearing VR suits ? Au contraire the 2D desktop widget
metaphor seems to be well established across Operating systems large
and small. In fact it is now surprisingly easy to move between
operating systems with a GUI frontend, because they all work so
similarly, as has been the case for quite a few years.

I agree that a standard GUI would not need to cover all of GUI. I would
like a standard GUI interface. It would then be up to the implementers
how they implement it for whichever platform.

[Victor Bazarov]

Earl Purple wrote:

kwikius wrote:

Which major parts of GUI technology are moving so fast? Is the
current point and click widget on desktop metaphor going to be
redundant. Will we all be wearing VR suits ? Au contraire the 2D
desktop widget metaphor seems to be well established across
Operating systems large and small. In fact it is now surprisingly
easy to move between operating systems with a GUI frontend, because
they all work so similarly, as has been the case for quite a few
years.

I agree that a standard GUI would not need to cover all of GUI. I
would like a standard GUI interface. It would then be up to the
implementers how they implement it for whichever platform.

I just wonder how long do you think it would take the Committee to
agree on a single specification, given that now there are so many
different ones on the market... And who's going to write it? By
the time the specification is agreed upon and written up, the GUI
development (with new bells and whistles like handwriting recognition
and other tricks introduced annually) will have left the spec so far
in the past that implementing the Standard set will be so not enough
to satisfy anybody, that nobody would care... Just the impression I
get, anyway.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

Earl Purple wrote:

I agree that a standard GUI would not need to cover all of GUI. I would
like a standard GUI interface. It would then be up to the implementers
how they implement it for whichever platform.
Note that our industry relies on competition, and "because it's Standard"
does not automatically win. If I had to choose between The Standard C++ GUI,
and Brand X, I would pick the one less liable to change uncontrollably when
I port it to another platform.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[homsan toft]

kwikius wrote:

Phlip wrote:

homsan toft wrote:

An updated standard that they hope to finish before 2010.

...

for GUI,

No, probably not.

There's the slight problem of hitting a fast-moving target with a
slow-moving projectile there...

;-)

Which major parts of GUI technology are moving so fast?

Guis are new in the computing world, compared with eg filesystems.
The basic features and uses have hardly stabilized yet.

The common features of Mac, Windows, java and web forms are
beginning to form a kind of useful core that isn't *just* minimal.
But there are still parts that may be useful to everyone but have few
widely-used implementations to look at or submit - no standard spreadsheet
component and only a few tree displays.
Fonts are available for each system, but work quite differently
.... etc

Also, some infrastructure that shouldn't be provided just for the gui library
is not in place - eg no signals in c++ yet.

Then, for a successful submission someone usually picks up from experience of
widely used implementations, and provides something with a leap of usefulness
and generalization (stepanov with STL, boost'ed libraries like regex...)
This just hasn't happened yet for guis, but maybe it does sometime within the decade.
(not in time for c++0x though, unless 0x is the hexadecimal prefix)

There's a big discussion on boost list once or twice a year, someone starts a
proof of concept implementation, then it bogs down because there's absolutely
no agreement on the problem to solve, scope of solution or even basics of
2D points...

homsan

[Earl Purple]

Victor Bazarov wrote:

I just wonder how long do you think it would take the Committee to
agree on a single specification, given that now there are so many
different ones on the market... And who's going to write it?
Volunteers, I would imagine. But the implementation would hopefully
only require adapters to the various libraries on the market.
By the time the specification is agreed upon and written up, the GUI
development (with new bells and whistles like handwriting recognition
and other tricks introduced annually) will have left the spec so far
in the past that implementing the Standard set will be so not enough
to satisfy anybody, that nobody would care... Just the impression I
get, anyway.

The impression I get is that C++ is still back in the early 80s with
console applications and is scared to progress in case they do so in a
way that is not perfect. With that in mind they wouldn't have given us
STL because that is not perfect - there are many things not so great
about STL but it's still better than not having it.

Platforms where GUI is not appropriate simply would not use the
library. In the same way that you could have platforms with no console
and thus not use console functions.

Those who have implemented GUI will not be out of work - as even
standard GUI will still need implementations (just like Roguewave were
not out of work when STL came along). And as I said earlier, the
current libraries could probably be used to implement the standard
interfaces anyway.

[Earl Purple]

Phlip wrote:

Note that our industry relies on competition, and "because it's Standard"
does not automatically win. If I had to choose between The Standard C++ GUI,
and Brand X, I would pick the one less liable to change uncontrollably when
I port it to another platform.

I would pick the one where I wouldn't need to change all my client code
because I wanted to change the library implementation.

So my client could use standard GUI and then we could change from Brand
X on Windows to Brand Y on Linux and Brand Z on the apple mac without
having to change any client code.

[Victor Bazarov]

Earl Purple wrote:

Phlip wrote:

Note that our industry relies on competition, and "because it's
Standard" does not automatically win. If I had to choose between The
Standard C++ GUI, and Brand X, I would pick the one less liable to
change uncontrollably when I port it to another platform.

I would pick the one where I wouldn't need to change all my client
code because I wanted to change the library implementation.

So my client could use standard GUI and then we could change from
Brand X on Windows to Brand Y on Linux and Brand Z on the apple mac
without having to change any client code.

But doesn't this simply mean that you need Product XYZ which *already*
supports all those things (and probably more), and there is no need to
have this in the Standard library? Just asking...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

Earl Purple wrote:

Victor Bazarov wrote:

I just wonder how long do you think it would take the Committee to
agree on a single specification, given that now there are so many
different ones on the market... And who's going to write it?
Volunteers, I would imagine. But the implementation would hopefully
only require adapters to the various libraries on the market.

And what is the purpose, again? If there _were_ a need to have common
GUI specification, it would have existed already. There is no sense
in trying to rush the evolution. The Standard is as much a set of rules
as it is a reflection of trends. If there were trends now towards some
kind of standard in C++ GUI, we would have seen them, no? I haven't,
have you?

And, what volunteers? Would *you* volunteer to write it up? If yes,
why haven't you yet? If no, why not? As soon as you can answer this
to yourself, maybe you can understand why this is not the time yet...

By the time the specification is agreed upon and written up, the GUI
development (with new bells and whistles like handwriting recognition
and other tricks introduced annually) will have left the spec so far
in the past that implementing the Standard set will be so not enough
to satisfy anybody, that nobody would care... Just the impression I
get, anyway.

The impression I get is that C++ is still back in the early 80s with
console applications and is scared to progress in case they do so in a
way that is not perfect. With that in mind they wouldn't have given us
STL because that is not perfect - there are many things not so great
about STL but it's still better than not having it.

Uh... Does that mean that your impression is unfounded? They *have*
given us STL *dispite* the fact that it's not perfect, haven't they?

IMNSHO C++ is not "scared to progress", but rather it has progressed
enough in the areas where it was necessary to have a Standard. And it
keeps progressing in the same fashion. GUI is simply so unstable at
this point that it is not necessary nor is it possible to devise any
common standard.
Platforms where GUI is not appropriate simply would not use the
library. In the same way that you could have platforms with no console
and thus not use console functions.
What console functions? It seems you have a wrong impression about what
the Standard Library contains at this point.
Those who have implemented GUI will not be out of work - as even
standard GUI will still need implementations (just like Roguewave were
not out of work when STL came along). And as I said earlier, the
current libraries could probably be used to implement the standard
interfaces anyway.

Roguewave? Who's that?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Earl Purple]

And what is the purpose, again?
So that GUI applications and components could be written in a
"standard" way, i.e. one piece of code for all implementations. Of
course, that would open up the big "legacy code" issue again, just like
happened when standard libraries replaced those that already existed
before them, with loads of code already written that were using
non-standard libraries.

Personally I find it easier to only have to learn one library then be
able to apply it everywhere.
If there _were_ a need to have common GUI specification, it would have existed
already. There is no sense in trying to rush the evolution.
There are common libraries and those who still choose to use C++ for
their GUI apps will use one of them. But although I haven't used them,
those that claim to be portable do not use standard C++ (std::string
etc) or have the STL feel to it. Of course, it will help once
shared_ptr becomes part of the standard.
The Standard is as much a set of rules
as it is a reflection of trends. If there were trends now towards some
kind of standard in C++ GUI, we would have seen them, no? I haven't,
have you?
The only trend I have seen is for GUI to move away from C++ entirely
into other languages, often Java because it has standard GUI. I
wouldn't know that well because I haven't developed GUI now for several
years, and when I did I used MFC and then WTL, and didn't particularly
like either of them. MFC had serious flaws which made it hard to use.
And, what volunteers? Would *you* volunteer to write it up? If yes,
why haven't you yet? If no, why not?
I would happily volunteer but there are others who are far more
qualified than myself to do so - those who work consistently in GUI,
who have used many libraries, and those who have implemented the
existing GUI libraries. If a standard were brought out, it should be
those who implement Qt and wxWidgets (as examples) and possibly even
implementers of MFC who get together and decide what the standard could
be, and then it could be proposed and peer-reviewed, or reviewed by
those who write GUI apps.
Uh... Does that mean that your impression is unfounded? They *have*
given us STL *dispite* the fact that it's not perfect, haven't they?
No, but just like in the real world where I program, if you try looking
for total perfection all the time you never develop anything.

Plus it is always possible to add new interfaces whilst retaining the
existing ones. So if they want to add new features to C++ in 2017
because of the way computing has progressed by then, they can do so
without abandoning the old ones.
IMNSHO C++ is not "scared to progress", but rather it has progressed
enough in the areas where it was necessary to have a Standard. And it
keeps progressing in the same fashion. GUI is simply so unstable at
this point that it is not necessary nor is it possible to devise any
common standard.
Actually I'm pretty certain there is a GUI standard somewhere. That is
why most GUI applications you use have a common feel to them. There is
a general concept of a menu, of buttons that respond to mouse-clicks,
of pop-up dialogs...
What console functions? It seems you have a wrong impression about what
the Standard Library contains at this point.

std::cout is part of the standard, isn't it? And even printf is still
there inherited from C.

[Earl Purple]

Victor Bazarov wrote:

But doesn't this simply mean that you need Product XYZ which *already*
supports all those things (and probably more), and there is no need to
have this in the Standard library? Just asking...

But they won't all support it with the same API. Common API, different
implementations.

Of course, for those things that the standard won't support, you'll
still need other libraries. If the standard supports enough for 80% of
apps that have a GUI content not to use library-specifics, it would be
worthwhile having one.

[Sgt. York]

Earl Purple wrote:

Those who have implemented GUI will not be out of work - as even
standard GUI will still need implementations (just like Roguewave were
not out of work when STL came along). And as I said earlier, the
current libraries could probably be used to implement the standard
interfaces anyway.

Just a small point, I can tell you first-hand that Rogue Wavers were in
fact put out of work as the STL came along and matured.

-York

[Victor Bazarov]

Earl Purple wrote:

[..in response to my questions..]

What console functions? It seems you have a wrong impression about
what
the Standard Library contains at this point.

std::cout is part of the standard, isn't it? And even printf is still
there inherited from C.

Yes, and what relationship to console do they have? Is that because
_your_ OS associates the console with the standard out? It has nothing
to do with the language or the library.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[kwikius]

homsan toft wrote:

kwikius wrote:

Which major parts of GUI technology are moving so fast?

Guis are new in the computing world, compared with eg filesystems.
The basic features and uses have hardly stabilized yet.

Apparently GUI has been around in some shape or form since the 1950's.

http://www.macos.utah.edu/Documentat...sxone/gui.html

What is striking is how little we have moved on. See Xerox Star in the
above link.

Also interesting Wiki:
http://en.wikipedia.org/wiki/History_of_the_GUI
The common features of Mac, Windows, java and web forms are
beginning to form a kind of useful core that isn't *just* minimal.
But there are still parts that may be useful to everyone but have few
widely-used implementations to look at or submit - no standard spreadsheet
component and only a few tree displays.
Having recently installed Fedora Linux I was amused at the similarity
between OpenOffice Calc Spreadsheet App and Microsoft Excel.

The Web influence is a good point however. Browsers are a (relatively)
platformless GUI. Also intersting is XUL:

http://xulplanet.com/tutorials/whyxul.html

though I havent gone that far into it yet.
Fonts are available for each system, but work quite differently
... etc
Though the interface for user to pick a font is often quite uniform
AFAICS and that is what this is about really, a common interface. There
are parallels to e.g picture/graphics formats. Many file formats
translated to one screen format.
Also, some infrastructure that shouldn't be provided just for the gui library
is not in place - eg no signals in c++ yet.

Then, for a successful submission someone usually picks up from experience of
widely used implementations, and provides something with a leap of usefulness
and generalization (stepanov with STL, boost'ed libraries like regex...)
This just hasn't happened yet for guis, but maybe it does sometime within the decade.
(not in time for c++0x though, unless 0x is the hexadecimal prefix)
Sure. If it happens it wont happen soon and will not happen by magic,
but that is no reason to give up on it.
There's a big discussion on boost list once or twice a year, someone starts a
proof of concept implementation, then it bogs down because there's absolutely
no agreement on the problem to solve, scope of solution or even basics of
2D points...

The discussions on Boost may have died but again its no reason to give
up on the goal of having a standardised C++ GUI AFAICS.

regards
Andy Little

[homsan toft]

kwikius wrote:

homsan toft wrote:

Guis are new in the computing world, compared with eg filesystems.
The basic features and uses have hardly stabilized yet.
Apparently GUI has been around in some shape or form since the 1950's.

Also interesting Wiki:
http://en.wikipedia.org/wiki/History_of_the_GUI
So there. Filesystem may be bad comparison - but programming in recognizable form
goes back to 19th c - it still makes GUIs "relatively recent" in some sense.

The common features of Mac, Windows, java and web forms are
beginning to form a kind of useful core that isn't *just* minimal. Having recently installed Fedora Linux I was amused at the similarity
between OpenOffice Calc Spreadsheet App and Microsoft Excel.
That's because StarOffice (the base for O-O) was a direct clone that purposely
tried to match most of Microsoft Office feature by feature - and was good at it.
See http://wikipedia.org/OpenOffice
The Web influence is a good point however. Browsers are a (relatively)
platformless GUI. Also interesting is XUL: http://xulplanet.com/tutorials/whyxul.html
As is Qt, FLTK and the UI toolkit of OpenOffice.

I like the 6-line C++ API of a Flash gui - http://codeproject.com/useritems/FlashGui.asp
Event I/O takes another couple of dozen lines.
Then Flash programmers can do all the interaction and graphics,
and let C++ programmers work with algorithms.
Doesn't quite cut it for standardization of course, but a rad approach.
Then, for a successful submission someone usually picks up from experience of
widely used implementations, and provides something with a leap of usefulness

Sure. If it happens it wont happen soon and will not happen by magic,
but that is no reason to give up on it.

No notion of giving up, just telling the OP that it likely won't be in next standard version.
Regards,

homsan

[Victor Bazarov]

Earl Purple wrote:

Victor Bazarov wrote:

But doesn't this simply mean that you need Product XYZ which
*already* supports all those things (and probably more), and there
is no need to have this in the Standard library? Just asking...
But they won't all support it with the same API. Common API, different
implementations.

Who they? I am saying "Product XYZ" (as in "a single product"), and
please don't ask me to name any examples, so common API is *already*
at your disposal.
Of course, for those things that the standard won't support, you'll
still need other libraries. If the standard supports enough for 80% of
apps that have a GUI content not to use library-specifics, it would be
worthwhile having one.

Oh, yes... Of course. Meanwhile we'll complain about something else
that doesn't exist in the standard, like programming of tactile
interfaces or genome manipulation or ...

[Alf P. Steinbach]

* kwikius:

Phlip wrote:

homsan toft wrote:

An updated standard that they hope to finish before 2010.

...

for GUI,
No, probably not.

There's the slight problem of hitting a fast-moving target with a
slow-moving projectile there...

;-)

Which major parts of GUI technology are moving so fast?

Depends what you mean by "fast".

The last ten years we have seen a major shift from procedural to
declarative GUI design, separating the visual aspects as XML (e.g.
Mozilla's XUL and Microsoft's XAML).

This means a C++ GUI framework for 2008 and a few years onward, should
better not be concerned with how to e.g. create buttons, but only with
how to react to button events (or perhaps at a higher level of
abstraction, user commands) and establish the connection from XML to C++
code.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Phlip]

homsan toft wrote:

So there. Filesystem may be bad comparison - but programming in
recognizable form
goes back to 19th c - it still makes GUIs "relatively recent" in some
sense.
It ain't the depth of history, it's the breadth of application. The shiny
thing in your cell phone is a GUI, too.

A Standard C++ Implementation must promise to support the same purported
Standard GUI across the broadest range of platforms which have screens and
input devices. So, jack of all trades == master of none. Such a GUI wouldn't
be competitive even with a portable GUI, like wxWidgets, that supports fewer
platforms.

And by the time we have this Standard, the 3D GUI Desktop will have matured.

Now discuss how Standard C++ could support the kernel of a GUI - maybe a
message pump, windows, common widgets, a canvas, and an HTML portal - and
then support generic plug-ins. Similar to custom iterators in STL, such
platform-specific plug-ins could then host all the platform-specific
extensions, following local de-facto standards.
Doesn't quite cut it for standardization of course, but a rad approach.

Today's discovery:

http://sourceforge.net/projects/stickwiki
"Wiki on a Stick"

It's a single self-modifying HTML file containing a passable Wiki. [Only
works on FireFox, but] imagine our Standard GUI with its HTML portal hosting
such a file. Instant power-usage, in a handy portable container. Our GUI,
HTML, and Ecmascript would all be (variously) Standard, too.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Earl Purple]

Sgt. York wrote:

Just a small point, I can tell you first-hand that Rogue Wavers were in
fact put out of work as the STL came along and matured.

And a lot of us who have been writing infrastructural type c++
libraries have been made redundant by boost.

[Earl Purple]

Victor Bazarov wrote:

Oh, yes... Of course. Meanwhile we'll complain about something else
that doesn't exist in the standard, like programming of tactile
interfaces or genome manipulation or ...

like concurrent programming (threads) or networking and database
interaction? i.e. common programming paradigms?

If there's a big demand for it, why not have a standard for it? Even if
the demand for it is limited and it's added to the standard, nobody is
forced to use that part of the library, just as I rarely use locale and
never use valarray now.

[Pete Becker]

Earl Purple wrote:

Library additions will go include the shared_ptr and scoped_ptr from
boost. Not sure about any of their other libraries. (Others can fill me
in). Would be nice to see bind in there, although some would propose
some language changes to aid that.

There's no proposal for scoped_ptr. But all of TR1 except for the math
special functions is now in C++0x.

--

Pete Becker
Roundhouse Consulting, Ltd.