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

From: Maxime Coste <>
Date: Wed, 17 Sep 2014 19:42:47 +0100

On Wed, Sep 17, 2014 at 06:29:01AM +0200, Christoph Lohmann wrote:
> On Wed, 17 Sep 2014 06:29:01 +0200 Maxime Coste <> wrote:
> > On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > > 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).
> Which is, like in other answers stated, not obvious. You have to look up
> the definition to read the source. Hint: Here complexity in the system
> can be avoided completely.

In what exactly is that different from seing mat_add(m1, m2, &m3) ? you see
m3 = m1 + m2, you know a + b is syntactic sugar for operator+(a, b). That is

It seems to me that you are saying 'to someone used only to C, C++ operator
overloading is confusing', on that I can only answer yes, as pointer arithmetic
is confusing for people not used to C or C++.

> > What is your strategy in C when you need to apply the same logic on different types ?
> That doesn’t happen that often to justify overloading. Hint: Avoided
> complexity in the system *beforehand*.

That goes back to the linked list/array thing, you dont have generics, so you use the
easy thing without generics: linked lists, which are almost always a poor choice.

> > > > 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, the best is to apply whichever data structure you need at the mo‐
> ment. Discussing which array to use makes no sense without the actual
> problem defined.

As I said, in practice you almost always have better performances with dynamic arrays
than lists, hence it should be your default list structure. But as it is a pain
to implement in C, because you cannot implement it generically, linked lists stay
the default implementation.

> You are too young, if you think .NET is the problem. The problem arose
> before that with C++ in the Windows world and X11 in Unix. Let’s see
> which wrong logic answer you will apply to the last argument.

Yay, X11 is a well known C++ program. Seriously, there are a lot of bad design
decision in Windows, as there a are a lot in modern linux userland, and
they do not seems to stem from the implementation language. the 90s where the
time of OOP everywhere, and we learned a lot since them. But rejecting the
tools because they were overused makes no sense. the C for construct can be
overused as well, we now have guidelines on that, and they are not 'for
loops are evil'.
> Conclusion: You try to force your work experience into the suckless phi‐
> losophy, which does not work due to different basic principles. Next you
> are fail to accept that reading source code in Open Source is more im‐
> portant than your abstraction of reusing code between hating and oppor‐
> tunity‐seeking programmer groups in corporate lifes. Please come down
> from your throne.

I'm merely trying to defend the fact that I would like to post about a C++
project on the suckless mailing list and have it judged on its own merits
rather than on dogmatic ideas about its implementation language.


Received on Wed Sep 17 2014 - 20:42:47 CEST

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