3 ms·

>but often C is a technical risk as there's so much more that can go wrong. That is objectively incorrect. There is much less that can go wrong with C, as the

>but often C is a technical risk as there's so much more that can go wrong. That is objectively incorrect. There is much less that can go wrong with C, as there is much less period. Everything that you can do incorrectly with C, you can do incorrectly with C++, plus 10 times more things that C++ introduced. The idea that C++ is safer because "we just won't do dangerous stuff" is silly, as any language is safe if you "don't do dangerous stuff", including C.

nicholassmith 14y ago
Alright, I probably phrased it wrong. C++ was written with specific safe guards against a number of common issues than can occur in C code, still it's more than possible to go horrifyingly wrong in C++ but the language has been designed (well, 'ish', it's still C++) to help avoid simple issues. The issues then come from the fact it's still is a fairly complex language and developers are often going to make mistakes. All languages are safe if you've written perfect code, but no one is perfect, C++ does try to catch some of the lower hanging fruit problems but if you're writing hoary code you're going to blow your foot off eventually.
- papsosouid 14y ago
  And with C you can use static analysis tools to avoid simple issues as well, plus you get a simple language so you aren't making the mistakes that you get with a huge complex language. OpenBSD is entirely C, and they have a far better track record than most C++ software.
pjmlp 14y ago
C++ allows to you to - use safe arrays with bound checking if you feel like to - use automatic memory management - pass arguments by reference and being sure they point to valid data - use proper strings without caring if the null character is missing C++ is only dangerous thanks to the C compatibility legacy. Don't use C'isms and the application will be a lot safer than doing pure C coding.
- eru 14y ago
  I am not sure about the reference passing, but the rest you can do in pure C, too. You can bound-check your arrays at run-time, by wrapping them in a struct and only accessing them with functions. There's even a proper (although conservative) garbage collector for C, while C++ usually boils down to reference counting. Even in C you are not restricted to the standard library to handle strings. C doesn't have to mean null-terminated strings. (And in C++, too, string literals give you the old-time bad strings.)
  - pjmlp 14y ago
    > You can bound-check your arrays at run-time, by wrapping them in a struct and only accessing them with functions. This is no longer a data type seen as a language type, but an Abstract Data Type as known in Computer Science. You are no longer using arrays, but a data structure made by yourself. > There's even a proper (although conservative) garbage collector for C, while C++ usually boils down to reference counting. If you are referering to Boehm-Demers-Weiser GC, it also works in C++. C++11 also has a GC API. > Even in C you are not restricted to the standard library to handle strings. C doesn't have to mean null-terminated strings. The moment you do this, you are the strange kind in town as all libraries expect C style strings as input. So it is conversion party any time you need to call those functions. > (And in C++, too, string literals give you the old-time bad strings.) Yeah, this is a consequence of C's compatibility that infected C++.
    - eru 14y ago
      > This is no longer a data type seen as a language type, but an Abstract Data Type as known in Computer Science. Yes, it's no longer a built-in data type. But non-builtin-types are perfectly fine, too. By the way, how do you get bounds checking in C++? I guess you use the same technique, but C++'s overloading makes it syntactically easier to hide that you are not using a built-in?
      - pjmlp 14y ago
        Yes, but that minor difference makes a huge difference in usability. Thankfully C++ is powerful enough that user types have the same rights as built-in ones.
jemfinch 14y ago
> Everything that you can do incorrectly with C, you can do incorrectly with C++ This isn't true. C++ doesn't allow certain implicit casts that C allows (e.g., from void* to T*).

nicholassmith 14y ago

Alright, I probably phrased it wrong. C++ was written with specific safe guards against a number of common issues than can occur in C code, still it's more than possible to go horrifyingly wrong in C++ but the language has been designed (well, 'ish', it's still C++) to help avoid simple issues. The issues then come from the fact it's still is a fairly complex language and developers are often going to make mistakes. All languages are safe if you've written perfect code, but no one is perfect, C++ does try to catch some of the lower hanging fruit problems but if you're writing hoary code you're going to blow your foot off eventually.

papsosouid 14y ago
And with C you can use static analysis tools to avoid simple issues as well, plus you get a simple language so you aren't making the mistakes that you get with a huge complex language. OpenBSD is entirely C, and they have a far better track record than most C++ software.

pjmlp 14y ago

C++ allows to you to - use safe arrays with bound checking if you feel like to - use automatic memory management - pass arguments by reference and being sure they point to valid data - use proper strings without caring if the null character is missing C++ is only dangerous thanks to the C compatibility legacy. Don't use C'isms and the application will be a lot safer than doing pure C coding.

eru 14y ago
I am not sure about the reference passing, but the rest you can do in pure C, too. You can bound-check your arrays at run-time, by wrapping them in a struct and only accessing them with functions. There's even a proper (although conservative) garbage collector for C, while C++ usually boils down to reference counting. Even in C you are not restricted to the standard library to handle strings. C doesn't have to mean null-terminated strings. (And in C++, too, string literals give you the old-time bad strings.)
- pjmlp 14y ago
  > You can bound-check your arrays at run-time, by wrapping them in a struct and only accessing them with functions. This is no longer a data type seen as a language type, but an Abstract Data Type as known in Computer Science. You are no longer using arrays, but a data structure made by yourself. > There's even a proper (although conservative) garbage collector for C, while C++ usually boils down to reference counting. If you are referering to Boehm-Demers-Weiser GC, it also works in C++. C++11 also has a GC API. > Even in C you are not restricted to the standard library to handle strings. C doesn't have to mean null-terminated strings. The moment you do this, you are the strange kind in town as all libraries expect C style strings as input. So it is conversion party any time you need to call those functions. > (And in C++, too, string literals give you the old-time bad strings.) Yeah, this is a consequence of C's compatibility that infected C++.
  - eru 14y ago
    > This is no longer a data type seen as a language type, but an Abstract Data Type as known in Computer Science. Yes, it's no longer a built-in data type. But non-builtin-types are perfectly fine, too. By the way, how do you get bounds checking in C++? I guess you use the same technique, but C++'s overloading makes it syntactically easier to hide that you are not using a built-in?
    - pjmlp 14y ago
      Yes, but that minor difference makes a huge difference in usability. Thankfully C++ is powerful enough that user types have the same rights as built-in ones.

jemfinch 14y ago

> Everything that you can do incorrectly with C, you can do incorrectly with C++ This isn't true. C++ doesn't allow certain implicit casts that C allows (e.g., from void* to T*).