Re: [dev] [RFC] Design of a vim like text editor

From: Maxime Coste <frrrwww_AT_gmail.com>
Date: Tue, 16 Sep 2014 20:09:13 +0100

On Tue, Sep 16, 2014 at 09:13:00AM +0100, Ralph Eastwood wrote:
> Maxime, I really like what you'e done with kakoune, although your code
> base doesn't
> seem to use C++'s features heavily, meaning that your could write
> equally clean code in C.
> Why does it have to be C89? C99 is nicer.
>
>
> For a text editor, C is perfectly adequate as the main operations are
> to do with text and you don't
> really need to worry about a lot of abstractions.

Well, I still rely a lot on having a proper type system to do checks at
compile time. For example I have separate types for line counts, byte
counts and char counts, so I get a compilatin error if I try to add
bytes and char, while still getting the conveniences of using operators,
and with code that compiles down to plain int operations.

Another example would be safe_ptr<T>, pointers that compiles to raw pointers
in optimized builds, but that guarantee that the pointed to object is alive
(you get an assert if an object dies when a safe_ptr to them still exists).
It stills behave like a pointer, but allows me to both document, and get
debug checks, that the pointed to object should by design outlive this pointer.

C++ is not the most elegant language, but there is nothing better available
IMHO. C89's minimalism is attractive, but no overloading, no generics, and
weak type system makes it harder than necessary to manage complexity. And
modern C (99 and 11) does have its own ugly quirks (the magically overloaded
tgmath.h functions, 'complex' builtin type...).

A common symptom of C's lacking abstraction facilities is the reliance on
linked lists as the most common list data structure. As it is so easy to
implement you add do it quickly for any struct, when in practice a dynamic
array provides you with much better performance characteristics.

Cheers,

Maxime Coste.
Received on Tue Sep 16 2014 - 21:09:13 CEST