5 ms·
I think we can be a little bit more charitable towards C++. Modern compilers will let you know if you try to do something as obviously incorrect as returning a
by minimax 13y ago
I think we can be a little bit more charitable towards C++. Modern compilers will let you know if you try to do something as obviously incorrect as returning a pointer to a stack variable.
$ cat > foo.cpp <<EOF
> int *dangling(void)
> {
> int i = 1234;
> return &i;
> }
> EOF
$ clang++ -Werror -c foo.cpp
foo.cpp:4:13: error: address of stack memory associated with local variable 'i'
returned [-Werror,-Wreturn-stack-address]
return &i;
^
1 error generated.
- steveklabnik 13y agoThank you! Maybe I should explicitly show a new/free example instead, or does that end up having a similar warning? I haven't written serious C++ in years, so I have some blind spots. Others on the Rust team have done quite a bit, so they tend to pick up my slack in exactly this manner.
- minimax 13y agoI wasn't trying to undermine your argument. Rust is solving real problems. Use after free and double free are still issues in the C world. In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.
- pcwalton 13y ago> In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes. Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.
- pjmlp 13y agoTrue, and hopefully the likes of D, Rust and Go will improve the situation. In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.
- masklinn 13y agoGo being mandatorily GC'd I don't think it's relevant to the issue of improving on C/C++ for their existing use cases.
- pjmlp 13y agoThere are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.
- masklinn 13y agoSure but if a GC'd language is acceptable for the application, the problem "was solved" years ago, the tooling not being the issue anymore.
- stusmall 13y agoSometimes these applications are written in C for the extreme portability rather than performance. I have a couple open source projects in mind that support a huge selection of OSes and hardware configurations that would not be possible with some of the other current higher level language but almost every platform supports C to some degree. I don't know how well Go supports weird configurations like MMU-less uClinux installs but the GC wouldn't be what is breaking it.
- Jhsto 13y agoI don't really understand concepts of low level languages, but I've had a perception that if I'd wrote a program in Go using the standard libary and compiled it with go build it would run on all imaginable platforms. Now, as far as I've understood your comment suggests that I'm wrong. Lets suppose that some corporation would download the binaries of my project and use it on an embedded system, would it run?
- alexk7 13y agoWhat's wrong with this use-case? The object will be destroyed and no pointer to it will exist after the clear.
- deleted 13y ago[deleted]