> 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.
> 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.
> 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.
> 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.
> 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.
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.
Regards,
--
Roberto E. Vargas Caballero
Received on Tue Sep 16 2014 - 22:02:54 CEST