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

From: Maxime Coste <frrrwww_AT_gmail.com>
Date: Tue, 16 Sep 2014 21:30:47 +0100

On Tue, Sep 16, 2014 at 10:02:54PM +0200, Roberto E. Vargas Caballero wrote:
> > 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
>
> Proper..., good word for saying a pain in the ass. One of the best thing
> of C (and C++ because they share this part) is automatic conversions
> that remove this work of the programmer. If you have problems
> with them maybe you should learn a bit more.

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.
 
> > 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.
>
> Operator overloading, one of the worst things of C++ (well, there are
> so much of them that is only more of them). It only is useful to make
> obfuscated code.

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 ?
 
> > 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.
>
> I don't need this damaged brain pointers, again if you have this kind
> of problems you should learn a bit more. Like a friend of mine says,
> code in C is like sex, you have to know what you are doing.

You probably never worked on complicated enough code bases if you believe every
program fits entirely in your brain. Putting safe guards in you code asserting
that what you believe is correct actually is is necessary if you want to keep
your sanity.

> > 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...).
>
> 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.

> > 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.
>
> Depend. Basically depend of the size and the operations you do in it.
> I suppose you know that inserting in a dynamic array is O(n^2), and of
> course, searches in an unordered array is O(n), while inserting
> in the head of a list is O(k). There is a limit in the size where almost
> operations in dynamic arrays are slower, and in a lot of times with this
> small sizes you can use overdimensioned arrays that are far faster
> than dynamic arrays.

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).

> Stop this C++ proselytism because the only thing you are going to
> get is becoming a troll. If you like maschoshism is your problem, but
> please don't tell to us.

Can't we have a civilized discussion ?
 
Cheers,

Maxime Coste.
Received on Tue Sep 16 2014 - 22:30:47 CEST