[cairo] Cairo and ISO C++

Sat Jan 25 00:33:39 PST 2014

The reference implementation is now posted to GitHub:
https://github.com/mikebmcl/N3888_RefImpl . It currently requires Windows
(tested on 7 and 8.1) with Visual Studio 2013 (the free Visual Studio 2013
Express for Windows Desktop works fine).

I'm hoping we will have a GNU/Linux X11-based (or maybe XCB-based) build
using GCC sometime in the near future but I can't make any promises. (The
code is mostly standard, portable C++ with only a handful of
Windows-specific things, most of which relate to the entry point and
creating a window. So it's almost entirely a matter of finding the time to
create a project file system using CMake or Autotools. The past few days
have been pretty quiet and thus productive but now with the reference
implementation rolling out there could be a lot of feedback, questions, and
concerns that need attention. So we'll see. It shouldn't be difficult to do
a quick and dirty port if you want to try it out on a different platform).

Also, I can't promise there are no bugs. I've found and squashed several
this week but there may be more lurking which will show up when I have a
chance to really test the functionality.

Thanks!

-Mike

(p.s. Apologies to those who read this in multiple places since I am
copying and pasting the same release message because I'm exhausted and want
to get to sleep!)

On Mon, Jan 20, 2014 at 7:16 PM, Michael McLaughlin <mikebmcl at gmail.com>wrote:

> Hi!
>
> I wanted to give everyone an update. Earlier today a proposal that Herb,
> Jason, and I have been working on, N3888: A Proposal to Add 2D Graphics
> Rendering and Display to C++, was published here:
> http://isocpp.org/files/papers/N3888.pdf . The main focus of the proposal
> is a series of rules that enable a mechanical transformation from the cairo
> API to an API that is in the style of the C++ Standard Library (the STL).
>
> We expect to present the proposal for feedback at the Issaquah, WA
> meeting of the ISO C++ Committee (PDF)<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3707.pdf>which runs from Feb. 10 - Feb. 15, 2014 (I will personally be there from
> mid-day Monday through Wednesday). We do not expect that the proposal is
> final and we are soliciting feedback on it from everyone who is interested.
> This includes all of you. We are hopeful that you will all be receptive to
> the approach we have taken and are supportive of the concept (even if you
> might have some ideas about how to make technical improvements).
>
> There is a reference implementation that is nearly ready. When it is
> complete I will post a link to the Git repository for it. The
> implementation right now is built on Windows using Visual Studio 2013 (it
> will work fine with the free Express for Windows Desktop version), but
> there's no reason it cannot run on a GNU/Linux or *BSD environment with a
> few changes. I hope to have some time in the next week or two to create a
> version using GCC on Ubuntu, but I can't make any promises.
>
> For those curious about the process, we will be presenting the proposal in
> Issaquah and will receive feedback on it (both there and from other places,
> including here). We expect that the general concept will be well received
> (though there's always a slight chance that it won't be) and that we will
> get a lot of constructive criticism. We will take that feedback and proceed
> to amend the proposal. Others may also propose amendments (either
> informally to us or formally through an N numbered paper). When we are
> ready, we will publish the amended document and present it at a future
> meeting of the ISO C++ committee. (There are generally two a year; one in
> North America and one in Europe or Asia, though sometimes (such as this
> year) there are additional meetings). The ultimate goal is to reach a point
> where everyone is satisfied with the proposal, in which case a formal vote
> would take place and it would be adopted as a Technical Specification. TSs
> are not formally part of the standard but are things which are likely to
> become part of the standard in the future. The various compilers (GCC,
> Clang, Visual C++, Intel C++, IBM C++, etc.) implement TSs so that the C++
> community can experiment with them and flush out any issues or problems
> that weren't discovered earlier. If all goes well, the TS would
> subsequently be adopted as part of the ISO C++ language standard, at which
> point it would officially become part of the C++ Standard (specifically the
> C++ Standard Library). The goal of all of this is for C++ programmers to be
> able to render and display 2D graphics by writing standard code which will
> compile and run regardless of which compiler or operating system the
> developer uses and targets. We consider portable, standards-compliant code
> to be a great thing and we are excited to tackle the problem of
> standardizing 2D graphics and are thrilled to create a design that uses
> cairo as its basis.
>
> If you do decide to read the paper (or play with the code once it is
> released), do note that we were intentionally conservative in some of the
> transformations and that we expect the proposal to evolve and change over
> time. When I am back from Issaquah, I hope to be able to revisit all of the
> great suggestions in this thread and work on drawing up amendments based
> upon the ideas that fit with the proposal.
>
> Thanks again for your time and for all the great work you've done
> individually and as a community in creating cairo. It is a masterful
> accomplishment and I'm really glad I've had the opportunity to work with it
> for this project!
>
> Respectfully yours,
>
> Michael B. McLaughlin
>
>
>
> On Tue, Dec 31, 2013 at 9:23 PM, Herb Sutter <herb.sutter at gmail.com>wrote:
>
>> Hi, my name is Herb Sutter and I chair the ISO C++ standards committee.
>> Behdad referred me to this list as the right place to raise this question:
>>
>>
>>
>> We are actively looking at the potential standardization of a basic 2D
>> drawing library for ISO C++, and would like to base it on (or outright
>> adopt, possibly as a binding) solid prior art in the form of an existing
>> library. You can find a quick summary of goals and discussions to date in
>> these two papers:
>>
>> ·         http://isocpp.org/files/papers/n3791.html
>>
>> ·         http://isocpp.org/files/papers/N3825.pdf
>>
>>
>>
>> As noted in the latter paper, we are currently investigating the
>> direction of proposing a mechanically C++-ified version of Cairo.
>> Specifically, “mechanically C++-ified” means taking Cairo as-is and
>> transforming it with a one-page list of mechanical changes such as turning
>> _create functions into constructors, (mystruct*, int length) function
>> parameters to vector<struct>& parameters, that sort of thing – the design
>> and abstractions and functions are unchanged. This would also allow us to
>> track Cairo as it evolves in the future, by continuing to reapply the same
>> rules to new updates to Cairo.
>>
>>
>>
>> We know about Cairomm but it seems to have languished so we are focused
>> on current Cairo as a starting point, even though it’s not C++ -- we
>> believe Cairo itself it is very well written C (already in an OO style,
>> already const-correct, etc.).
>>
>>
>>
>> We want to make sure we’re doing this in the right way and with the
>> group’s approval, so your feedback would be much appreciated. Also, we
>> might want to reuse parts of the Cairo documentation in our specification,
>> which we understand is governed by MPL 1.1, and we would like to know if
>> this would be all right with your group.
>>
>>
>>
>> Thanks, and best wishes,
>>
>>
>>
>> Herb
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20140125/d379649c/attachment.html>