4 ms·

I 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

by minimax 13y ago

I 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 ago
  True, 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 ago
    Go 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 ago
      There 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 ago
        Sure 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 ago
        Sometimes 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 ago
        I 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?
        pjmlp 13y ago
        Depends on the implementation. Don't mix languages with implementations. Currently there are two native compiler toolchains for Go, which only support a given set of OSs and computer architectures. Additionally some people written Go interpreters with another set of supported targets. So to answer your question, it would run on the embedded system if : 1 - the hardware could cope with Go runtime requirements 2 - it would be a supported target for one available native code toolchain
        stusmall 13y ago
        It depends on how "embedded" embedded means to you. I've talked to some people who call a CPE Linux/Atom box embedded and I know some people who don't consider anything with an OS embedded. I won't even touch that argument. :) But I used MMU-less uClinux as an example because it breaks a lot of assumptions that are made in a lot of code. No dynamic linking(which if I remember go doesn't support by default, or does it even support at all? I haven't written any in a year or two), no protected memory, and no real fork (vfork instead) crosses a lot of code off the list on what you can run. I don't know if go can support it, but I know that the current offical toolchains don't. There may be a feature go has that prevents them running on a platform like this, but it won't be GC. There are some GC'd languages that will run on this platform. C is great in that is makes very few assumptions and if written carefully can be extremely portable. The base language doesn't even assume there is an OS present. I've only run into one platform that had very little C support. It was a small 8 bit uC that had a very strange execution stack that made C as everyone uses it hard to efficiently implement.
      - zurn 13y ago
        The remainig issue for many of those is "need better GC". Apps like games could be brought in with near-pauseless GC that currently seems to exist only in Java land. (Yes you can work around the current GC's but this drives away some developers)
- alexk7 13y ago
  What'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]

by minimax 13y ago

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 ago
True, 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 ago
  Go 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 ago
    There 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 ago
      Sure 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 ago
        Sometimes 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 ago
        I 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?
        pjmlp 13y ago
        Depends on the implementation. Don't mix languages with implementations. Currently there are two native compiler toolchains for Go, which only support a given set of OSs and computer architectures. Additionally some people written Go interpreters with another set of supported targets. So to answer your question, it would run on the embedded system if : 1 - the hardware could cope with Go runtime requirements 2 - it would be a supported target for one available native code toolchain
        stusmall 13y ago
        It depends on how "embedded" embedded means to you. I've talked to some people who call a CPE Linux/Atom box embedded and I know some people who don't consider anything with an OS embedded. I won't even touch that argument. :) But I used MMU-less uClinux as an example because it breaks a lot of assumptions that are made in a lot of code. No dynamic linking(which if I remember go doesn't support by default, or does it even support at all? I haven't written any in a year or two), no protected memory, and no real fork (vfork instead) crosses a lot of code off the list on what you can run. I don't know if go can support it, but I know that the current offical toolchains don't. There may be a feature go has that prevents them running on a platform like this, but it won't be GC. There are some GC'd languages that will run on this platform. C is great in that is makes very few assumptions and if written carefully can be extremely portable. The base language doesn't even assume there is an OS present. I've only run into one platform that had very little C support. It was a small 8 bit uC that had a very strange execution stack that made C as everyone uses it hard to efficiently implement.
    - zurn 13y ago
      The remainig issue for many of those is "need better GC". Apps like games could be brought in with near-pauseless GC that currently seems to exist only in Java land. (Yes you can work around the current GC's but this drives away some developers)
alexk7 13y ago
What'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]