Slashdot Mirror
Bjarne Stroustrup Announces the C++ Core Guidelines
alphabetsoup writes: At CppCon this year, Bjarne Stroustrup announced the C++ Core Guidelines. The guidelines are designed to help programmers write safe-by-default C++ with no run-time overhead. Compilers will statically check the code to ensure no violations. A library is available now, with a static checking tool to follow in October.
Here is the video of the talk, and here are the slides.The guidelines themselves are here.
Here is the video of the talk, and here are the slides.The guidelines themselves are here.
If you take all the fun out of finding memory leaks and stack overflows what fun is there to C/C++? I mean I just love using AutoPtr everywhere, it's perfect!
Harrison's Postulate - "For every action there is an equal and opposite criticism"
For example, one of the guidelines here is to always prefer make_shared over std::shared_ptr(new ...). That's good advice for a couple of reasons
1) it allocates your memory for the shared_ptr control block and the object contiguously
2) it means you can't separate the allocation from the creation of the shared ptr and end up with an owner who's not looking at the shared ptr in-between.
However, it also means that if you have any weak_ptrs pointing at the end of that shared_ptr, the object itself won't go away until all the weak_ptrs do too (because the control structure won't go away until they do, and they're contiguously allocated).
Imperative programmers reinvent functional programming concepts, but in a shitty way. More at eleven.
"print" is deprecated. You must now use the safe_print_n function and get a safe pointer back using the SafetyFirst() method of the SafeLiteral class.
Because safe by default, amirite?
He has a connecting to all the features he put into C++ and any coding guidelines should include thing that should not be used. First among those are exceptions, unfortunately Bjarne has never wanted to admit C++ exceptions were a mistake.
Ada95 added OO features including clear mechanisms (enforced by the compiler) on how to get OO design benefits without runtime performance costs or risks for dispatching.
Much of what I've seen in C++ is a response to problems in the original language design, particularly gaps or errors of omission.
Computer Science in the 21st Century seems to be full of stuff we knew about in the '80s and '90s, but forgot.
I think it is sad, looking around on the responses so far, to see, yet again, that the overwhelming response to this is to jeer at anything that is beyond people's comprehension. I guess what it boils down to is, that far too many who call themselves coders can't be bothered to sit down and work out a detailed plan before barging ahead. You get nothing but trouble from OOP if you think in terms of simple scripts, and that is particularly true of C++.
Just like "don't use goto", or "don't use threads", etc., these guidelines and recommendations are really great to prevent beginners from making hard to spot errors, but all those variations and features exist for a reason and have a use.
Nobody uses GOTO anymore. With event driven programming and call back functions, it all spaghetti code strewn with COME FROM statements, effectively.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Every object that can be thrown/caught must implement the Throwable interface
Then have all exceptions extend a subclass of std::exception . The guidelines mention use of a subclass as opposed to using the built-in exceptions directly.
the C++ alternative is only allocating objects on the stack and implementing destructors that clean up their resources
Also called Resource Acquisition Is Initialization (RAII), or "automatic resource destruction" if you don't want to remind readers of the record industry (RIAA).
but then you have the restriction of not being able to allocate on the heap
You can take advantage of automatic resource destruction if you wrap your object on the heap in a smart pointer type (std::unique_ptr or std::shared_ptr as appropriate) on the stack. If that isn't appropriate in a given situation, C++11 supports a scope guard idiom using std::shared_ptr and lambda expressions. The finally factory described in the Guidelines is ultimately an update of a method described in a 2000 article by Andrei Alexandrescu in Dr. Dobb's .
You just need to catch the crash. Though it would be helpful if we could pass along some additional information about the crash..
Oh. Hmmm..
-- Seq
I found Rust
I've found it best not to talk about Rust around here. The language has already accumulated a legion of haters at Slashdot. Rational discussion about Rust sans the office punklets happens at Hacker News.
It was anticipated that Rust would motivate some progress in C++ memory safety. Some have argued that if that is all that Rust accomplishes it is worthwhile. Too bad an entire language has to be invented to get some folks off the dime.
The uptake of Rust is so large though I don't think it's going to go away just because C++ adopts some degree of compile time memory safety. The language is great on it's own merits, there is none of that half century of baggage to slog through and the entire stack and all native Rust third part modules provide the same memory safety guarantees, barring 'unsafe.'
These things, combined with the never ending stream of opportunities the segfaults and overflows that C/C++ cannot avoid providing will ensure a chunk of mind-share, haters be damned.
Maw! Fire up the karma burner!
Seasoned professionals have given us decades worth of mostly unnecessary buffer overflows.
I use goto. Sometimes. When you're in C then it's can be effective way to do a function clean up before exiting. Sure this can be over done but trying to avoid a goto like a religious taboo can also result in some pretty nasty code to replace it.
I hate patterns. They're too much like verses from a religious text, because I've run across people who seem unable to understand your code unless it uses patterns from the official pattern Bible. Holding a conversation with them can involve being interrupted every few minutes with "oh, that's a FurblingFunctorFactory, why didn't you say so?" If you don't keep a close watch they'll go and changing existing/working code to rename classes to indicate what pattern they are.