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

From: Maxime Coste <>
Date: Wed, 17 Sep 2014 00:38:27 +0100

On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> > is to catch at compilation code that is logically invalid, if you have
> > f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> > signature. In C you would be forced to use f(int, int), and long debugging
> > sessions to discover this simple mistake.
> Then write better and more logic access functions instead of your object
> abstraction. It keeps your mind simpler and speeds up your code.

These are not objects, just ints, its an implementation detail that I use a
a class to get segregated types and to specify exactly what can add to what.
On any platform with a decent call ABI, this compiles to the same assembly,
the only thing being a nice error message if I try to do something senseless.

> > It just gives you tool so that you can write your code closed to the domain
> > language, did you learn linear algebra writing matrix_add(m1, m2, &m3)
> > ? or m3 = m1 + m2 ?
> This is programming and not your playground. Avoid fancy code.

I guess that is a matter of taste, I just know m1 + m2 calls operator+(Matrix, Matrix).
> Suckless is about writing simple code bases. When your choice for C++ is
> because you want to write complex code bases then you are in the wrong
> community and should leave as fast as you can.
> By adding constraints on the hidden complexity it is by cause made hard‐
> er to write useless abstraction code.

You cannot always simplify the problem to keep a simple solution, sometimes the
problem *is* complex. I put safe guards in the code, especially when the have
zero cost in release, because I have debugged enough clever C like code to
prefer a compilation error or an assert failing as soon as possible to a long
session in gdb.

> > > No generic is a feature. Generic are very stupid idea that only creates
> > > blown binaries (this is one of the point I don't like about C11). Also,
> > > the compexity of generics in a lenguage with automatic conversions
> > > like C (and C++) is too much.
> >
> > what is silly is rewriting the same function with different arguments again
> > and again. Or ending up relying on macros to emulate generics.
> Learn to code in C.

What is your strategy in C when you need to apply the same logic on different types ?

> > Get your complexity right, inserting in a dynamic array is O(n), the eventual
> > need for an allocation is amortized (whereas you always end up doing a malloc
> > for your linked lists). Another thing you should look up is modern cpu
> > architectures and caches, in practice the much better locality of reference
> > of arrays makes them *way* better on operation like insert/erase in the middle
> > than lists even though complexity theory says otherwise. (Remember, complexities
> > are asymptotic, you need huuuuuge number of elements).
> When you work close to the metal much of your theory can be optimized
> out. I won’t tell you how.

The best you can do is store your linked list in an array, and sort it at certain
point so that elements end up linearly in memory. But when you've done that you
already have a dynamic array implementation.

> No, civilisation ended when »C++« was mentioned. Code abstraction and
> bad design choices made from idiots relying on OOP are the reason why
> your local Windows machine is so slow in loading drivers, opening Win‐
> dows, loading the help file in the regular Java NULL pointer exception
> or simply loading and displaying text in a webbrowser.
> This can only be avoided by changing and restricting the system.

I blame that on .net... More seriously, yep there is a lot of ugly C++ out
there, and OOP nonsense, I've seen my share of extra deep class hierarchies
with virtual methods everywhere. That code might have been written in C++,
but its very far from idiomatic, modern C++. The ioccc tends to show that
C is far from imune from unintelligile code.


Maxime Coste.
Received on Wed Sep 17 2014 - 01:38:27 CEST

This archive was generated by hypermail 2.3.0 : Wed Sep 17 2014 - 01:48:07 CEST