C++ standards committee looking at adding Cairo to the C++ standard

S

Stefan Ram

Paavo Helde said:
problem with GUI frameworks etc. is that they really cannot be
standardized.

Yes we can! Of course, we need some abstraction!

Abstraction means: define the abstract GUI components, like
»root window«, »menu« in C++, but leave it to the implementation
how to actually implement them, how they look like.

The C++ program must not contain references to specific
colors or pixel locations. A menu might be a one-dimensional
list of texts in one device, two dimensional list of symbols
in another device. The C++ program does not know this.

The implementation chooses a safe default for the look
(colors, dimensions, fonts) and might allow style
customizations of the GUI via means not defined in the
standard (eg using a DSL). A C++ GUI program will still be
usable without any such customizations even though it might
have a not very exciting »standard appearance«.

Ten years ago, I published this text:

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en

(the first part of the text on this web page was posted to
comp.std.c++ on 2003-09-03).
 
Ö

Öö Tiib

It appears that Herb Sutter wants to add a 2D drawing library to the C++
standard, and he is looking at libCairo as a base for this library.

Not only libCairo. The group of development of C++ graphics API is:
https://groups.google.com/a/isocpp.org/forum/#!forum/graphics
The link to the Cairo's mailing list:
http://lists.cairographics.org/archives/cairo/2013-December/024858.html

What are your thoughts on this?

The future of anything depends heavily on first impressions it leaves.
Console ... that is rather unimpressive. It is easier to attract and
to teach C++ to kids when there is graphics API present right out of
the box.
 
A

Alf P. Steinbach

The future of anything depends heavily on first impressions it leaves.
Console ... that is rather unimpressive. It is easier to attract and
to teach C++ to kids when there is graphics API present right out of
the box.

But I think Cairo may be too complex, too heavy, for kids.

Not that C++ isn't -- but tonight I saw a question from a 9-year old
on Stack Overflow, and he claimed to already have written a 4000+ lines
C++ program. I didn't write a program of that many lines until college
(but then, computers weren't available at all until high school).

I think the first one of that size that I made was "RealCalc", a general
expression evaluator with naming and graphing of formulas, written in
Pascal. I remember how nice it felt to demonstrate it to someone, doing
some electronic circuit simulation, yay, works! And what a down-trip it
was to discover that the way that I'd been passing files around as
arguments, was not supported by the language, like today's C++ formal
UB, only worse because it wasn't even meaningful enough to possibly
/could/ have been supported, it just worked by a fluke...


Cheers,

- Alf
 
Ö

Öö Tiib

But I think Cairo may be too complex, too heavy, for kids.

I meant "for kids" not in literal sense but for anyone who is not
too experienced and tries C++.

I am unsure if there is plan that Cairo will be standardized. Cairo
is C library AFAIK. More likely they want to take Cairomm (or OFX
or Cinder) and evolve (and strip) some immediate mode graphics
library prototype out of it.

The immediate mode graphics are less used, less likely evolved,
easier to understand for novices but have more various libs.
Retained mode graphics have DirectX and OpenGL and it is
unlikely that hardware vendors want to support something more.
Not that C++ isn't -- but tonight I saw a question from a 9-year old
on Stack Overflow, and he claimed to already have written a 4000+ lines
C++ program. I didn't write a program of that many lines until college
(but then, computers weren't available at all until high school).

Yes, times change. Most kids know the touch-pad gestures better than
me. I also started with simple languages Basic and then Pascal as kid,
don't remember line counts but the printouts were long. :)
I think the first one of that size that I made was "RealCalc", a general
expression evaluator with naming and graphing of formulas, written in
Pascal. I remember how nice it felt to demonstrate it to someone, doing
some electronic circuit simulation, yay, works! And what a down-trip it
was to discover that the way that I'd been passing files around as
arguments, was not supported by the language, like today's C++ formal
UB, only worse because it wasn't even meaningful enough to possibly
/could/ have been supported, it just worked by a fluke...

I was young man when I first tried C (horror) and then C++ (also
shock). Translating, assembling and linking took ages, terrible
diagnostics, most errors were left undiagnosed. Graphics were
supported by language in Basic and (Turbo) Pascal already back
then. C++ had nothing. I basically had to learn how VGA card
and dot matrix printer work on low level to produce graphs.
About same was with mouse.

Modern day is other way around ... there are number of libraries
to choose. That might be even harder for novice than the *nothing*
that I had. Something accepted by committee, no matter if as C++
standard, as separate standard, as technical specification or as
technical report would be good thing.
 
R

Rui Maciel

Öö Tiib said:
The future of anything depends heavily on first impressions it leaves.
Console ... that is rather unimpressive.

I don't believe that's relevant at all. Just because something isn't included in the standard
it doesn't mean it doesn't exist.


Rui Maciel
 
R

Rui Maciel

Paavo said:
It would be a major relief if things like SVG rendering could be done
cross-platform and with standard tools.

Is it really necessary to standardize those tools throught the C++ standard?


Rui Maciel
 
Ö

Öö Tiib

I don't believe that's relevant at all. Just because something isn't
included in the standard it doesn't mean it doesn't exist.

I do not understand. Are you saying that first impression is irrelevant?
My point was that C++ toolset leaves sad first impression as state of art.
C++ standard is guideline for people writing C++ compilers and standard
library implementations so it has everything to do with improving that
toolset.
 
S

Stefan Ram

Öö Tiib said:
C++ standard is guideline for people writing C++ compilers and standard
library implementations so it has everything to do with improving that
toolset.

I am giving classes in Java and C++. I try to stay focussed,
on-topic in these classes. So I do teach what is part of the
standard ISO C++ and standard Java SE / JDK.

Teaching Java SE, I can teach how to write JavaDoc, because
this is part of the standard JDK. C++ does not have a
standard for documentation comments, although there is
Doxygen. Contracts are essential for modern programming, and
contracts of classes and functions are being described in
the documentation. So it is good when a language supports this.

Teaching Swing in Java is great as a motivation to learn
Java and OOP in Java. People want to write GUI programs and
they can see that they absolutely need to learn OOP to do
this in Java. There are not licensing issues that I am aware of.

In C++, I cannot teach GUIs because that would be off-topic
in a C++ class. A GUI does not belong to the standard C++.
Sometimes people try to teach OOP in C++ with »class cow :
public animal { public void sound(){ ::std::cout << "moe\n"
...«, but students are annoyed by such examples, possibly
they feel to be treated like children, because the topic of
animal sounds usually is treated in daycare facilities for
children. And what's the point of a shape array with
circles and rectangles, when one then cannot paint the shapes?

I myself would not mind to teach C++ in a more abstract
manner. But at least some students seem to like to see some
GUI or graphics sometimes. If C++ would have gotten a
standard interface for sockets, GUI, doc comments, XML, and
all these things 10 years ago, it would be more important
today. But instead, on TIOBE it dropped from rank 2 in 1994
to rank 3 in 2009 and now to rank 4 in 2014 (in spite of the
new 2011 standard!). This is sad, it is a wasted opportunity.
 
S

see.my.homepage

I am giving classes in Java and C++. I try to stay focussed,
on-topic in these classes. So I do teach what is part of the
standard ISO C++ and standard Java SE / JDK.

Sorry, but even though I'm positive about adding some GUI support to C++, your argument is not convincing for me.
Your "inability" to teach students GUI in C++ is a result of your strict policy of limiting yourself to the standard C++ only. This might be equivalent to saying that there is no GUI in C++, which your students can easily refute by just looking at their desktop computers - they are already using GUIapplications written in C++ (I am using such an application to write this post, for example), so obviously you have chosen not to teach them something useful. Does it make you a good teacher?

You might as well relax your strict policy and show them some Qt (or whatever) examples *today*. There is no need to wait for the std committee to putGUI in the standard library only so that you can keep your lectures "focused". I guess your students would prefer "useful" over "focused" any single day.

A side note: when I have recently shown some Qt examples to my Java colleague at work, he was literally shocked how easy it is to write GUI code in C++.
 
W

Wouter van Ooijen

I am giving classes in Java and C++. I try to stay focussed,
Your "inability" to teach students GUI in C++ is a result of your strict policy of
limiting yourself to the standard C++ only.

I teach C++ too.

Each quarter, we combine two 'theoretical' courses with one 'practical'
(project) course. My C++ course runs in parallel with a game project, so
of course I use drawble graphic objects as examples for inheritance. For
the assignments I provide a library for drawing such objects. That
library itself is not a subject of the C++ course, but its interface,
and creating drawable objects with it, sure is. It does not matter much
which library I use, the important aspects are inheritance and (virtual)
overloading.

Restrict yourself to the C++ standard does not mean you can't use a real
library! Just focus on the interface.

Wouter van Ooijen
 
J

Jorgen Grahn

.
I am giving classes in Java and C++. I try to stay focussed,
on-topic in these classes. So I do teach what is part of the
standard ISO C++ and standard Java SE / JDK.

Teaching Java SE, I can teach how to write JavaDoc, because
this is part of the standard JDK. C++ does not have a
standard for documentation comments, although there is
Doxygen. Contracts are essential for modern programming, and
contracts of classes and functions are being described in
the documentation. So it is good when a language supports this.

Surely this doesn't mean you don't teach your students to document at
the right level (especially since you seem to know very well)? Even
if you ignore Doxygen, there are still /* */ and // so it's not as if
you cannot document your code in ISO C++.

....

For the rest, I just agree with the others who responded.

/Jorgen
 
W

woodbrian77

Sorry, but even though I'm positive about adding some GUI support to C++, your argument is not convincing for me.

+1

When it comes to the standard, I keep this in mind:
"The stone which the builders rejected has become
the chief corner stone." Psalm 118:22

Iow, the C++ standard committee gets trumped here
and there. What's in the standard is often inferior
to alternatives outside the standard.


Brian
Ebenezer Enterprises - Heavenly code coming down
from the cloud.
http://webEbenezer.net
 
I

Ian Collins

Stefan said:
I am giving classes in Java and C++. I try to stay focussed,
on-topic in these classes. So I do teach what is part of the
standard ISO C++ and standard Java SE / JDK.

Teaching Java SE, I can teach how to write JavaDoc, because
this is part of the standard JDK. C++ does not have a
standard for documentation comments, although there is
Doxygen. Contracts are essential for modern programming, and
contracts of classes and functions are being described in
the documentation. So it is good when a language supports this.

Which can be unit tests, which C++ certainly does support.
Teaching Swing in Java is great as a motivation to learn
Java and OOP in Java. People want to write GUI programs and
they can see that they absolutely need to learn OOP to do
this in Java. There are not licensing issues that I am aware of.

In C++, I cannot teach GUIs because that would be off-topic
in a C++ class. A GUI does not belong to the standard C++.

Teach them how things are done in the real world: pick a library and use it.

I never hear people complaining that they can't teach Python or PHP
because those languages lack a standard GUI.
 
S

Stefan Ram

What's in the standard is often inferior
to alternatives outside the standard.

In the C++ standard, we have containers, algorithms,
an input/output library, a regular expressions library,
and more. What is there outside the standard to which
these are clearly inferior?
 
S

Stefan Ram

Ian Collins said:
Which can be unit tests, which C++ certainly does support.

There are contracts that cannot be expressed as unit tests.
For example, we might require that »for all int values i:
0 <= f( i )< 100«. Unit tests can express random examinations
of this, but they cannot directly express a universal quantification
over a very large set.

Unit tests are great! But even in Java, they do not /replace/
the contracts in the JavaDoc, but are /added/ to them.
Teach them how things are done in the real world: pick a library and use it.

What works in the real world does not always work in the
classroom. First, it does not even always work in the real
world (many software project fail, are cancelled, or overdue).
Next, the classes are already much too short to teach most
of what is in the standard C++, so they only teach a selection.
Teaching a »picked library« means that there will be even
less time to teach C++ proper. While some students might
like this, others might be alienated by it.
 
W

Wouter van Ooijen

Teach them how things are done in the real world: pick a library and use it.
Teaching a »picked library« means that there will be even
less time to teach C++ proper. While some students might
like this, others might be alienated by it.

The suggestion is not to tceah a library, but to take your examples from
the use of the library. With a little added effort you can use the
library in the assignments.

Wouter
 
W

woodbrian77

In the C++ standard, we have containers, algorithms,
an input/output library, a regular expressions library,
and more. What is there outside the standard to which
these are clearly inferior?


Rather than using map, I suggest one of these:
http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive.html

Leigh's segmented arrays are better than deque:
i42.co.uk/stuff/segmented_array.htm

Using Boost Multi_index is better than using multiple
standard containers:
http://www.boost.org/doc/libs/1_55_0/libs/multi_index/doc/index.html
 
I

Ian Collins

Wouter said:
The suggestion is not to tceah a library, but to take your examples from
the use of the library. With a little added effort you can use the
library in the assignments.

That's correct. I can't see how adding something to the standard makes
it easier to teach. Whether a widget is a std::widget or one from a
library, it is still a widget.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top