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.
Its nice to see efforts to drive the complexity out of the design/implementation of safe code but this won't due much to improve the already error prone task of debugging optimized code. You don't always have the luxury of running a debug build, especially when analyzing a crash dump from a customer and templated/STL C++ constructs are often too complex for debuggers to parse properly. Hopefully these efforts reduce the number of crashes enough to justify the added complexity of debugging the crashes that still occur.
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.
Bjarne has never wanted to admit C++ exceptions were a mistake.
What should a method that fails do instead of returning an exception? Should it instead be set up to explicitly return two different types of return value, namely the object that it's supposed to return if it exceeds or an object describing the failure if it fails?
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
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
Unless you're dealing with hardware directly, you don't need pointers at all.
Those who do not learn from commit history are doomed to regress it.
The other thing about GC is that it solves the resource deallocation problem for memory only. It doesn't support deallocating other resources which may be more important to deallocate promptly. (People are working on C and C++ garbage collection, and there have been attempts, but none have gained much popularity. Whether this is because nobody has worked hard enough, or because it doesn't offer a solution that much better than smart pointers, or that C and C++ just won't work well with GC is an interesting question.)
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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!
I've ran into situations where not using GOTO resulted in much messier code that was harder to read. This rarely happens, but it does happen, and I always take a step back and try to find a better way than using GOTO.
Half century? Are you counting from Algol?
That said, the cruftiness of C++ is one of the things that keeps me from bothering to properly learn it, however much I respect its newer developments. Another is that its place on the scale of abstraction isn't often a place that I need to go personally: C or Python usually makes more sense for me.
Where on that scale would you say Rust lies? Is its target use software that lies on the boundry between systems software and applications, e.g., web servers?
Seasoned professionals have given us decades worth of mostly unnecessary buffer overflows.
You're trying to make me declare some sort of hard-and-fast rule to something that's really an issue of style, which I won't do. But here's a heuristic: if you expect to succeed in opening the file, you could probably go ahead and use the 'pythonic' 'ask forgiveness, not permission' pattern. But if you're trying to (for some reason) open only one of 50 files and expect the other 49 not to exist, then your loop should probably look more like
instead of
Also, exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
Having been handling errors for a long time before I ran into exceptions, I don't agree that having to constantly check some sort of error flag is better than using exceptions.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Exceptions are one approach. The mistake is in thinking that one approach supersedes all others.
It has more than its share of problems, which need to be acknowledged if we're to move beyond them.
Required reading for internet skeptics
For C that's a perfectly reasonable use of goto. For C++ you should use unique_ptr or wrap your resource in your own object that you can stack allocate. RAII is a very nice pattern in C++.
RAII is not a "pattern" it is an "idiom".
A pattern is independent from programming languages, idioms are thins you only can do in one/some language.
e.g. using pointers and ++ to copy a \0 terminated string like this:
... supported by certain languages, not a pattern.
strcpy(char* dest, char* src) {
while (*dest++ = *src++)
;
}
is an idiom
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Congratulations: You just created a time of check to time of use (TOCTTOU) race bug. Consider what happens if another process deletes the file between the call to isfile and the call to open.
exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.
Could you explain what you mean by this? Is it that Python tends to throw (predictable) exceptions in cases where C++ has (unpredictable) undefined behavior?
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.
For C that's a perfectly reasonable use of goto. For C++ you should use unique_ptr or wrap your resource in your own object that you can stack allocate. RAII is a very nice pattern in C++.
So unique_ptr will close open file handles and network connections?
I'm a minority race. Save your vitriol for white people.