Can C++ Be Safer? Bjarne Stroustrup On Ensuring Memory Safety (thenewstack.io) 110
C++ creator Bjarne Stroustrup "joins calls for changing the programming language itself to address security concerns," according to an article shared by Slashdot user guest reader:
In mid-January, the official C++ "direction group" -- which makes recommendations for the programming language's evolution -- issued a statement addressing concerns about C++ safety. While many languages now support "basic type safety" -- that is, ensuring that variables access only sections of memory that are clearly defined by their data types -- C++ has struggled to offer similar guarantees.
This new statement, co-authored by C++ creator Bjarne Stroustrup, now appears to call for changing the C++ programming language itself to address safety concerns. "We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library." The group still also supports its long-preferred use of debugging tools to ensure safety (and "pushing tooling to enable more global analysis in identifying hard for humans to identify safety concerns"). But that January statement emphasizes its recommendation for changes within C++.
Specifically, it proposes "packaging several features into profiles" (with profiles defined later as "a collection of restrictions and requirements that defines a property to be enforced" by, for example, triggering an automatic analysis.) In this way the new changes for safety "should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code." And this new approach would ultimately bring not just safety but also flexibility, with profiles specifically designed to support embedded computing, performance-sensitive applications, or highly specific problem domains, like automotive, aerospace, avionics, nuclear, or medical applications.
"For example, we might even have safety profiles for safe-embedded, safe-automotive, safe-medical, performance-games, performance-HPC, and EU-government-regulation," the group suggests. Elsewhere in the document they put it more succinctly. "To support more than one notion of 'safety', we need to be able to name them."
Stroustrup emphasized his faith in C++ in a 2020 interview. "I think C++ can do anything Rust can do, and I would like it to be much simpler to use," Stroustrup told the Association for Computing Machinery's Special Interest Group on Programming Languages.
But even then, he'd said that basic type safety was one of his earliest design goals -- and one he's spent decades trying to achieve. "I get a little bit sad when I hear people talk about C++ as if they were back in the 1980s, the 1990s, which a lot of people do. They looked at it back in the dark ages, and they haven't looked since."
This new statement, co-authored by C++ creator Bjarne Stroustrup, now appears to call for changing the C++ programming language itself to address safety concerns. "We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library." The group still also supports its long-preferred use of debugging tools to ensure safety (and "pushing tooling to enable more global analysis in identifying hard for humans to identify safety concerns"). But that January statement emphasizes its recommendation for changes within C++.
Specifically, it proposes "packaging several features into profiles" (with profiles defined later as "a collection of restrictions and requirements that defines a property to be enforced" by, for example, triggering an automatic analysis.) In this way the new changes for safety "should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code." And this new approach would ultimately bring not just safety but also flexibility, with profiles specifically designed to support embedded computing, performance-sensitive applications, or highly specific problem domains, like automotive, aerospace, avionics, nuclear, or medical applications.
"For example, we might even have safety profiles for safe-embedded, safe-automotive, safe-medical, performance-games, performance-HPC, and EU-government-regulation," the group suggests. Elsewhere in the document they put it more succinctly. "To support more than one notion of 'safety', we need to be able to name them."
Stroustrup emphasized his faith in C++ in a 2020 interview. "I think C++ can do anything Rust can do, and I would like it to be much simpler to use," Stroustrup told the Association for Computing Machinery's Special Interest Group on Programming Languages.
But even then, he'd said that basic type safety was one of his earliest design goals -- and one he's spent decades trying to achieve. "I get a little bit sad when I hear people talk about C++ as if they were back in the 1980s, the 1990s, which a lot of people do. They looked at it back in the dark ages, and they haven't looked since."
If you want Rust... (Score:2, Insightful)
Re: (Score:2, Informative)
It's not your language, you numpty, it's his.
Comment removed (Score:5, Insightful)
Re: (Score:3)
As the original inventor he definitely has a right to voice his opinion, but I'm not sure any programming language belongs to anyone ;-)
Yes, though I don't think our esteemed OP was thinking that deeply.
I must admit, I share the OP's view that it'd be better not to change C++ just to get it to do something that other languages do already. C++ is... what it is. People who love it genuinely seem to love it. At the same time, it's already a massive sprawling thing that very few people have a complete handle o
Re: (Score:3)
I must admit, I share the OP's view that it'd be better not to change C++ just to get it to do something that other languages do already.
That is the essence of C++. It's why the language is popular: because it has a lot of features. If a language feature is popular, eventually it will make it into C++.
Re: If you want Rust... (Score:2)
Rust isn't perfect either, but it's proven a point that garbage collection doesn't have to be some variant of mark and sweep. I'd rather see more Rust inspired languages.
I'm a bit puzzled by this comment. Rust doesn't have anything resembling a garbage collector. At all. Nor does it do implicit reference counting like swift. In rust, freeing unused memory is essentially the same as c, except it is done implicitly rather than explicitly (you can do it explicitly, but there's almost never a need to. The only time I've ever done that is to basically tell an MPSC channel that it's not needed anymore so that the receiver can terminate its loop, which ended up being short lived a
Re: (Score:2)
Likewise in C++ you can delete memory explicitly but with reference-counting smart pointers and RAII you rarely have to do it in many cases. Seems like a lot of C++ design involves a lot of object copying, though.
Re: (Score:2)
I rather find an issue author has to decide when to use a value copy vs. pointer/reference vs. smart pointer. That should be decided by a compiler based on its costs evaluations.
Re: (Score:2)
Seems like a lot of C++ design involves a lot of object copying, though.
Not since we got move semantics.
Re: (Score:2)
Rust doesn't have anything resembling a garbage collector.
It actually does. Say you define a recursive structure like a list, create one consisting of numerous cons cells allocated from the heap, and store a reference to the head of it in a variable. Now clear that variable, or store a reference to a different list in it, or let it go out of scope. All the cons cells in your list will be automatically freed. Something like a garbage collector right?
Now, this is not a garbage collector but it is definitely something like a garbage collector. And it is quite fascina
Re: If you want Rust... (Score:2)
Now clear that variable, or store a reference to a different list in it, or let it go out of scope. All the cons cells in your list will be automatically freed. Something like a garbage collector right?
That doesn't really sound like one to me. When I think garbage collection, I think of references being scanned at a (typically) regular interval and/or after a certain condition being met, and references that are no longer used getting freed.
Cons won't do that. Everything will just be recursively freed, no scanning needed.
Re: (Score:2)
Ref counting garbage collection is a thing. Rust also has that. OP said "nothing like a garbage collector" and that is not true.
Rust did have a garbage collector in its early days and it was removed. Turns out, the kinds of patterns gc supports aren't important to a wide swath of systems programming situations.
Re: If you want Rust... (Score:2)
If reference counting is garbage collection, then literally every language has garbage collection of some sort. But actually rust wasn't intended to be a systems language early on, it was just intended to be a language that prevents common footguns, particularly with concurrency. Over time, as the borrow checker was fleshed out, garbage collection was needed less and less. Until it just wasn't needed anymore.
Re: (Score:2)
it just wasn't needed anymore
That's debatable. At least you can point to c and c++ and say, those guys get by without it too. Getting by is not the same as not needing.
Re: If you want Rust... (Score:2)
Either way, rust just plain doesn't need it. If rust needed garbage collection, they wouldn't have gotten rid of it in early development. In fact, I'd argue that garbage collection actually breaks most of the greatest benefits of the borrow checker and lets programmers get away with really sloppy coding practices.
Re: (Score:2)
Careful not to get yourself into an echo chamber.
Re: (Score:2)
This site is the closest thing to social media that I actually use. If I was in an echo chamber, would you be here?
Re: (Score:2)
> At the same time, it's already a massive sprawling thing that very few people have a complete handle on.
That is a problem for Microsoft (and G++ implementors), not me or my team -- we can always agree not to use features we don't understand, and to incorporate new ones experimentally when we are ready.
That said it might be handy if the compiler had a checkbox (or command line switches) for which major and minor features to allow, like they do with exceptions and warnings and a bunch of other things. If
Re: (Score:2)
That's the funny thing about something that is used by others: Everyone has their own preference for where they would like to see future development go.
* A creator ignoring the feedback of users can become out-of-touch with the actual needs of the users, and
* Users "hijacking" the design can lead to design-by-committee.
All successful art, which I say the design of a (Programming) Language is both Art and Science, is a blending between the creator's vision and the user's actual needs.
Without users your lang
Re: (Score:2)
Without users your language would be dead. The hard part is knowing how tell the difference between bad feedback and good feedback.
Indeed! And ignoring new developments to keep very change averse users happy will, if not kill the language, reduce it firmly to history. Maybe C++ will become the new COBOL anyway, but I hope not. Rust has some brilliant ideas, that anyone managed to make a language memory and race safe and comparable to C++ is no mean feat. But you can't do something as basic as swapping in Ru
Re:If you want Rust... (Score:4, Insightful)
Right. I thought that was the whole point of Rust.
Well, that and escaping all the C++ legacy insanity.
Re: (Score:2)
Rust seems to have little over modern C++. If you want Rust then just use the equivalent modern C++ idioms for the same benefit. The only way Rust makes sense to me is if you compare it to C or C++98.
Re: If you want Rust... (Score:2)
Then it wouldn't be C++ any more (Score:2)
Re: (Score:2, Funny)
Re:Then it wouldn't be C++ any more (Score:4, Funny)
Hey Chat-GPT, please generate an incoherent, rambling rant about programming languages with reference to incrementing version names.
Re: (Score:3)
As you wish:
Re: (Score:2)
Huh, it's kind of like a slashdot post but more coherent and grammatical.
The problem with AI at the moment it is can't replicate some of the batshit loonyness we get here. That, for now, is safely the preserve of humans.
Re: (Score:3)
I think it can be salvaged, try:
(C++) - C
That should always be -1, regardless of the initial value of C.
-1 seems like an appropriate name because I, for one, won't be using it. Also, when seeking help, users will need to search for "minus one lang", which also seems appropriate.
Re: (Score:2)
Might not be, if C is float or you set it to NaN.
Re: Then it wouldn't be C++ any more (Score:2)
Re: (Score:2)
This is exactly right. As long as people use C-only features, C++ cannot be memory or even type safe.
On the other hand, C++ has become so abstract that compile-time errors abound and can be incredibly hard to debug.
Re:Then it wouldn't be C++ any more (Score:4, Insightful)
And I'd rather have "hard" to "debug" "errors" at compile-time than at run-time. They're not "errors" if they're at compile-time", because they stop those errors from making it in in the first place.
Re: (Score:2)
More than that, I'd say it's main advantage is that it evolved organically over many years, which gives it both utility and some sort of charm which inspires people to do great things with it, in the same way that organic cities like London or NYC are great to live and do business in (the current ideologically caused problems will pass), unlike large faceless cities built on some architect's or comittee's idea.
Re: (Score:2)
And just like living in London or NYC costs so much you need an immense investment to be able to do so, so does C++ require an enormous investment in learning to be able to make use of properly.
I'd rather spend my effort (and money) on something fun than on living in (or using) something that has "evolved organically" into an insanely costly proposition.
Re:Then it wouldn't be C++ any more (Score:5, Insightful)
What Bjarne and others are proposing is not the elimination of C compatibility. Even today it's absolutely vital, even for new projects, since there are so many C libraries you might need to use. Rather, it's creating different safety modes for C++. So I think you can write a wrapper for a C library, and then create a compile-time boundary layer there, and anything outside that boundary might have different rules for what's allowed, restricting C++ to a set of language features and techniques that prevents most memory or other obvious errors.
This tends to be how many C++ users tend to write their code anyhow. We're essentially just talking about enforcing these practices with the compiler. That's already a big part of C++ - using the compiler to help prevent code mistakes. Rust has taken this concept to the next level, so they're looking at ways to incorporate some of that next-level safety to C++.
Essentially, C++ would be a modal language (they call these "profiles"). To me, that makes a lot of sense as a reasonable way to move forward and evolve the language into something that can leave a lot of legacy cruft behind, and isolate it behind specified gates.
Re: (Score:2)
So basically, turning C++ into a Rust clone.
We have come full circle.
putting a safety strap on your chainsaw (Score:4, Informative)
And then believing it's "safe to cut down tall trees (ignoring how they lean)..." Even if a memory-safe version of C++ could be produced, that doesn't solve the problem with the tons of memory-unsafe code and libraries.
Comment removed (Score:4, Interesting)
Re:putting a safety strap on your chainsaw (Score:4, Insightful)
The advantage of Rust (or Ada or any other memory-safe language) is that a call within the language preserves the properties of the language. (Sure, you can call C from Rust or Ada, but it's obvious when you do so you're leaving the memory-safe world.)
A MUCH BETTER approach, IMHO, is to -replace- those libraries with ones done in a memory-safe language. (And I bet you'll find latent bugs in the older version.) Then the language itself puts forward a 'contract' with respect to the properties of the language.
Re: putting a safety strap on your chainsaw (Score:3)
Re: putting a safety strap on your chainsaw (Score:2)
All compiled with exceptions turned off ;)
Re: (Score:3)
Ada83 put A LOT of work into language definitions for both fixed-point and floating-point arithmetic. Ada95 added extended decimals (enough to calculate national debt to the nearest penny :-)) Within the limits of the numeric models (e.g. what happens when a value lies out of the 'model numbers' that can be represented in fixed-point, or the change in accuracy over values in floating-point), the language did that preserving type safety and memory safety. Developers doing numeric computation in Ada learned
Re: putting a safety strap on your chainsaw (Score:2)
Re: (Score:2)
If you disable checks and write bad code, bad things can happen. The numeric value overflowed, and that check was disabled.
"The internal SRI software exception was caused during execution of a data conversion from a 64-bit floating-point number to a 16-bit signed integer value. The value of the floating-point number was greater than what could be represented by a 16-bit signed integer. The result was an operand error. The data conversion instructions (in Ada code) were not protected from causing operand er
Re: putting a safety strap on your chainsaw (Score:2)
Re: (Score:2)
This specific check was disabled, so the value loaded into the integer was garbage. Otherwise, the language REQUIRES a constraint check to see if the value from the floating point variable will fit into the (signed 16 bit) integer. From the report cited above, " a data conversion from a 64-bit floating-point number to a 16-bit signed integer value. The value of the floating-point number was greater than what could be represented by a 16-bit signed integer."
Ada83 RM, section 4.6 on conversions says "A conv
Re: (Score:2)
declare .. 2**15; for 16_bits'size use 16;" := to_16_bits (some_big_assed_float); := 16_bits'last; -- largest represe
16_bit_variable : 16_bits; -- presumably "type 16_bits is range -2**15 - 1
begin
16_bit_variable
-- can raise constraint_error
exception
when Constraint_Error =>
-- what do we do now, Batman? Use the max value in the integer?
16_bit_variable
Re: putting a safety strap on your chainsaw (Score:2)
Re: putting a safety strap on your chainsaw (Score:2)
Re: (Score:2)
How about not-std?
Re: putting a safety strap on your chainsaw (Score:2)
Talking of MS, thereâ(TM)s Managed C++, which was replaced by C++/CLI.
Re: (Score:2)
Re: (Score:2)
Very true! But in a multi-developer, long-lived code environment, language support is a huge advantage.
Put up, or shut up. (Score:1)
Yes, you can do stupid things in C++. But if you stick to new and delete operators and have loose pointers laying around, C++ is fine. Remember that memory leaks are impossible in Java. Rust advocates bang on about safety, but just have examples of bad practice in C++. In my job, I see horrible code in Java, Javascript, and C/C++ everyday. What is it, exactly, that prevents people from writing really poor code in Rust?
Re:Put up, or shut up. (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
But if you stick to new and delete operators and have loose pointers laying around, C++ is fine
It most certainly is *not* fine.
For example, go read up on the twisted maze of iterator invalidation rules you have to keep in your head.
Re: (Score:3)
Remember that memory leaks are impossible in Java.
They aren't, really. People put things into a queue, and forget to take them out, and over time the Java program takes up more and more memory.
You might say that's not a "real" memory leak, because the program still knows where the memory is, but actually there is no such thing as a "real" memory leak, since every C program knows where the memory is, there are pointers to it within the program (inside the malloc data structures). The problem in Java or C is that the memory has been allocated, is no longer
Re: (Score:2)
The trouble seems to be kids who think that because they're using a language like Java (or C# or JavaScript or Python or ... ) that they don't need to think about memory. They honestly believe they can just do whatever and the compiler or runtime will work it all out. I'm always amazed at how much completely pointless allocation and deallocation they manage to cram in to even simple projects. Worse, some modern APIs even demand it!
The trend for the last 20 years or so has been 'be wasteful and super care
Re: (Score:2)
My preferred solution is to set a (relatively small) maximum size on a queue. There's always an implicit maximum size, even if you preten
How many people even use smart pointers ? (Score:2)
But do most programmers use them ?
Re: (Score:3)
Of course, I would recommend using an elegant language like C, but most people don't like elegance.
Re: (Score:2)
There's nothing 'elegant' about C when you're working with strings or re-implementing linked lists for the unmpteenth time.
Re: (Score:2)
Re: (Score:2)
Yes there is, because it gets easier every time. Meanwhile, the same C++ expression can have a multitude of meanings:
i++;
Does this code:
Re: (Score:2)
It's even worse. What does f() do???
a small corner of memory safe (Score:4, Insightful)
Using C safely in say an environment where 32 bit words might exist with 16 bit words that might exist with 8 bit words in a given environment is essentially on the programmer to at know to check for strangeness. Not caring at all really means " someone else will fix this when it breaks".
Safety is between the ears (Score:4, Insightful)
In embedded work, or even anything that touches hardware, passing bare pointers around is very much a feature.
Re: (Score:2)
Re:Safety is between the ears (Score:4, Informative)
What has happened in the last decade is that the state-of-the-art for compile-time and static analysis has improved significantly, and bare pointers lack what is needed to make use of those capabilities. It sounds like Stroustrup started out from the position that "Hey, C++ can already do all this stuff you just have to use the right kinds of pointers" and now he has come around to "Okay well, maybe we need some additional language semantics to make best use of this." If the creator of the language is starting to come around to this concept, then the rest of us should too.
Re: Safety is between the ears (Score:2)
Sort of. Bare pointers are still faster than many abstractions you might want to use. The thing that makes a language "fast" is your ability to pass around the minimum amount of data through the minimum number of function calls.
If you can ensure the safety statically that gets you some of the way there, but in cases where things like buffer sizes vary at runtime the safety comes with an extra function call and conditional jump.
On the rare but not too rare case where that occurs inside the inner loop of some
Re: (Score:2)
"++ code can pass smart pointers that compile down to the exact same code as passing the bare pointer, but provide compile-time protection mechanisms"
Shared pointers are a run time mechanism , not compile time. If you don't know this then perhaps discussing the merits of C++ and pointers isn't for you.
Re: Safety is between the ears (Score:2)
Unique ptr is also runtime sock puppet. Want a 3rd try? Or maybe just give up before you die in that hole.
Re: (Score:2)
I thought unique_ptr was a zero-overhead abstraction, so I tested it. I wrote a simple main() that used a bare pointer, and another that used unique_ptr. Using Visual Studio 2022, when using unique_ptr, there were 2 differences:
1) The compiler inserted 3 instructions to create a security check cookie, then 3 more instructions to call __security_check_cookie. The cookie itself consumed 16 bytes of additional stack. I don't know why it chose to do this in the unique_ptr case -- perhaps it is triggered by
Re: (Score:2)
The original comment was BS written by someone who doesn't have a clue.
HTH.
As for scropt kiddie - I've been doing C++ since the 90s sock puppet.
Re: (Score:2)
Perhaps you should go an aquaint yourself with what a unique_ptr does particularly with assignments from one to the other then let me know if you think it'll produce the exact same code as if someone just used a plain pointer.
The problem with people like you is you have a little knowledge but make the mistake of thinking you have a lot.
Re: (Score:2)
What gets me is that having been an assembly language programmer, I feel like these arguments are pointless. I can implement a class with shared pointers in assembly, but I don't because I know that the compiler will automatically make the same optimizations I would have made anyway. Bjarne Stroustroup has been thinking of the performance impact on changes to C++ for the past 20 years - which might explain why some people feel like it's taking too long. But Bjarne was very aware that the std:: namespace
Re: (Score:2)
There's a middle-ground solution taken by a few languages (Rust, Swift) that allow passing raw pointers or manipulating memory directly under an unsafe modifier. Syntax differs, but the core idea that seems to have merit is that the developer should explicitly announce to the compiler (and to any readers) "I am taking responsibility for safety, get out of my way".
That seems a better compromise than either saying "100% the code is potentially unsafe (C/C++)" or "you cannot access unsafe primitives (Java with
Sure and it can also have usable exceptions (Score:3)
Will it though?
Look at the incomprehensible wall of musts and musts not on page 6 of P2759R0 and the resistance to subsetting. How do you provide actual guarantees on out of bounds access, mutability and UAF within all that? Guidelines sure, you can write a lot of those ... but compile/runtime guarantees?
Wrong Layer (Score:2)
Re:Wrong Layer (Score:4, Interesting)
If you want a safe version of C++, propose a standard 'safe' library which, if you develop using its APIs, you get all the safety you want.
STL already does that by default on many implementations.
eg, Try going out of bounds or keeping an iterator after you destroy a container in Visual C++. It will check for that and throw exceptions.
Circle! (Score:2)
If I understand the broad strokes here, this has already been done in circle [github.com].
It's compatible with C++ and allows piecemeal addition & mix-and match of features as well as editions which sound like the profiles he mentions.
Wanting things fixed in the "old" version/language (Score:2)
At one software company I worked for in the medical space, we would often get complaints from doctors (users) about bugs in the software. Doctors are notorious for not being willing to update their software, instead sticking with years-old versions. We would tell them that the issues were fixed in the latest version, so "please just update, and let us know if you still see the issue." Their response? "We don't want the new version, we want you to fix the *old* version!"
That's not how it works. When you fix
Re: Wanting things fixed in the "old" version/lang (Score:1)
Re: (Score:2)
Of course. The illustration was a true story, but just an illustration here. It's not a problem that needs to be solved.
Re: (Score:2)
"We don't want the new version, we want you to fix the *old* version!"
Newer versions usually have changes in user interface, too.
They don't want those.
Re: (Score:2)
Of course, that's exactly what they meant. But the two things are, of necessity, tied together. There's only so long an "old" version can be maintained, nobody can afford to do that. And sometimes the "fix" requires additional data points or fields that only exist in the "new" version.
In the subject at hand, C++ developers want the "fix" for memory safety, but that requires a completely new foundation that would make it not C++.
Re: (Score:2)
Newer versions usually have changes in user interface, too. They don't want those.
I was recently talking to my biggest customer, and the discussion migrated to the user interface. I used the old joke, "Programming is like sex. Make one mistake and you support it for life." I told him that I've learned over the years that users (myself included, when I'm in that role) HATE user interface changes. Once I put a GUI in place, it stays that way forever. It stays that way even if I think it would be more efficient to change it to something else.
I even have qualms about adding additional ways t
Re: (Score:2)
We don't want a hip replacement! We want you to fix the old hip :-) :-)
Re: (Score:2)
Precisely.
Re: (Score:2)
Microsoft use the same argument about WIndows. However there's more to upgrading than just fixed bugs as I'm sure you know.
Re: (Score:2)
Of course. But no company, no matter how wealthy, can afford to separately maintain each and every version indefinitely. Eventually, users will be forced to move on.
Also, bug fixes often depend on the context. It may be that a "bug" in the old version required new fields that only exist in the "new" version. Retrofitting the old version in many cases turns the old version...into the new version.
This is the future (Score:2)
Packing constraints and analysis into tools and compilers enabling a configurable suite of guarantees you require is unquestionably the future. Analysis becomes more capable over time granting more freedom to developers to meet same constraints with less artificial restrictions.
The benefit is constraints can be enabled for an existing codebase and work done incrementally over time on changes to meet constraints.
This is opposed to rewriting everything in some other language that only gives you x when in fac
Good. But only if people are going to use it. (Score:5, Insightful)
Adding syntactic sugar to validate programs helps as long as people use it. How many C++ projects use "override" keyword? If you look at the Github - not many.
The problem of C++ its complexity. To use language facilities you need to know them and understand them. Even without std (almost wrote STL, so you see how long ago I started working with it) learning it all is a huge task.
For now Rust *appears* simpler, but wait a few language releases. It solves *some* of the memory issues that can be solved with std or some specific purpose libraries in C++, but introduces other problems. After using Go for awhile, I understand how easily you could write memory- or type-unsafe program, despite built-in memory and type safety. The features of the language are good, but they are not panacea. Good programming practices are.
Re: (Score:2)
How many C++ projects use "override" keyword?
Did you take into account that most C++ code don't use virtual functions because it is unnecessary in most cases?
Re: (Score:3)
You can also write memory unsafe code with shared_ptr. This person managed to get a double free: https://stackoverflow.com/ques... [stackoverflow.com]
I would be surprised if Rust allowed something like that to compile.
I agree and disagree about "good programming practices" being the answer. They prevent tons of bugs but bottom line is the code is being written by humans, who are notoriously buggy systems that have some nonzero error rate per kLOC. I like offloading safety work to a compiler that never gets tired or distracted.
Oh GOOD, MORE syntax (Score:3)
Maybe we can tack another Turing-complete language onto it. Or maybe we just need to add more arcane syntax to the templates themselves, like sprinkling some %% around.
Look, you've got C, which is small and lean and dangerous. It's a sharp knife, and you can get some very delicate work done with it, but it's easy to cut yourself if you aren't paying attention.
And then you've got newer languages like Rust which are difficult to learn, but make some promises and seem to be able to deliver on them. I don't have a good metaphor for these languages; I haven't used them enough, but it seems clear that it has a purpose and people appreciate it.
C++ is already a big language, doing big language things, and it's fine at what it does, but trying to promise even more things just makes it less and less comprehensible. It's one of those Swiss army knives that has a zillion blades and some of them are really hard to even understand, and for some reason they keep adding MORE blades to fix the problems that the other blades caused, or just because they saw a really cool knife somewhere else and wanted to roll it in.
One of the guiding principles of the language was that you don't pay for what you don't use, but it's getting even harder to decide what's even worth paying for anymore. I saw a C++ talk on a C++ 2.0 kind of syntax and I think maybe it's the way of the future. There are a lot of very smart people working on C++ as it stands, and maybe it's time to start thinking about working on something new. Nothing lasts forever, and sometimes the decisions of the past are best left there.
Re: (Score:2)
Re: (Score:2)
There's ALWAYS more syntax. I've been programming C++ professionally for more than 20 years. I'm working in C++ as we speak. For every little bit that's deprecated, we get more syntax, always more syntax.
And look, some of it is good. I like lambdas (but I'm also a lisp programmer, so that's no surprise), but I've only ever had to learn more, as well as more cryptic syntax over the years. There are some shortcuts now, sure--we get some template inference stuff, etc.--but in general, the language is more verb