A list of modern C++ features
github.com
github.com
As someone who doesn't work in C++ or have the benefit of 10 years experience to see the flaws, trying to write modern, safe C++ is essentially impossible. I spent a solid week trying to write something safe and only use C++14/17 features when they were available, and encountered a mountain of outdated- and mis-information about what one can and can't do, what is and isn't considered safe and why one certain feature is better than another.
It's nobody's fault that this happens, but with C++14 apparently fast becoming a language that is addressing it's #1 pitfall (safety) in an apparently very adequate way, it's frustrating that there's no "safe code" linter to stop rookies stepping on landmines.
Thanks for the list, it's a solid start, and the sibling comment about C++ Core Guidelines is another solid resource.
When using make, it could look something like this:
CC := clang
CFLAGS := -std=c99
WFLAGS := -Weverything -Werror
NOWARN := vla
COMPILE = $(CC) -c $(CFLAGS) $(WFLAGS) $(NOWARN:%=-Wno-%) -o $@ $<
foo.o: NOWARN += padded
foo.o bar.o: %.o: %.c
$(COMPILE)
make WFLAGS=""http://clang.llvm.org/extra/clang-tidy/ is much more approachable, and gives a solid overview.
The introductory sentence gave me project-naming cancer:
> clang-tidy is a clang-based C++ “linter” tool.
Then why is it called tidy ??? It appears first on page three of google's search results for "C++ linter" in spite of the fact that anything from LLVM is probably a) current and b) of exceptional quality.
A little marketing-mindset would go a long, long way for these kinds of things.
Whilst the Ruby community lead by the example of DHH often takes this concept too far, it is inarguably effective.
Besides the clang-tidy, there is the ongoing efforts to improve VS analyzers, but I guess they will only be fully productized on VS "15", the upcoming release.
I also imagine other C++ linters are improving their C++ Core Guidelines support.
Under C++ Core Guidelines you are supposed to use [[unsafe]] annotation to mark such features.
Am I the only one who uses C++ as C with classes? Sometimes I use vectors or strings and I like default values in functions and other minor improvements to C. I don't want to reimplement the n'th version of string concatenation when I can just use the "+" operator, sure... and there starts the rabbit hole. Before you know it you have a "protected abstract virtual base pure virtual private destructor" and have to explain the new hired mathematician who only has experience in R what the fuck you are doing.
For that matter, I'd argue that this is a reasonable approach for every language.
I'd say unfortunately not. Focussing on the classes has the disadvantge it can quickly lead to 'everything is an object' or derived strict OOP mindsets thereby not only ignoring tons of other, more functional, goodies modern c++ has to offer but also leading to what you call 'protected abstract virtual base pure virtual private destructor'.
"I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new “features”, little supposing that the main source of his problems could very well be that it contained already far too many “features”. The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more..."
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
Yes C++ is complex, but so are Python, Ruby, Ada, Fortran, C#, F#, Haskell, OCaml, Java...
Even Go will get caught in the complexity game if it gets enterprise adoption at scale.
If not the language, the libraries surely will.
Its not a "complexity game" in so much as poor design being over-compensated for. C++ is like cancer infecting the minds of young programmers with buggy habits -- and no amount of features and static analysis will change what lies beneath... :p
The only thing Ada has thrown away was GC support that no compiler vendor has ever bothered to implement.
What other features were thrown away across Ada83, Ada95, Ada2005 and Ada2012?
If I present you Ada random code snippet X, are you sure you will be able to say which language version it requires?
Also Python is the poster child of what happens when you throw compatibility away.
C is a mine-field of devastating design flaws which have caused many people to die because of decades old decisions made on a whim and any change to basic libraries to make them safer and removing dangerous functions is heresy.
As far as Python, yes the two versions of the language is troublesome for users but the language is objectively better and students learning programming for the first time benefit from a more robust version.
Feel free to give me a random code snippet ;p
It does provide the necessary language features for security conscious developers to write safe code, the fact that many write C++ as if it was "C with C++ compiler" is an unfortunate one.
Yes it would have been great that we had Ada instead of C++, sadly that wasn't what greedy Ada compiler vendors wanted us to have.
In fact, from that list it seems like it is finally meeting parody on key Ada 95 features -- so maybe we dont have to be so sad :)
Wow. Hyperbole much?
I get that you don't like C, but you sound like a raving lunatic who is completely unconnected with reality.
Devastating design flaws? Flaws I can agree with. Devastating? That sounds a bit overstated.
Caused many people to die? I call BS. (Yes, I'm pretty sure you might be able to document a few. But you said "many", and I'm calling you on it.)
Decisions made on a whim? Again, BS. In fact, at this point you're just making stuff up.
There are so many parts of C that are unsafe that a secondary tool is needed to have an reasonable type-checking and that tends to be devastating if they can be easily avoided by even safety critical engineers.
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... "Toyota does not claim to have followed MISRA Guidelines"
And honestly I dont think we agree on what "a few" is. In my book if any more than 4 or 10 people die from a solved problem in computer science (like strong typing, mutexes, and range checking) that is already way too yes many
As far as decisions on a whim compare the two language design efforts and i'll let you decide:
http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&... "The requirements were not a language specification, but instead they attempted to define rigorously the needed characteristics in a form that could be critically reviewed."
https://www.codingunit.com/the-history-of-the-c-language “It’s entirely Dennis Ritchie’s work”
It took a decade to even decide what the C language really was and standardize it -- sounds pretty undefined and whimsical to me. But we all use and understand words differently so let's agree to disagree :)
And what, exactly, happened?
For years I avoided Python3. Updating my code base was a hassle I did not want to deal with.
Finally, a few months ago, I had some spare time and took the dive.
And nothing bad happened. I did not even spend hours on it. At this point, all the libraries I need exist for Python3, and the automated tools update my code for Python3 without manual intervention almost every time.
A minor problem compared to dealing with developers continually using poor paradigms for eternity because C++ did not want to break compatibility.
And I believe the developers who backport to 2.x are not those who implement the features in 3.x. The latter don't care at all about 2.x. Those who backport do not see it as a "pain" but as a new feature to add to their language.
Fortunately the architects of the change said that they've learned their lesson. They don't have much choice either, another one like this and it would be bye bye python.
Certainly did not affect me or anyone I know.
[1] https://github.com/isocpp/CppCoreGuidelines
[2] https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr...
Rust would be an obvious choice for what I described. It's been on my personal list for a while to learn Rust and make use of it. I think I will pretty soon.
I've been demotivated (to start) by reading over here on HN or elsewhere about how much of a learning curve it is to learn Rust. Perhaps, it was the bias that I already know what C++ was like in terms of syntax and idioms that made me ask for a choice with least friction.
I'm mostly a front-end software engineer and I got along just fine with Rust.
That learning curve is necessary for safety. If you want a safe C++-like language without Rust's learning curve, you either (1) have a brilliant solution nobody has come up with yet or (2) don't actually want a safe language after all.
> Make it's syntax as simple and easy to learn as Python
Nim's syntax is mostly pythonic, and it's metaproramming language is Nim (unlike C++'s abominable template metaprogramming language).
If you want it to be safe, you will basically be reinventing Rust.
I've been in the situation many times where the compiler knows about a feature but the auto complete doesn't and the static analyzer will totally fail early and not report anything else except syntax error.
The things I dislike most are pairs and tuples. They make the code enormously harder to read, understand and debug, compared to non-standard classes or structures with meaningful member names. Even this guide promotes them in “using Coordinate = std::pair<int, int>;” Please, never do that, create your own class with x/y or latitude/longitude instead.
auto [a, b] = function_returning_pair();
int a, b;
std::tie(a, b) = function_returning_pair();The author named their pair "Coordinate". In math and in computer graphics there’s widely known convention the fields of Cartesian coordinates are named x/y and not a/b.
When you’ll start writing code that use and/or modify those Coordinate values, meaningful names in C++ source and in the debugger help a lot.
If you use the members a lot, a struct with named members really is much easier to read, though.