3 ms·

Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it

Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.

pjmlp 11y ago
Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.
- Cshelton 11y ago
  Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of tooling for cross platform, both mobile and desktop OS's. I believe Go also has some fairly popular mobile cross platform libraries as well that are probably much further along than Rusts'. I can't say for Windows phone as I have never done anything for it and I think it's dead...
  - pjmlp 11y ago
    > But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the respective platform language. With Rust or Go AFAIK I need to use Mac OS X or GNU/Linux for cross-compilation. Need to compile that toolchain myself and write my own wrappers to OS APIs. Also not enjoying the same IDE experience isn't that much fun. > I can't say for Windows phone as I have never done anything for it and I think it's dead... Except the APIs are the same as Windows and XBox are moving to, even if WP10 is at the end of the road now with the last update misfortune. So if Rust or Go want a place in Windows Store for desktop and XBox apps, they need to get along with WinRT APIs. Yes, those languages will surely improve but if I have 1 hour to work on a side project, I rather spend that hour coding and not fixing toolchain issues. If I had more time, I would surely like to help to improve the situation, but sadly time is limited.
    - Tyr42 11y ago
      I just got Rust compiling for a linux kernel module. It wasn't too bad, though an inability to read C header files is kinda a pain. And for any target you are going to want to wrap things up in a "Rusty" api, as dealing with cstrings is kinda a pain. Still, it'd be a pain to go from C strings to C++ strings, and hook new/delete up to kmalloc/kfree.
    - Manishearth 11y ago
      > Need to compile that toolchain myself and write my own wrappers to OS APIs. Nah: https://users.rust-lang.org/t/multirust-0-8-with-cross-std-installation/4901 https://users.rust-lang.org/t/multirust-0-8-with-cross-std-i... Before this feature the cross libs existed, just that there was no UI for downloading and installing them.
- Manishearth 11y ago
  FWIW I really like "new C++" a lot and am quite hopeful for the ISOCPP stuff as well as C++ Concepts :)
- pcwalton 11y ago
  > Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. No, there aren't. Empirically, modern C++ projects are not memory safe. Maybe when you qualify it with this: > At least when using it alone or in small teams that value safety. But I suspect the reason it looks that way is actually this: Projects that are developed alone or with small teams tend to be less important projects that people don't try to attack and/or find memory safety problems in. The lack of people actively looking for memory safety problems makes it look like C++ projects are safe, but in reality they aren't. If solo/small team projects in C++ had anywhere near as many people looking for holes as big ones like browser engines, then they'd fall over too. I don't have any hard statistics for this, but given the consistent memory safety track record of C++ projects I think I'm more likely to be right here than wrong. I've written small projects in C++ and I don't think they're memory safe, even though I don't know of any areas where they aren't. I just know what the statistics are.
  - pjmlp 11y ago
    I fully agree with you, but my point is that until Rust achieves a certain parity with mobile OS C++ tooling the "good enough approach of C++14 and C++17" improvements will prevail, even among those that would rather use something else. Given myself as example, in spite of all my rants about security that you well know, I still use C++ as my portable business code between mobile platforms. However I always compile with all warnings as errors, fully embrace C++ STL types for safe programming and do regular static analysis, exactly to minimize as much as possible the errors that might still miss my attention. If I would be focusing just in a single platform, then I would surely choose between Swift, Java and C# respectively.

Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.

pjmlp 11y ago

Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.

Cshelton 11y ago
Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of tooling for cross platform, both mobile and desktop OS's. I believe Go also has some fairly popular mobile cross platform libraries as well that are probably much further along than Rusts'. I can't say for Windows phone as I have never done anything for it and I think it's dead...
- pjmlp 11y ago
  > But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the respective platform language. With Rust or Go AFAIK I need to use Mac OS X or GNU/Linux for cross-compilation. Need to compile that toolchain myself and write my own wrappers to OS APIs. Also not enjoying the same IDE experience isn't that much fun. > I can't say for Windows phone as I have never done anything for it and I think it's dead... Except the APIs are the same as Windows and XBox are moving to, even if WP10 is at the end of the road now with the last update misfortune. So if Rust or Go want a place in Windows Store for desktop and XBox apps, they need to get along with WinRT APIs. Yes, those languages will surely improve but if I have 1 hour to work on a side project, I rather spend that hour coding and not fixing toolchain issues. If I had more time, I would surely like to help to improve the situation, but sadly time is limited.
  - Tyr42 11y ago
    I just got Rust compiling for a linux kernel module. It wasn't too bad, though an inability to read C header files is kinda a pain. And for any target you are going to want to wrap things up in a "Rusty" api, as dealing with cstrings is kinda a pain. Still, it'd be a pain to go from C strings to C++ strings, and hook new/delete up to kmalloc/kfree.
  - Manishearth 11y ago
    > Need to compile that toolchain myself and write my own wrappers to OS APIs. Nah: https://users.rust-lang.org/t/multirust-0-8-with-cross-std-installation/4901 https://users.rust-lang.org/t/multirust-0-8-with-cross-std-i... Before this feature the cross libs existed, just that there was no UI for downloading and installing them.
Manishearth 11y ago
FWIW I really like "new C++" a lot and am quite hopeful for the ISOCPP stuff as well as C++ Concepts :)
pcwalton 11y ago
> Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. No, there aren't. Empirically, modern C++ projects are not memory safe. Maybe when you qualify it with this: > At least when using it alone or in small teams that value safety. But I suspect the reason it looks that way is actually this: Projects that are developed alone or with small teams tend to be less important projects that people don't try to attack and/or find memory safety problems in. The lack of people actively looking for memory safety problems makes it look like C++ projects are safe, but in reality they aren't. If solo/small team projects in C++ had anywhere near as many people looking for holes as big ones like browser engines, then they'd fall over too. I don't have any hard statistics for this, but given the consistent memory safety track record of C++ projects I think I'm more likely to be right here than wrong. I've written small projects in C++ and I don't think they're memory safe, even though I don't know of any areas where they aren't. I just know what the statistics are.
- pjmlp 11y ago
  I fully agree with you, but my point is that until Rust achieves a certain parity with mobile OS C++ tooling the "good enough approach of C++14 and C++17" improvements will prevail, even among those that would rather use something else. Given myself as example, in spite of all my rants about security that you well know, I still use C++ as my portable business code between mobile platforms. However I always compile with all warnings as errors, fully embrace C++ STL types for safe programming and do regular static analysis, exactly to minimize as much as possible the errors that might still miss my attention. If I would be focusing just in a single platform, then I would surely choose between Swift, Java and C# respectively.