5 ms·

You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.

by est31 4y ago

staunton 4y ago
The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.
- kitkat_new 4y ago
  not only the overhead, but even the semantics The difference is that the use of the smart pointers is checked of the compiler
- ryandrake 4y ago
  I know this is an unpopular opinion but if you want to stick with C++, the solution to this, at least in my experience, is to stop doing things that let you shoot your foot off. C++ gives you every tool in the tool chest, and most of them are not safe. Stick to a safe subset and you've solved 90% of all those stereotypically C++ problems. I've got a pretty big C++ codebase for my hobby projects, sanded down, polished and perfected over the years without the usual corporate pressure to ship. The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. The simple key is to just stop doing these unnecessary things.
  - jjnoakes 4y ago
    The most recent example I debugged for a colleague was a container of callbacks, and one of them ended up changing the container while it was being iterated over. Nothing crazy, just no easy way that we were aware of to catch that kind of thing.
  - bbkane 4y ago
    Yes, but "just don't do that" doesn't scale to large teams with varying levels of experience and discipline. It sounds like you have rules that even you disobey on this project.
  - luuio 4y ago
    Everything you said is true. C++ gives you everything you need to be safe. But that's not the point. Rust makes it HARD (or very hard) to do things that are unsafe. It's not what C++ can or cannot do, it's not what Rust can or cannot do. It's what the Rust language and compiler opinionatedly encourage you to do and not to do. This is what's lacking in C++.
    - blub 4y ago
      I think many people - me included - are complaining that it makes things hard period. Not in the sense of “rocket science” as this argument is sometimes smugly dismissed, but in the sense of extra friction which slows things down and decreases the pleasure of coding.
  - saagarjha 4y ago
    > The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? The problem with C++ is that all of these things don't look like unsafe operations, and people end up making mistakes with them that are not obvious.
    - blub 4y ago
      When using GCC for example, there’s a macro one can define which adds bounds checking to all containers. Integer overflow can be turned into defined behavior through a compiler switch. Holding pointers to stack variables past the return is not as easy to inadvertently do as an off-by-one. Someone has to store the address into a variable and this kind of code should raise alarm bells. A more indirect way is to pass an address of a local variable to a function which is typical. But then if a function takes arbitrary pointers it receives and stores them, this should also raise some alarm bells.
    - jandrewrogers 4y ago
      > You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? Can't speak for the OP, but I never see any of these bugs in my C++ code. You can write code with these bugs but that is more of a style choice, practically speaking. The C++ bugs I see are almost always in complex state logic or in rarer cases an unexpected/unhandled error case from a call to outside code, which can happen in every language.
  - staunton 4y ago
    Yes, of course. If you use C++, try to not shoot your foot off. The same advice also applies to Rust or any other programming language. You should still try to follow best practices and not mess up, even if a language makes it less likely to mess up in certain ways. The question is how often you mess up in each language and how bad those mess-ups are. This depends a lot on the programmer(s) and the kind of project. My personal view is that the space of team/project combinations where you should ever start a new C++ project is now confined to "team desperately wants C++".
kitkat_new 4y ago
manually vs automatically (with more control about the how compared to other high level languages)

You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.

by est31 4y ago

You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.

staunton 4y ago

The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.

kitkat_new 4y ago
not only the overhead, but even the semantics The difference is that the use of the smart pointers is checked of the compiler
ryandrake 4y ago
I know this is an unpopular opinion but if you want to stick with C++, the solution to this, at least in my experience, is to stop doing things that let you shoot your foot off. C++ gives you every tool in the tool chest, and most of them are not safe. Stick to a safe subset and you've solved 90% of all those stereotypically C++ problems. I've got a pretty big C++ codebase for my hobby projects, sanded down, polished and perfected over the years without the usual corporate pressure to ship. The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. The simple key is to just stop doing these unnecessary things.
- jjnoakes 4y ago
  The most recent example I debugged for a colleague was a container of callbacks, and one of them ended up changing the container while it was being iterated over. Nothing crazy, just no easy way that we were aware of to catch that kind of thing.
- bbkane 4y ago
  Yes, but "just don't do that" doesn't scale to large teams with varying levels of experience and discipline. It sounds like you have rules that even you disobey on this project.
- luuio 4y ago
  Everything you said is true. C++ gives you everything you need to be safe. But that's not the point. Rust makes it HARD (or very hard) to do things that are unsafe. It's not what C++ can or cannot do, it's not what Rust can or cannot do. It's what the Rust language and compiler opinionatedly encourage you to do and not to do. This is what's lacking in C++.
  - blub 4y ago
    I think many people - me included - are complaining that it makes things hard period. Not in the sense of “rocket science” as this argument is sometimes smugly dismissed, but in the sense of extra friction which slows things down and decreases the pleasure of coding.
- saagarjha 4y ago
  > The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? The problem with C++ is that all of these things don't look like unsafe operations, and people end up making mistakes with them that are not obvious.
  - blub 4y ago
    When using GCC for example, there’s a macro one can define which adds bounds checking to all containers. Integer overflow can be turned into defined behavior through a compiler switch. Holding pointers to stack variables past the return is not as easy to inadvertently do as an off-by-one. Someone has to store the address into a variable and this kind of code should raise alarm bells. A more indirect way is to pass an address of a local variable to a function which is typical. But then if a function takes arbitrary pointers it receives and stores them, this should also raise some alarm bells.
  - jandrewrogers 4y ago
    > You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? Can't speak for the OP, but I never see any of these bugs in my C++ code. You can write code with these bugs but that is more of a style choice, practically speaking. The C++ bugs I see are almost always in complex state logic or in rarer cases an unexpected/unhandled error case from a call to outside code, which can happen in every language.
- staunton 4y ago
  Yes, of course. If you use C++, try to not shoot your foot off. The same advice also applies to Rust or any other programming language. You should still try to follow best practices and not mess up, even if a language makes it less likely to mess up in certain ways. The question is how often you mess up in each language and how bad those mess-ups are. This depends a lot on the programmer(s) and the kind of project. My personal view is that the space of team/project combinations where you should ever start a new C++ project is now confined to "team desperately wants C++".

kitkat_new 4y ago

manually vs automatically (with more control about the how compared to other high level languages)