
ISO C++ 2D API - protomyth
http://tirania.org/blog/archive/2014/Jan-04.html
======
cosmotriton
[A note from the peanut gallery]

Miguel loves C and that's perfectly fine - it's a great language, easy to read
and write, powerful, but does suffer from some of the same _fundamental_
problems as C++... Both languages are tightly bound to today's base machine
architecture - they are called "systems programming languages" for this very
reason.

I find it odd that we have this continual debate about older (and widely used)
systems programming languages (the ones that are _actually_ used and form the
basis of modern computing....), but neglect the arguably more interesting -
and obvious - problem: the lack of a viable, consumer class, non-Von Neumann
machine architecture. What would it mean for the advent and design of new high
level programming languages that are safe, performant, productive, portable,
and that directly map to this new machine model?

The future will always be built on the past, but this doesn't mean we have to
keep re-inventing the same problems to solve... Here's to a future of new
machine models and the languages used to program them efficiently,
effectively, safely, _and_ easily.

------
vinkelhake
This blogpost is so silly.

Agg is more like a meta library for constructing drawing APIs. Using it
directly is quite painful. It even comes with Agg2D which is a simplified API.

Another easy to use C++ drawing API is Qt's QPainter.

It all comes down to how you design the API. C++ doesn't force you to come up
with Agg if you really want something like QPainter. I expect the
C++-translation of Cairo to be equally simple. We're talking about translating
cairo_foo(ctx, params); to ctx.foo(params); and adding automatic memory
management.

API design is hard. If you have it in you to design a good C API, you could
probably do the same in C++.

------
randallu
What is this? Python? Why "standardize" Cairo? I can already use Cairo if I
want to.

I'd rather they provided some standard template interfaces to all of the
common 2D graphics algorithms (simple line clipping, tessellation, polygon
clipping, bezier subdivision, etc) and not couple it to a classical scanline
rasterizer CPU graphics library. But I don't think that even this belongs in
the language standard.

There are a bunch of other opensource libraries they'd need to "standardize"
if they want to draw text...

~~~
zanny
> Why "standardize" Cairo?

Because it means you can start making assumptions about available resources on
platforms you target. If all you need is the included 2d api in the standard
(which would be terse at best) then as soon as you can throw a compiler flag
for, say, c++14, you can _assume_ those primitives are there. You don't have
to fight to either bundle a 3rd party library with your software, or pray to
god the included version on the target system still has a version with the
same abi, etc. You can just use it outright without hesitation because
standard compliance means you have it at your disposal.

------
sparkie
Do we really need a vector graphics library in standard C++? Why not just
create a new ISO standard using Cairo as the base, and stop making the
language even more bloated that it currently is. If the proposed graphics API
does not require changes to the language it really doesn't need to be there.

~~~
MaulingMonkey
Quality standard libraries are wonderful in that you can rely on their
presence.

A thousand ad hoc separately licensed libraries with wildly varying build
chains, supported compilers and operating systems, with similarly varying code
quality, naming conventions, build configuration options, conflicting runtime
selection, error handling styles, documentation quality, etc. may be the bread
and butter of your standard C++ programmer -- I know it is of mine -- but it
hardly seems like the ideal state of things, especially having also used
languages with much, much larger standard libraries.

What practical problems have you, personally, run into as a result of standard
library "bloat"?

Just yesterday, as a practical problem I've personally had with the "leanness"
of non-standard libraries, I spend a good half the day trying to wrangle a set
of third party libraries into submission. 4 library configs x 3 platforms
varying just enough to spend a good half the day setting up library paths,
library names, library dependencies, tracking down #defines for "optional"
functionality that was forgotten (or off because it doesn't work yet -- I
haven't figured out which) on one platform, all in yet another build system
(adapting their projects to ours would take too long), harmonizing runtime
library settings to match instead of crash...

A whole lot of busywork that simply doesn't happen for standard libraries,
because "batteries included" means it's already been taken care of, without
cutting off the rabbit hole of extra libraries when you need them.

~~~
sparkie
I run into many of the same issues as you, but pushing some library to become
standard does not _solve_ the problem at all - it just forces the problem on
somebody else. Somebody still needs to configure and maintain the library for
a particular distribution, but rather than it being a distribution's package
maintainer (or yourself), the problem is pushed onto the compiler/standard
library devs, and the distribution's maintainers will still need to configure
the standard library for their own distributions anyway. This is the "bloat"
\- it's increasing the workload for those developers. (I don't personally work
on a C++ compiler, but I've worked on tooling for other languages, and I've
maintained packages.)

The problem of package and configuration management is an OS problem and
should not be the responsibility of compiler developers who would ideally be
working on an OS-agnostic language compiler. For every non-language feature
you push into the standard, you increase the amount of coupling the compiler
has to an OS. (It's already the case with existing APIs, even down to basic IO
- it actually forces the operating system to be designed to match the
requirements of the language, and thus limits to scope for experimentation and
other solutions.)

C++ has significant usage outside of our mainstream operating systems. It's
used in embedded systems, and they have the exact opposite problems you
describe - the trouble of taking things out of the language, rather than
putting them in.

The way we maintain packages should be agnostic of any particular OS or
language - we need a way to eliminate the "hidden knowledge" that goes into
building and configuring the packages in the first place, so that any
particular setup can be automatically reproduced. It's not a solved problem
yet, but Nix is making great steps towards that capability, which don't
require adding bloat to existing solutions. (We usually call it the
Open/Closed principle)

The C++ Committee are attempting to solve the problem in a different way - by
saying "we'll handle everything for you". What about adding libraries to ISO
C++ for scraping websites, or accessing RDBMS, parsing text, or one of the
dozens of common programming problems that exist? Why graphics in particular,
and where do we stop attempting to push things into the standard? Screw it,
why don't we just make ISO C++ a standard operating system?

~~~
widdershins
I think Herb has said the answer to "why graphics in particular" is:
beginners. If someone wants to start out programming in C++, it can be
disheartening to learn that just drawing some simple shapes requires using
external libraries, with all the complexity that brings.

~~~
nightski
Maybe some effort should be put into making it much easier to use external
libraries in a C++ IDE then?

With Visual Studio or Eclipse I am still downloading the libs for my
architecture, sometimes compiling them with an entire set of potential issues
and dependencies, configuring paths, etc...

They have NuGet for .NET in Visual Studio, you'd think this could be done for
native software.

It is actually far easier to do this on Linux with package managers, which is
sad for Windows imho.

~~~
eropple
The main roadblock is the disgusting combinatoric explosion of compiler
versions and debug/release single/multi versions.

The "answer" seems to be to download as source and plug vcxproj dependencies
right into your solution. Which, coupled with Windows's problems with static
libraries (I use nothing else on OS X - static library right out of Homebrew),
is hilarious.

~~~
MaulingMonkey
Sometimes that's the answer. But just yesterday this set of library vcxproj s
ended up being generated by CMake... with one supported platform each and
absolute paths in them. Not worth even checking into the depot, nevermind
including in your .sln, not that the first person to take a crack at it didn't
_try_ checking them in and adding them to the sln...

It's not even that great a library from what I can tell.

~~~
eropple
Yeah - CMake adds more problems than it solves, IMO. I keep an XCode project
and a VS solution and just deal with it.

------
mikevm
That blog post has 0 content.

In what way was Cairo the "clear winner"?

------
IsTom
News from Herb Sutter -- cool. Rather subjective attack on "hostile templates"
\-- not cool.

~~~
randallu
AGG is pretty nasty to use and has worse performance than Cairo on basics like
alpha blends and copies (bitblts).

------
rayiner
He's not wrong about C versus C++. I'm probably just dumb, but I find the Mono
source (C) way easier to follow than say the Sun JVM (C++).

~~~
eropple
I don't know many people who'd call the JVM good C++, though. It's got a _lot_
of baggage.

Life's way too short to not have things destruct on scope exit. I'm pretty
confident that my own projects would be a lot more verbose and much, much more
error prone (like, failure-to-get-off-the-ground error-prone) if I had to deal
with C's limitations.

------
atesti
By the way, the author of Antigrain (Agg) has recently died:

[http://beta.slashdot.org/submission/3154635/rip-maxim-
sheman...](http://beta.slashdot.org/submission/3154635/rip-maxim-shemanarev)

I was shocked to read this when I saw the blogpost from Miguel and wanted to
find out why development of Antigrain stalled.

------
oscargrouch
its a matter of subjective taste.. particularly i think C# is nasty.. nothing
to see here.

Edit: But i respect the man! :)

~~~
oscargrouch
really, in the case he is pointing out (choosing cairo for moonlight) its just
a matter of wrapping a C api in a C++ application.. so people can embed more
easily...

See the case for the Dart VM for a good example.. its everything wrapped in
the C api.. (and also if you want a example of beautiful C++ code for a
complex application. hack the VM).. in every language you can write pretty
code or nasty code.. i think the only exception here would be haskell (as a
proof of the impossibility to write a code that do not look ugly)

------
checker659
What about Skia?

