5 ms·

C# is memory-safe by default. C++ will forever let you (and your coworkers, and library code you use/misuse) access memory outside array bounds and dereference

by _yosefk 11y ago

C# is memory-safe by default. C++ will forever let you (and your coworkers, and library code you use/misuse) access memory outside array bounds and dereference pointers to already-freed objects. This extends to C++'s advanced features (such as objects captured by reference in anonymous functions.) This is a big benefit of C# (and every other remotely popular language except C and C++; how C compares to C++ is a separate question.) Arguably, some systems cannot afford a garbage-collected language, but your comment kinda assumes you can choose between C# and C++.

Aleman360 11y ago
I work on UI for universal Windows apps where the choice is C#, C++, or JavaScript. Modern C++ is pretty nice if your team is ready to embrace it and leave old styles behind. I still use C# for utilities and prototypes but for production stuff, users' time is more valuable than mine.
- pcwalton 11y ago
  This comment fails to address the main point yosefk was making: that C++ is not memory safe, and C# is. In fact, it completely ignores the point in presupposing that C++ is for "production stuff" and C# is for "utilities and prototypes", when the point of memory safety is to make your code not fail in production.
  - Aleman360 11y ago
    Embracing Modern C++ (RAII, STL, range-based for loops) helps you avoid a big chunk of memory safety problems. Contracts and some of the stuff in the new Core guidelines take it further. Everyone's needs are different obviously. The stuff I work on has tons of users and start up perf and minimal memory usage are primary requirements. Most of our bugs are nullptr access violations or straight up programming errors that C# doesn't shield you from either.
    - pcwalton 11y ago
      > Embracing Modern C++ (RAII, STL, range-based for loops) helps you avoid a big chunk of memory safety problems. Not really. RAII still allows for dangling pointers/references. The STL is vulnerable to iterator invalidation. Ranges are likewise vulnerable. > Contracts and some of the stuff in the new Core guidelines take it further. How do contracts help memory safety? The ISO Core C++ bounds/lifetime checker does, yes, but as I mentioned in the other comment I don't know whether it is still going to be C++ in practice. > The stuff I work on has tons of users and start up perf and minimal memory usage are primary requirements. Those are valid reasons to use C++, yes. > Most of our bugs are nullptr access violations or straight up programming errors that C# doesn't shield you from either. C# doesn't make null dereference undefined behavior :)
      - blub 11y ago
        1) Using smart pointers makes it really hard to have dangling pointers. 2) The invalidation rules are pretty well known at this point, but I concede that it's much better to have compile-time validation. A good STL impl will have iterator debugging, which catches iterator invalidation. e.g: debug mode in GCC 3) Regarding null, you're theoretically right, undefined behaviour and all. In practice[1], accessing a null pointer/reference will result in a crash both in C# and C++. When developing Java apps (C#'s big brother), the biggest sources of bugs during development were null pointer exceptions and unhandled exceptions propagating to the event loop and killing the UI thread. [1] There are strange cases such as http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
        pcwalton 11y ago
        > Using smart pointers makes it really hard to have dangling pointers. No, it doesn't. std::vector<std::unique_ptr<int>> x; x.push_back(std::make_unique(1)); auto& y = *x[0]; x.clear(); std::cout << y; // use after free This is, of course, a toy example. For lots and lots of real examples, search Web browser engine bug trackers for UAF vulnerabilities. (They have been using smart pointers exclusively for a decade or so now.) > A good STL impl will have iterator debugging, which catches iterator invalidation. Valgrind and ASan catch UAF too and have been around for years and years. Yet we still have a ton of UAF vulnerabilities.
rhodysurf 11y ago
Some people (like myself) just prefer C++ to C#.
- paulddraper 11y ago
  That's fine. And surely you'll agree with the GP that they're not really comparable.
  - blub 11y ago
    They are both used for building UI applications on Windows, because there's a lot of existing C++ code, .NET used to be (not sure now) a major PITA to deploy and was slower to boot. It also allows one to expand to other platforms and operating system in a way that C# never could, in spite of toolchains like Mono, and the recent open sourcing of .NET. I would absolutely not choose C# for building a UI app even today.
    - pcwalton 11y ago
      > I would absolutely not choose C# for building a UI app even today. Even if memory safety is important to you (the point of this subthread)?
      - blub 11y ago
        I don't really think about "X safety", but rather about various quality attributes such as availability and resilience, perhaps also security in this case. These have to be evaluated and kept in balance with other attributes such as performance, portability, dev resources etc. I would personally prefer to use various engineering practices such as static and dynamic analysis, unit tests, etc rather than change programming languages. There's also the other side of this argument: my last project was Java. C++ would have allowed us to port more easily to other platforms (a current pain point) and get better performance in combination with OpenGL (another major pain point), however, the project constraints would have made it extremely difficult to bring a C++ project to market with the resources we had.
pcwalton 11y ago
> C++ will forever let you (and your coworkers, and library code you use/misuse) access memory outside array bounds and dereference pointers to already-freed objects. This extends to C++'s advanced features (such as objects captured by reference in anonymous functions.) Well, to be fair ISO Core C++ (mentioned in the blog post) with all safety profiles turned on is designed to fix this issue. I have my doubts about whether it'll actually succeed in still being C++ though, as it rules out so much valid modern code (and I also have doubts, or at least unanswered questions, about its soundness/expressiveness).
- lomnakkus 11y ago
  I hate to sound like a fanboy, but... exactamundo! I'm sure the C++ community will gradually work to address the (huge!) security issues through heroic effort, but it's doubtful that anything meaningful can be achieved when "undefined behavior" remains an acceptable definition of the semantics of an operation. EDIT: Don't get me wrong... I am in awe of the recent efforts of the C++ committee (and co.), and I hope they succeed in this endeavour!
  - pcwalton 11y ago
    > it's doubtful that anything meaningful can be achieved when "undefined behavior" remains an acceptable definition of the semantics of an operation. Well, I should be fair. I may be wrong here, but my understanding of ISO Core C++ plus all safety profiles is that this will no longer be the case: there will be no undefined behavior in this particular dialect of C++, assuming the effort to create this dialect succeeds.
    - lomnakkus 11y ago
      Yeah, that's my understanding as well... but I'm skeptical that this is actually possible (within reason) given the history of C++ and the sheer weight of legacy C++ code bases.
      - sho_hn 11y ago

by _yosefk 11y ago

Aleman360 11y ago

I work on UI for universal Windows apps where the choice is C#, C++, or JavaScript. Modern C++ is pretty nice if your team is ready to embrace it and leave old styles behind. I still use C# for utilities and prototypes but for production stuff, users' time is more valuable than mine.

pcwalton 11y ago
This comment fails to address the main point yosefk was making: that C++ is not memory safe, and C# is. In fact, it completely ignores the point in presupposing that C++ is for "production stuff" and C# is for "utilities and prototypes", when the point of memory safety is to make your code not fail in production.
- Aleman360 11y ago
  Embracing Modern C++ (RAII, STL, range-based for loops) helps you avoid a big chunk of memory safety problems. Contracts and some of the stuff in the new Core guidelines take it further. Everyone's needs are different obviously. The stuff I work on has tons of users and start up perf and minimal memory usage are primary requirements. Most of our bugs are nullptr access violations or straight up programming errors that C# doesn't shield you from either.
  - pcwalton 11y ago
    > Embracing Modern C++ (RAII, STL, range-based for loops) helps you avoid a big chunk of memory safety problems. Not really. RAII still allows for dangling pointers/references. The STL is vulnerable to iterator invalidation. Ranges are likewise vulnerable. > Contracts and some of the stuff in the new Core guidelines take it further. How do contracts help memory safety? The ISO Core C++ bounds/lifetime checker does, yes, but as I mentioned in the other comment I don't know whether it is still going to be C++ in practice. > The stuff I work on has tons of users and start up perf and minimal memory usage are primary requirements. Those are valid reasons to use C++, yes. > Most of our bugs are nullptr access violations or straight up programming errors that C# doesn't shield you from either. C# doesn't make null dereference undefined behavior :)
    - blub 11y ago
      1) Using smart pointers makes it really hard to have dangling pointers. 2) The invalidation rules are pretty well known at this point, but I concede that it's much better to have compile-time validation. A good STL impl will have iterator debugging, which catches iterator invalidation. e.g: debug mode in GCC 3) Regarding null, you're theoretically right, undefined behaviour and all. In practice[1], accessing a null pointer/reference will result in a crash both in C# and C++. When developing Java apps (C#'s big brother), the biggest sources of bugs during development were null pointer exceptions and unhandled exceptions propagating to the event loop and killing the UI thread. [1] There are strange cases such as http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
      - pcwalton 11y ago
        > Using smart pointers makes it really hard to have dangling pointers. No, it doesn't. std::vector<std::unique_ptr<int>> x; x.push_back(std::make_unique(1)); auto& y = *x[0]; x.clear(); std::cout << y; // use after free This is, of course, a toy example. For lots and lots of real examples, search Web browser engine bug trackers for UAF vulnerabilities. (They have been using smart pointers exclusively for a decade or so now.) > A good STL impl will have iterator debugging, which catches iterator invalidation. Valgrind and ASan catch UAF too and have been around for years and years. Yet we still have a ton of UAF vulnerabilities.

rhodysurf 11y ago

Some people (like myself) just prefer C++ to C#.

paulddraper 11y ago
That's fine. And surely you'll agree with the GP that they're not really comparable.
- blub 11y ago
  They are both used for building UI applications on Windows, because there's a lot of existing C++ code, .NET used to be (not sure now) a major PITA to deploy and was slower to boot. It also allows one to expand to other platforms and operating system in a way that C# never could, in spite of toolchains like Mono, and the recent open sourcing of .NET. I would absolutely not choose C# for building a UI app even today.
  - pcwalton 11y ago
    > I would absolutely not choose C# for building a UI app even today. Even if memory safety is important to you (the point of this subthread)?
    - blub 11y ago
      I don't really think about "X safety", but rather about various quality attributes such as availability and resilience, perhaps also security in this case. These have to be evaluated and kept in balance with other attributes such as performance, portability, dev resources etc. I would personally prefer to use various engineering practices such as static and dynamic analysis, unit tests, etc rather than change programming languages. There's also the other side of this argument: my last project was Java. C++ would have allowed us to port more easily to other platforms (a current pain point) and get better performance in combination with OpenGL (another major pain point), however, the project constraints would have made it extremely difficult to bring a C++ project to market with the resources we had.

pcwalton 11y ago

> C++ will forever let you (and your coworkers, and library code you use/misuse) access memory outside array bounds and dereference pointers to already-freed objects. This extends to C++'s advanced features (such as objects captured by reference in anonymous functions.) Well, to be fair ISO Core C++ (mentioned in the blog post) with all safety profiles turned on is designed to fix this issue. I have my doubts about whether it'll actually succeed in still being C++ though, as it rules out so much valid modern code (and I also have doubts, or at least unanswered questions, about its soundness/expressiveness).

lomnakkus 11y ago
I hate to sound like a fanboy, but... exactamundo! I'm sure the C++ community will gradually work to address the (huge!) security issues through heroic effort, but it's doubtful that anything meaningful can be achieved when "undefined behavior" remains an acceptable definition of the semantics of an operation. EDIT: Don't get me wrong... I am in awe of the recent efforts of the C++ committee (and co.), and I hope they succeed in this endeavour!
- pcwalton 11y ago
  > it's doubtful that anything meaningful can be achieved when "undefined behavior" remains an acceptable definition of the semantics of an operation. Well, I should be fair. I may be wrong here, but my understanding of ISO Core C++ plus all safety profiles is that this will no longer be the case: there will be no undefined behavior in this particular dialect of C++, assuming the effort to create this dialect succeeds.
  - lomnakkus 11y ago
    Yeah, that's my understanding as well... but I'm skeptical that this is actually possible (within reason) given the history of C++ and the sheer weight of legacy C++ code bases.
    - sho_hn 11y ago