6 ms·

Can't wait for modules. Header files are the worst. Also really excited for co-routines. I never liked using promises. Wow, had no idea ranges and contracts a

Can't wait for modules. Header files are the worst. Also really excited for co-routines. I never liked using promises. Wow, had no idea ranges and contracts are on the table too. With all this stuff, C# is really losing its appeal.

rhodysurf 11y ago
Yeah I want modules and contracts badly
edwinnathaniel 11y ago
To me it has always been the tooling and its ecosystems around the language that matters, not some of these advanced features... So C# might lose its appeal to you specifically but not to many people ;)
- Aleman360 11y ago
  True, C# tooling is an order of magnitude better. Still hate IDisposable and events using strong references.
joebaf 11y ago
Lots of important stuff is being discussed/voted/cleaned up... hope modules, ranges and contracts will meet the deadlines to be in cpp17
_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 :)

rhodysurf 11y ago

Yeah I want modules and contracts badly

edwinnathaniel 11y ago

To me it has always been the tooling and its ecosystems around the language that matters, not some of these advanced features... So C# might lose its appeal to you specifically but not to many people ;)

Aleman360 11y ago
True, C# tooling is an order of magnitude better. Still hate IDisposable and events using strong references.

joebaf 11y ago

Lots of important stuff is being discussed/voted/cleaned up... hope modules, ranges and contracts will meet the deadlines to be in cpp17

_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 :)