corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: C99 versus C++ (limited)
Date Fri, 14 Aug 2015 10:20:56 GMT

I started this thread to see if there was a big interest in converting to
C++ (limited). Looking at the comments I categorize such a change as
ranging from
"nice to have" to "not needed" at least for now.

Peter told me very politely (using different words), that there are so much
to do in corinthia, that my time could be used better.

Therefore we will keep DocFormat unchanged in C99.

I hope nobody objects that I play with C++ for the editor framework, since
it is a consumer the effect on other parts are non-existing.

jan i.

On 13 August 2015 at 22:31, Peter Kelly <> wrote:

> I think C++ would make working with the DocFormats library, at least in
> its current form, significantly easier. In particular, the explicit support
> for classes, and the ability to use smart pointers (thus avoiding manual
> reference counting) would be a big win in terms of complexity.
> As a background to why the library is in C and not C++:
> The reason is that originally DocFormats was written in Objective C (since
> I was targeting only iOS at the time). Objective C is a superset of C, so
> when I decided I wanted to open source the code and enable it to be used on
> non-Apple platforms, I methodically went through the source tree converting
> all the Objective C classes and reference counting statements into their C
> equivalents. Objective C has automatic reference counting now, but at the
> time I was not using it, so this meant the translation was relatively
> straightforward.
> While it *is* possible to mix Objective C and C++, doing so results in an
> additional layer of complexity, which I wanted to avoid - you have two ways
> of defining classes etc. The conversion to C was simpler than I expect a
> conversion to C++ would have been. However, now all the code is in C and
> completely free of any Apple-specific dependencies, I think it would be
> reasonable to move to C++ to more concisely express many of the things that
> are currently done explicitly (memory management being the most
> significant). The resulting code would also be more readable.
> I don’t volunteer to do the conversion myself, since it’s a lot of work.
> However for anyone willing to take on the task, this would be an excellent
> way of becoming intimately familiar with the library, which would be of
> great use in developing ODF and other filters.
> I kind of have a natural aversion to C++ because of it’s complexity, and
> the sheer number of features which, if they are all (or even a significant
> portion of them) used can lead to very complicated code. I think we should
> agree on fairly strict guidelines on the subset of the language we use, do
> avoid things “getting out of hand” with the codebase, so to speak.
> There are some nice properties of C I like, such as the ability to grep
> for a function name throughout the whole source tree to find out all the
> places it’s used, which is handy for refactoring. Xcode also has some
> refactoring tools which work for Objective C and most of C, which I used a
> lot doing the original conversion, but these do not work with C++ (of
> course this is a limitation of Xcode, not a problem with C++ per se).
> There are some specific areas we’ll need to be careful about in terms of
> performance. Actually the first pure C code I had in DocFormats, long
> before I converted the whole library, was the DFNode and DFDocument
> structures, which use a specialised memory allocator that simply allocates
> a slab of memory and frees it all in one go after conversion has finished.
> Prior to that, every node was a separate Objective C object, and freeing a
> whole document took an inordinate amount of time, due to the large number
> of release messages sent to free individual nodes, and the fact that
> Objective C’s dispatch mechanism is not efficient for compute-intensive
> code. This had a very noticeable impact on load times of large documents,
> which was greatly improved by switching to a customised, efficient memory
> allocation strategy. We should maintain this when moving to C++.
> Regarding Flat, I’d like to keep that in C at least for now, because my
> plan is to build a virtual machine for executing Flat programs, and for
> which I’ll implement a garbage collector, which necessarily requires
> intimate knowledge of the memory layout of objects. While this is possible
> to do in C++, it’s easier in C as there’s less abstractions in the way.
> Flat is also about to get it’s own type system, which will be different in
> many respects from that of C++ (and more tailored towards the task of
> transformation). I’ll post more on this in due course.
> But for the bulk of the DocFormats code, I think it makes sense to move to
> C++, and that we’ll benefit from the improved maintainability and make it
> easier for new committers coming into the project to understand the
> structure of the code.
> —
> Dr Peter M. Kelly
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> > On 10 Aug 2015, at 6:26 pm, jan i <> wrote:
> >
> > Hi
> >
> > Peter and I talked the other day and among others about the benefits of
> > using C++ instead of sticking to C99.
> >
> > This would be a major change in the project (less in the code, more in
> the
> > "how to"), and it is
> > not something we should "just" do.
> >
> > I favor C++, but not unlimited, I see 2 places where C++ can give us more
> > stable code:
> > - Interfaces.
> > Using classes to group our functions (like e.g. platform, core,
> filters/odf
> > etc.),
> > would make it very clear where the function originates. It would also
> allow
> > group global variables that are private to the rest of the world.
> > I would not use real interface classes, for our internal grouping, that
> is
> > not needed. But e.g. the DocFormats API should be a real interface class
> > - Automatic.
> > At the moment we have a lot of code managing construction/deconstruction,
> > that could be totally automated by use of C++ smart pointers.
> > - Object model (filters, flat and core)
> > would be more logically represented as objects, and suddenly copying etc.
> > would be a lot easier.
> >
> > I would not like to see big inheritance (especially not multiple
> > inheritance).
> >
> > I fail to see what we loose by making the change, but please give your
> > opinion.
> >
> > rgds
> > jan i.
> >
> > Ps. This is in no way a vote thread, but simply a way to gather opinions.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message