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

[Rui Maciel]

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.

The link to the Cairo's mailing list:
http://lists.cairographics.org/archives/cairo/2013-December/024858.html


What are your thoughts on this?


Rui Maciel

[Paavo Helde]

Rui Maciel <rui.m...@gmail.com> wrote in
news:labt7p$co4$1...@dont-email.me:

It would be a major relief if things like SVG rendering could be done
cross-platform and with standard tools. Especially all the text/font
management business is currently very hairy and largely platform-
specific. About half (and the hairier half!) of third-party libraries
used by our current product are currently there for the single task of
SVG rendering, and on one platform we even gave up with this when it all
got too hairy. Libcairo is in that mix somewhere, too.

So I see it as a big step in the right direction. If something like this
can be standardized, then by all means do it! I understand the major
problem with GUI frameworks etc. is that they really cannot be
standardized.

Cheers
Paavo

[Mr Flibble]

On 05/01/2014 20:34, Stefan Ram wrote:
> Paavo Helde <myfir...@osa.pri.ee> writes: I understand the major

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

It's a bad idea as nobody can agree on the design of such abstractions
and it's a bad idea because it is something that simply shouldn't be
part of the standard C++ language.

If you are going to standardize a 2D drawing and GUI library why not
also standardize on a 3D library of which 2D is a subset? Answer: no
need to as we already have perfectly adequate libraries such as OpenGL
and SDL.

/Flibble

[Paavo Helde]

Mr Flibble <flibbleRE...@i42.co.uk> wrote in news:q-Kdnc8hO_
2oS1TPnZ2dn...@giganews.com:

> If you are going to standardize a 2D drawing and GUI library why not
> also standardize on a 3D library of which 2D is a subset? Answer: no
> need to as we already have perfectly adequate libraries such as OpenGL
> and SDL.

So, can we do (2D) SVG rendering easily with OpenGL or SDL, on any average
Windows, Mac or Linux box (no UI involved, the result would be a bitmap
image sent to the HTTP client)? If so, we would switch over instantly.

Cheers
Paavo

[Öö Tiib]

On Sunday, 5 January 2014 17:20:24 UTC+2, Rui Maciel wrote:
> 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.

[Alf P. Steinbach]

On 06.01.2014 04:18, �� Tiib wrote:
>
> 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]

On Monday, 6 January 2014 06:59:07 UTC+2, Alf P. Steinbach wrote:

> On 06.01.2014 04:18, �� Tiib wrote:
> >
> > 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.

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.

[Rui Maciel]

Öö Tiib wrote:

> 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

[Rui Maciel]

Paavo Helde wrote:

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

[see.my....@gmail.com]

> 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 GUI applications 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 put GUI 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++.

--
Maciej Sobczak * http://www.inspirel.com

[Wouter van Ooijen]

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

> 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

[Jorgen Grahn]

On Tue, 2014-01-07, Stefan Ram wrote:
...

> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[woodb...@gmail.com]

On Tuesday, January 7, 2014 9:40:09 AM UTC-6, see.my....@gmail.com wrote:
>
> 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

[Ian Collins]

Stefan Ram wrote:

> �� Tiib <oot...@hot.ee> writes:
>> 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.

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.

--
Ian Collins

[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

[Ian Collins]

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.

--
Ian Collins

[woodb...@gmail.com]

On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
>
> 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

[woodb...@gmail.com]

> 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 think val_array is not used much and there are
alternatives to it that are used more often.

[Jorgen Grahn]

On Tue, 2014-01-07, Stefan Ram wrote:

> Ian Collins <ian-...@hotmail.com> writes:

Some extra context: SR wrote:
| 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.
>

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

I don't know Java, but are unit tests useful as documentation in /any/
interesting cases? Mine turn out, in the best case, as examples which
supplement the interface documentation but are rather useless if you
don't read the latter first.

[Ian Collins]

Stefan Ram wrote:
> Ian Collins <ian-...@hotmail.com> writes:

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

> ... non-standard ...

>
>> library, it is still a widget.
>

> When something is announced as a �C++ course�, it is easier to
> teach what actually /is/ part of C++, because people expect this
> and also I myself deem this to be honest.

But you aren't teaching the library, you are using a part of it to
illustrate a concept. I assume you use a compiler in your course but
you don't consider learning how to use the compiler as part of the course.

--
Ian Collins

[Ian Collins]

In most of my projects, they are the documentation (and implementation)
step between the user stories and the code. Unlike JavaDoc style
comments, they are always up to date!

--
Ian Collins

[Jorgen Grahn]

I wonder if I would find them /useful/ as documentation too ... are
any of these projects publicly available so I could take a look?

> Unlike JavaDoc style
> comments, they are always up to date!

Yeah, well ... I don't understand what's so hard about keeping
documentation up to date. I frequently see people let it slip, and I
cannot figure out why. Incompetence? Mine is always up to date, but
that's because I write it to /use/ it. If I was forced to write
meaningless or superfluous documentation ("void foo() is a function
called foo which returns nothing") that would be a different issue.

[Mr Flibble]

On 07/01/2014 22:31, woodb...@gmail.com wrote:
> On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
>>
>> 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

My segmented_array container is not /better/ than deque it is just
/different/; it has different performance and invalidation
characteristics for certain operations compared with vector, deque *and*
list.

I plan on improving segmented_array by making a change that should turn
it into an ultimate general purpose container (when I can find the time
and I am not drinking gin).

/Flibble

[woodb...@gmail.com]

On Tuesday, January 7, 2014 5:22:00 PM UTC-6, Mr Flibble wrote:
>
> My segmented_array container is not /better/ than deque it is just
> /different/; it has different performance and invalidation
> characteristics for certain operations compared with vector, deque *and*
> list.
>

Your container is more flexible in that the user can pick the
segment size. That's better.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Wouter van Ooijen]

> When something is announced as a �C++ course�, it is easier to
> teach what actually /is/ part of C++, because people expect this
> and also I myself deem this to be honest.

You can't explain C++ without examples. Examples are not part of the
standard, so why not take real-world examples from the use of a library.

I assume your course has homework or something similar? There are no
assignments in the C++ standard. So when you select/write the
assignemnets, make them do somthing simple but real. Graphics are not
the only choice, but not a bad one.

Wouter

[Öö Tiib]

On Wednesday, 8 January 2014 00:31:00 UTC+2, woodb...@gmail.com wrote:
> On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
> >
> > 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

'boost::intrusive' does not contain 'map'. So if someone needs
a map then 'std::map' is clearly superior for her. If someone does
not need a map then sure, why she used 'std::map'?

Note that the original intention of starters of boost was to build
libraries suitable for incorporation into the C++ language standard.
They actually have been quite successful with that. You basically
bring example from work that is meant for proposing to standard.

The major beneficial difference of intrusive containers is that
exactly same object can be in several different containers at same
time.

The other difference is that user has to manage the lifetime of
objects. Lot of users I have met have difficulties of optimal
resource management (coming from garbage collections) so that
difference can not be labeled as clearly beneficial.

I have seen cases in practice where 'boost::intrusive::set' results
with 4 times faster than 'std::set' with default allocator. 'std::set'
can be also made to perform as well as 'boost::intrusive::set' by
using custom allocator so it still does not mean it is clearly
inferior.

[Jorgen Grahn]

On Tue, 2014-01-07, Ian Collins wrote:

> Stefan Ram wrote:
>> Ian Collins <ian-...@hotmail.com> writes:
>>> 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
>>
>> ... non-standard ...
>>
>>> library, it is still a widget.
>>
>> When something is announced as a �C++ course�, it is easier to
>> teach what actually /is/ part of C++, because people expect this
>> and also I myself deem this to be honest.
>
> But you aren't teaching the library, you are using a part of it to
> illustrate a concept.

When I was a student, it was not uncommon to have exercises based on
some library or other ready-made code. It was usually written by the
teacher or someone at the staff, and explicitly crude and simple, not
enough for real-world use.

E.g. we got the parser and the virtual machine/interpreter for free
when we did the compiler course and were supposed to focus on code
generation. We got a nice little railroad simulator (graphical, with
bells and whistles) when doing the concurrency course. And so on.

[Ian Collins]

Jorgen Grahn wrote:

> On Tue, 2014-01-07, Ian Collins wrote:
>>
>> In most of my projects, they are the documentation (and implementation)
>> step between the user stories and the code.
>
> I wonder if I would find them /useful/ as documentation too ... are
> any of these projects publicly available so I could take a look?

I'm afraid not.

I try to name my tests so they document the behaviour of the code. The
tests them selves act as both detailed descriptions and examples of how
to use the code. I think this is much easier to do well if the tests
are written first.

>> Unlike JavaDoc style
>> comments, they are always up to date!
>
> Yeah, well ... I don't understand what's so hard about keeping
> documentation up to date. I frequently see people let it slip, and I
> cannot figure out why. Incompetence?

Usually time pressure!

--
Ian Collins

[Rui Maciel]

Stefan Ram wrote:

> Ian Collins <ian-...@hotmail.com> writes:

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

I never heard of any case of a project failing due to having adopted a GUI toolkit which wasn't
included in an international standard.


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

I don't see how you get more teaching time by adding a component to the C++ standard.


Rui Maciel

[Rui Maciel]

Öö Tiib wrote:

> I do not understand. Are you saying that first impression is irrelevant?

How many people got their first impression from C++ by reading the unreleased draft of the ISO
standard currently in development? Because it appears that so far with regards to first
impressions the language has been doing great so far.


> My point was that C++ toolset leaves sad first impression as state of art.

If you believe that standardizing GUI toolkits has anything to do with state of the art then
your concept is not only outdated by a decade or two but it also ignores history.

> C++ standard is guideline for people writing C++ compilers and standard
> library implementations so it has everything to do with improving that
> toolset.

Surely you must be aware that it's possible to develop components for C++ without having them
included in an ISO standard.


Rui maciel

[Rui Maciel]

Stefan Ram wrote:

> Ian Collins <ian-...@hotmail.com> writes:

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

> ... non-standard ...

>
>>library, it is still a widget.
>

> When something is announced as a »C++ course«, it is easier to
> teach what actually /is/ part of C++, because people expect this
> and also I myself deem this to be honest.

Do you believe that programs and/or libraries written in C++ aren't C++?


Rui Maciel

[Öö Tiib]

On Thursday, 9 January 2014 10:06:43 UTC+2, Rui Maciel wrote:
> Öö Tiib wrote:
>
> > I do not understand. Are you saying that first impression is irrelevant?
>
> How many people got their first impression from C++ by reading the unreleased draft of the ISO
> standard currently in development? Because it appears that so far with regards to first
> impressions the language has been doing great so far.

I repeat ... I don't understand what you are saying. Explain?
A: First impression does not matter. (Then lets agree to disagreement.)
B: First impression that C++ leaves is good. (Then lets agree to disagreement.)
C: Graphics can't attract nor impress. (Then lets agree to disagreement.)
D: C++ standard can do nothing to improve C++. (Then lets agree to disagreement.)
E: ... <- Please fill it.

Where did I write that standard is meant for reading by students? I did specify
standard's audience and you quoted it below.

> > My point was that C++ toolset leaves sad first impression as state of art.
>
> If you believe that standardizing GUI toolkits has anything to do with state of the art then
> your concept is not only outdated by a decade or two but it also ignores history.

Unimpressive state of compilers, standard library and tools of C++ is direct result of C++
standard not requiring features that can attract or impress from those people who should
read it. Historic issues continue being issues until repaired, decades do not matter.

> > C++ standard is guideline for people writing C++ compilers and standard
> > library implementations so it has everything to do with improving that
> > toolset.
>
> Surely you must be aware that it's possible to develop components for C++ without having them
> included in an ISO standard.

My awareness does not help at all with issue that I described. IOW it is irrelevant.

Every third newbie question is:
"what is good C++ GUI toolkit?" (first two questions are about books and tutorials)
Every second answer to that question is:
"Qt is more or less OK, but it is LGPL and it is corporately owned and it switches owners
every two years and it creates large binaries and the code of it is not really C++ and it
does take some serious hacking to get it to work on iOS or Android ... and so on."

Is it impressive?

[Rui Maciel]

Rui Maciel wrote:

> I never heard of any case of a project failing due to having adopted a GUI
> toolkit which wasn't included in an international standard.

Correction: a basic 2D drawing API.


Rui Maciel

[Jorgen Grahn]

On Thu, 2014-01-09, Ian Collins wrote:
> Jorgen Grahn wrote:
>> On Tue, 2014-01-07, Ian Collins wrote:
>>>
>>> In most of my projects, they are the documentation (and implementation)
>>> step between the user stories and the code.
>>
>> I wonder if I would find them /useful/ as documentation too ... are
>> any of these projects publicly available so I could take a look?
>
> I'm afraid not.

Ah, too bad.

> I try to name my tests so they document the behaviour of the code. The
> tests them selves act as both detailed descriptions and examples of how
> to use the code. I think this is much easier to do well if the tests
> are written first.

I can imagine that working to some extent ... especially if you
clearly separate "illustrative" tests and "tricky edge cases" tests.

But I suspect personality is involved too. For example, I learn much
better by reading about principles than from examples.

>>> Unlike JavaDoc style
>>> comments, they are always up to date!
>>
>> Yeah, well ... I don't understand what's so hard about keeping
>> documentation up to date. I frequently see people let it slip, and I
>> cannot figure out why. Incompetence?
>
> Usually time pressure!

Not when the documentation is five lines up from the place they
change. Then they're virtually shouting "I didn't bother to learn
about the /intentions/ behind this code before I changed it"[1].
Fortunately it's quite easy to catch this in review.

/Jorgen

[1] Once again, assuming the documentation is relevant to begin
with. If it's not, I'm liable to forget too.

[Chris M. Thomasson]

> "Rui Maciel" wrote in message news:labt7p$co4$1...@dont-email.me...

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

> The link to the Cairo's mailing list:
> http://lists.cairographics.org/archives/cairo/2013-December/024858.html

> What are your thoughts on this?

Graphics for C++, Humm. Perhaps raw bitmaps?

Then teach the students how to program their own line and circle
plotting algorithms in C++. Then go for Bezier Curves, and on and
on. Turning math into visual representations can be a powerful
method of teaching...

IMVHO, starting to learn 2d graphics from "scratch" is the essence
of the power of C++.

;^)

[Alf P. Steinbach]

http://www.boost.org/doc/libs/1_55_0/libs/gil/doc/index.html

cheers & hth.,

- Alf