4 ms·

A lot of things pointed out in the article shouldn't prevent anybody from starting a project in modern C++. First of all, usage of raw arrays is discouraged, if

by jupp0r 7y ago

A lot of things pointed out in the article shouldn't prevent anybody from starting a project in modern C++. First of all, usage of raw arrays is discouraged, if you use std::array or std::vector, there are way less ways to shoot yourself. Same goes for manually managing memory, you shouldn't ever have to call delete on your own nowadays. Most other problems mentioned in the article are ABI compatibility and dynamic library loading problems that are super specific to Windows and that very few people should ever have to deal with. This is going to painful no matter what language you are using. Win32 API is no fun, hardly C++s fault.

serial_dev 7y ago
I see these kinds of comments very often ("Ackchyually, feature X of C++ has been discouraged for at least Y years now and if you still use it, you are doomed"). I used to learn C++ at the university (~5 years ago) and have read multiple books on that, however, I would have no idea how to start using the language again and how to figure out which patterns are OK and which ones are discouraged and what should I use instead. All "modern C++" books I found are 10+ years old. There seem to be so many opinions out there on forums, but I don't see a comprehensive, community-approved place (book or website) where I can learn and understand the differences between the many ways of doing the same thing.
- AlexeyBrin 7y ago
  > I don't see a comprehensive, community-approved place (book or website) where I can learn and understand the differences between the many ways of doing the same thing Check C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... which is a community approved collection of best practices for modern C++.
- wvenable 7y ago
  > however, I would have no idea how to start using the language again and how to figure out which patterns are OK and which ones are discouraged and what should I use instead. I jump into C++ every 5 years or so and I haven't found this to be that big of a problem. Reading a few websites got me up to speed really quick. Having worked mostly in modern managed languages lately, I just look for the C++ solution that is as close to that as I can and it's now very easy to find that. My C++ code looks very much like my C# code. My own state of mind when working with C++ is that it feels good then do it, if it feels bad then go out and see if there is a better way.
praptak 7y ago
I spent the last 6 years writing C++. Would not recommend for a new project, unless some very specific conditions are met. The main reason being the memory (un-)safety and the costs it generates.
- einpoklum 7y ago
  I wonder what kind of C++ you've been writing. Memory safety is much less of an issue than it used to be. When you use spans over raw arrays (or vectors etc.) - you can have bounds checking; if you use std::array - you won't make invalid accesses. As for memory management - that's essentially a solved problem, you just use smart pointers, and generally not allocate yourself. It's true that you _can_ shoot yourself in the foot with C++; but it's becoming increasingly more difficult to do so unintentionally.
  - bb88 7y ago
    > I wonder what kind of C++ you've been writing. Last I checked there's still a lot of C++ code in legacy production systems -- and a lot that has never ever used a smart pointer.
    - einpoklum 7y ago
      That was exactly my point; GP says they've been writing C++ for the past 6 years, but seems to be talking about legacy code.
      - praptak 7y ago
        Nope, I meant modern C++. Granted, it has multiple mechanisms to prevent memory corruption but they are not watertight.
  - praptak 7y ago
    vector::operator[] does not check bounds, neither do some libraries that I have to use, notably Google Protocol Buffers can turn a logic bug (bad index to repeated field) into an access to unallocated memory. Best practices do not fully eliminate segfaults. This is a practical observation.

by jupp0r 7y ago

serial_dev 7y ago

I see these kinds of comments very often ("Ackchyually, feature X of C++ has been discouraged for at least Y years now and if you still use it, you are doomed"). I used to learn C++ at the university (~5 years ago) and have read multiple books on that, however, I would have no idea how to start using the language again and how to figure out which patterns are OK and which ones are discouraged and what should I use instead. All "modern C++" books I found are 10+ years old. There seem to be so many opinions out there on forums, but I don't see a comprehensive, community-approved place (book or website) where I can learn and understand the differences between the many ways of doing the same thing.

AlexeyBrin 7y ago
> I don't see a comprehensive, community-approved place (book or website) where I can learn and understand the differences between the many ways of doing the same thing Check C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... which is a community approved collection of best practices for modern C++.
wvenable 7y ago
> however, I would have no idea how to start using the language again and how to figure out which patterns are OK and which ones are discouraged and what should I use instead. I jump into C++ every 5 years or so and I haven't found this to be that big of a problem. Reading a few websites got me up to speed really quick. Having worked mostly in modern managed languages lately, I just look for the C++ solution that is as close to that as I can and it's now very easy to find that. My C++ code looks very much like my C# code. My own state of mind when working with C++ is that it feels good then do it, if it feels bad then go out and see if there is a better way.

praptak 7y ago

I spent the last 6 years writing C++. Would not recommend for a new project, unless some very specific conditions are met. The main reason being the memory (un-)safety and the costs it generates.

einpoklum 7y ago
I wonder what kind of C++ you've been writing. Memory safety is much less of an issue than it used to be. When you use spans over raw arrays (or vectors etc.) - you can have bounds checking; if you use std::array - you won't make invalid accesses. As for memory management - that's essentially a solved problem, you just use smart pointers, and generally not allocate yourself. It's true that you _can_ shoot yourself in the foot with C++; but it's becoming increasingly more difficult to do so unintentionally.
- bb88 7y ago
  > I wonder what kind of C++ you've been writing. Last I checked there's still a lot of C++ code in legacy production systems -- and a lot that has never ever used a smart pointer.
  - einpoklum 7y ago
    That was exactly my point; GP says they've been writing C++ for the past 6 years, but seems to be talking about legacy code.
    - praptak 7y ago
      Nope, I meant modern C++. Granted, it has multiple mechanisms to prevent memory corruption but they are not watertight.
- praptak 7y ago
  vector::operator[] does not check bounds, neither do some libraries that I have to use, notably Google Protocol Buffers can turn a logic bug (bad index to repeated field) into an access to unallocated memory. Best practices do not fully eliminate segfaults. This is a practical observation.