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?

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