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.
Praise the computer gods!
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"
CPPCoreGhost?
He really didn't say all the things he said.
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.
As a hiring management and C++ expert, I can tell you that most C++ programmers are bad because they are not well informed. C++ demands the use of best practice and the avoidance of pitfalls. If you call yourself a C++ professional you should be thoroughly familiar with the work of Meyers, Sutter, Lakos, Stroustoup... This effort can only help.
"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?
Safer than you could possibly imagine.
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.
What I take from the talk is that ownership matters.
I found Rust very interesting on its pragmatic solution to pointers. If c++ can borrow that and implement it, even better.
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.
Safe but you have to pay a lot of attention to not make it accidentally unsafe, thus.. sort of safe?
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.
Just say no.
I mean, that's like asking your drug dealer how to smoke crack safely. Because he has the most experience. And must be a specialist in drug safety because he is still alive. Until he isn't.
I mean, we are talking C++ here. The language where one solves the dining philosophers problem by turning the forks into generalized tables and then taking a dump on the plates.
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++.
They have to make these core guidelines because C++ leaves open so many possibilities to use it incorrectly and create an abomination that kills people.
David Emery, who posted above me, got it right. There are SO many better designed languages than C++. Ada is one of them, yes.Hell, even ding dang old Delphi is a better language than C++. And if you don't trust an automated software system to allocate and free memory for you, then what automated computer system DO you trust?
I've said it once, I'll say it 1000 times: C++ is the product of troubled minds.
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.
"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup
Very true, C++ would struggle no matter how laudable the goal is.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
It should print "Error: The operation completed successfully."
There are languages that have learned from the mistakes of past languages and have the freedom tp do things better.
Myself, I am currently being impressed by the efforts of the golang community. They have thought of most things that annoy me as a C/C++ programmer -- a very low overhead GC (sub-ms in v1.5), built in vet (a lint-likr tool with race-condition detection), coverage analysis, unit testing, and an official git-based package import tool. And messaging in preference to passing pointers around in unsafe ways.
And a language spec that isn't 2,000 pages long.
You claim that all exceptions should be fatal. I hope this was sarcasm. If not, then for example, if a program lacks a configuration file because it is being started for the first time, what lesson ought to be taught, to whom, and why?
More than half of Stroustrup's talk was concerned with pointers. In 2015, we still need the kind of effort Stroustrup is calling for, simply because a fairly advanced OO language STILL uses pointers, with the risk of dangling ones, of pointers outliving the thing they point to, etc. etc. ? I dunno, people... but this is one of the main reasons I never made the switch to C++.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
For the longest time I thought that people were talking about a C string function when they mentioned his name.
He really didn't say all the things he said.
Earlier today he confirmed that he really did say all those things.
Safe as houses, safe as fuck!
All those moments will be lost in time, like tears in rain.
Checked exceptions are probably better viewed as part of a the API, in the sense that if exceptions didn't exist, these would be implemented as return parameters, which you would also have to declare and either check, or pass to the calling code.
Maybe all exceptions should have been checked, but the difference (not always followed) is that checked exceptions are supposed to be for things the deployed program or user has some control over (missing file, sleep interrupted - that is, things you should plausibly expect to happen), and unchecked exceptions are for bugs or uncontrollable things (NULL, out of memory - bugs you should have fixed, or can't expect). In other words, handling checked exceptions should be as natural as checking to see if fopen returned NULL in C.
Not done as consistently as it should have been in Java though. Made them confusing, inconsistent, and irritating to a lot of people who just decided checked exceptions were wrong rather than misimplemented (similar: operator overload abuse makes many people dislike the entire idea).
It will give you code so secure that it can even order some fruity cocktails with those little umbrellas!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
if a program lacks a configuration file because it is being started for the first time
That isn't an exception. That's a given.
Based on a cursory Google search, "given" appears not to be a term of art in programming. What is the C++ idiom to handle givens? I know Python's idiom is Easier to Ask Forgiveness than Permission (EAFP), which uses exceptions liberally because they're less likely to be vulnerable to time of check to time of use (TOCTTOU) attacks on a multitasking system than the alternative Look Before You Leap (LBYL) paradigm.
Exceptions were devised to handle exceptional events, not to handle your main flow of control.
"Use the settings in the configuration file except when the configuration file does not exist." How is that not "exceptional"?
If you had written it in C++ instead of BASIC it wouldn't be offtopic.
"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" becomes legal C++.
A lot of the information present was "already solved" by not using C++ in the first place, but telling shops to "only use ISO C99/C11" is kinda difficult when none of the available compilers support the complete thing. C++11/14 are considered "not backwards compatible" with earlier versions of C/C++ since some things are changed. However compiler support is much better.
On Windows, only C/C++ should ever be used. On MacOS X/iOS only OBJC should be "used" for new projects, but C and C++ can be used if you don't want to use OBJC. On Linux... ugh where do I begin. Linux and FreeBSD projects should only be coded in C if at all possible. I see a lot of "bad" projects that run out the door as C++, but they're little more than frameworks layered over more frameworks, and many of the frameworks add nothing but overhead. It's like some people enjoy massive code bloat because they desperately need their own vanity wrappers every time a new programmer is added to the project because they don't understand another C++ programmers coding style. This damages open source projects right off the bat.
If you're not comfortable with C++, and you're not willing to write something in C, then don't try to use C++ in the first place. Maybe the project doesn't really need C/C++. Maybe it can be written with Python or or just Lua with C/C++ bindings to an existing library. But once you make this compromise, you also reduce the portability, because NO OS comes with a requirement to support any scripting language (save for Javascript if a GUI+Web Browser is installed.) Linux and FreeBSD used to come with Perl, sometimes Python, sometimes other things, but because of security concerns and maturity of build tools, these have largely disappeared.
Like given the current state of things, I'd rather see people use a subset of C# (eg Unity), Javascript or Swift on a portable runtime if the project isn't meant to be heavily optimized at the runtime level. Once there is a Swift runtime for Windows and Linux, I'm sure people will wholesale abandon flash (which was the only semi-portable runtime, but is absolutely awful at security because most flash developers are not programmers, but visual artists, and thus the there's a lot of security issues as a result of wanting the flash authoring tool to be easy to use.)
Nothing ensures that the config file exists, and your program is responsible for creating it.
You appear to state that the std::ios::fail() paradigm of C++, which allows an inconsistent stream object to continue to exist, is superior to the exception-on-failure paradigm of Python. Do I understand you correctly?
So good you Big Boys have created the Cyber War Domain with your Great Work(TM).
How would Lockheed Martin and Raytheon "grow" without your Great Work. How would they "advance" mankind without given the opportunity for Cyber WAR ?
Seriously, can somebody think about the Uniformed Shit-doing Professionals ? I mean, these folks want a career too. They have kids to feed. They have an ego to polish.
Let's don't deprive these folks by using memory safe languages ! Think about the MIC and all their hungry mouthes !
Also, Pascal was created a swiss man. Switzerland is way too less belligerent to be accepted as a civilized nation. Using Pascal is un-patriotic, therefore.
WAR - OUR GOD. HAIL WAR !
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?
Isn't this about 3 decades past due, and long past any window of opportunity to become really important?
Seriously, C++ needed this back in the 80's.
I was in college when the cfront ("C with Classes", later renamed "C++") preprocessor came out (1983). We continued to use C in class. (Um, making it a C class without "C with Classes".)
As I shifted to industry and specialized in embedded/real-time programming, I watched many bad C++ compilers appear. But even these compilers, when used correctly, enabled the use of many C++ features in firmware. (Burned into UV-EPROMs, and get off my lawn!)
By the early '90's a consensus was developing within the embedded community that there should be a standardized subset of C++ that would be "blessed" for embedded use, the main criteria being that only features that would keep us "running light, without overbyte" (relative to C) would be so blessed.
This notion caught on with several large companies, and many style guides for "Embedded C++" appeared, generally one for each revision of every different C++ compiler out there. But all that changed when the Japanese car makers made their presence known: They decided to sponsor an effort to specify a language to be called "EC++".
This effort started with great hopes (I was a minor contributor), but came to an abrupt end when we realized the Japanese actually wanted a fixed specification (for a new compiler), not one that would actively track the ongoing advances in C++ compiler technology. Which interested me not at all.
That was when I largely abandoned following the bleeding edge of C++ compiler developments for use in ROMmed code: The EC++ subset was too limited to be worth using (IMHO), and it was getting too difficult to track compiler advances while actually getting code written. And the ISO C effort was doing a great job cherry-picking many valuable concepts from C++.
I've been hoping for another industry effort to push C++ into my firmware, and I believe the C++ Core Guidelines may be precisely what I've been waiting for, or at least a giant step in that direction, assuming ISO C++ follows along. The Guidelines emphasize how to do what C++ does best, and they effectively bypass much of the cruft a 32 year old continuously evolving language accumulates.