The opposite can also be said. By re-inventing a simple data structure, you can end up 2 years later in the same position where your structure is inefficient (list vs. array, etc) and you end up having to rewrite your app. While implicit operator overload was probably a C++ mistake, it does allow to replace some kind of structures with other one without changing the code relying on them.
Other than that, I kind of agree that C++ is kind of terrible. So is perl, php, js or any other languages that send a barrage of features to the programmer without managing to educate them on their impact on performance and memory structure. Most C++ devs know about vTables and that's about it. I would also argue that C isn't a very good language either. It may be simpler to "get" what actually happen when you run your code, but has sub par code organization, total lack of "pointer flow" tracking, causing huge security traps and has an evil reliance on casting for any kind of structure/callback abstraction. All of those things could be "fixed" in new languages, but beside Rust, it seem there is no leverage for proper system level languages these days. OOP is probably a better choice for business programming anyway, but that's not even half of the market.
are you talking about the implicit conversion operator or operator overloading in C++?
For the former, it has been vastly improved in C++11 with the addition of explicit conversion operator. For the later, some very important capabilities of C++ rely on operator overloading namely the assignment operator (copy/move assignment) and the function operator (allows what C++ calls functors). Another useful thing with operator overloading is allowing the creation of generic functions that work on existing types (int, float, ..) and user defined types, for example std::accumulate.
C++11/14 "auto" is an example where someone can have the equivalent of a void* with compile time type checking and "no" runtime penalty. Yes, multiple specialized version of the method will be created and increase the binary size and potential cache fault, but much of them will (ok, should...) be eliminated/combined again during LTO. A slightly incompatible fork of C could also remove array to pointer demotion, sizeof() would then be consistent and potential overflow would be possible to catch using branch analysis or -fsanitize=.
However, C in all its simplicity already has its potential for abuse. Macros can go very bad. Very bad. (Just look at openSSL).
It is also not difficult to abuse the left-right rule in pointer arithmetic: *x->a->c=5. It can easily become incomprehensible.
We did not need C++. We needed a way to further simplify C.
Lua is the answer. :P
C++ started out as a great 'next generation C', but in the last years it became a playfield for CS-academics, just adding one useless esotheric feature after each other.
http://thread.gmane.org/gmane.comp.version-control.git/57643...
> Unfortunately, I haven't had any time inte the last few days to code, nor read mail. I'm assuming that there is no point in me finishing the patch and that git will go with the strbuf solution? /Lukas
... with no response.
Yeah, only "getting shit done" and "getting Linux and Git" happen, which is pretty much all he attempted to do.
If he likes simplicity and good taste then why did he pick Git over Mercurial? Because he did not implement the latter?
I understand the reasons behind these, none the less they are really annoying.
Any sufficiently complicated C program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of C++.
For example: 1) Macros for data structures instead of templates 2) Virtual functions emulated with function pointers 3) goto fail instead of exceptions
