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?

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