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]

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]

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.

 

[Earl Purple]

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]

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]

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/wg21/docs/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]

An updated standard that they hope to finish before 2010. ....

No, probably not.

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

;-)

 

[benben]

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]

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]

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!"

 

[Earl Purple]

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]

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

 

[Phlip]

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.
[/QUOTE]

 

[homsan toft]

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]

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]

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

 

[Victor Bazarov]

Victor Bazarov wrote:



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

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

 

[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]

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.