6 ms·

Huh? The best way to prevent mistakes is to make doing it right easy. Manually doing everything just means a lot of room to mess up. Using the newer constructs

by bluGill 3mo ago

Huh? The best way to prevent mistakes is to make doing it right easy. Manually doing everything just means a lot of room to mess up. Using the newer constructs my means you can't make a mistake as the hard work is done correctly for you. Zero cost abstraction means that it has no downside to manually doing it. C++ is trivial compared to the code I work on. If you are writing hello world complexity then C++ might be complex but some of us work on hard problems.

jstimpfle 3mo ago
I understand C++ as well, or better, than most (or all) of my peers, and certainly betters than people on here thinking they need to explain to me how RAII works. Do you want to argue that C++ RAII / objects stuff isn't complex and doesn't put considerably restrictions on how you design your app, then maybe you should reconsider. I would argue that if cleaning up resources properly is among the hard problems, or among the most error-prone problems in your code, then maybe you're problems aren't that hard or complex after all. I'm currently working on a distributed caching system and on real time voxel geometry boolean operations simulation (on GPU), both on the scale of >= 10^9. Is that "complex" enough? Both are done in C++. C++ helps exactly 0 in achieving any of these things (as opposed to using plain C), well the one help is I don't have to type 'struct' all the time. In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs and performance problems from using them. The code was not obvious and using STL containers (std::deque is very bad specifically) meant the actual runtime characteristics depend on which STL implementation is being compiled in. It would have been easier to just do straightforward obvious manual code.
- feelamee 3mo ago
  I'm interesting which C++ features also helps you to design such systems. I think basic RAII/function overloading/templates should give a lot of capabilities comparing with plain C? > (as opposed to using plain C) Also, curious - how plain C helps with this?
  - jstimpfle 3mo ago
    I've found that RAII and the stuff you have to buy into in order to use RAII come with more downsides than upsides once you scale beyond high level programs that try to get done a lot with very few lines. > how plain C helps with this? By staying out of the way and providing everything of what you actually need in the end. That is assuming a detail oriented approach where you deeply think about, and want to be flexible about, the organization of what your program should do. As programs grow into large architectures, and as programs get more performance conscious, they also get more detail oriented like that, and they tend to opt out of unflexible high level language features.
    - feelamee 3mo ago
      thx, I don't understand fully, but see something truthy in this. It would be interesting to read more detailed blog post about this.
- CyberDildonics 3mo ago
  In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs Which part of the STL are you expecting to be thread safe?
  - jstimpfle 3mo ago
    Where did I imply that I am expecting any part of the STL to be thread safe?
    - CyberDildonics 3mo ago
      If you aren't, wouldn't that imply that the concurrency problems are with you and not with the standard library?
      - jstimpfle 3mo ago
        Why don't you read again what I said instead of continuing to make implications?
        CyberDildonics 3mo ago
        You said you had concurrency problems with the STL, but none of it has any intersection with concurrency, that is left to the users. There are no expectations there unless you were using threads, atomics, mutexes etc. and they had bugs.
        jstimpfle 3mo ago
        Try harder, Sherlock. You're very close to proving that I assumed the STL was "thread safe". You've almost got me.
        CyberDildonics 3mo ago
        I'm not trying to prove anything, I'm asking why you "had concurrency problems from using the STL" when the STL doesn't have anything to do with concurrency.

by bluGill 3mo ago

jstimpfle 3mo ago

I understand C++ as well, or better, than most (or all) of my peers, and certainly betters than people on here thinking they need to explain to me how RAII works. Do you want to argue that C++ RAII / objects stuff isn't complex and doesn't put considerably restrictions on how you design your app, then maybe you should reconsider. I would argue that if cleaning up resources properly is among the hard problems, or among the most error-prone problems in your code, then maybe you're problems aren't that hard or complex after all. I'm currently working on a distributed caching system and on real time voxel geometry boolean operations simulation (on GPU), both on the scale of >= 10^9. Is that "complex" enough? Both are done in C++. C++ helps exactly 0 in achieving any of these things (as opposed to using plain C), well the one help is I don't have to type 'struct' all the time. In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs and performance problems from using them. The code was not obvious and using STL containers (std::deque is very bad specifically) meant the actual runtime characteristics depend on which STL implementation is being compiled in. It would have been easier to just do straightforward obvious manual code.

feelamee 3mo ago
I'm interesting which C++ features also helps you to design such systems. I think basic RAII/function overloading/templates should give a lot of capabilities comparing with plain C? > (as opposed to using plain C) Also, curious - how plain C helps with this?
- jstimpfle 3mo ago
  I've found that RAII and the stuff you have to buy into in order to use RAII come with more downsides than upsides once you scale beyond high level programs that try to get done a lot with very few lines. > how plain C helps with this? By staying out of the way and providing everything of what you actually need in the end. That is assuming a detail oriented approach where you deeply think about, and want to be flexible about, the organization of what your program should do. As programs grow into large architectures, and as programs get more performance conscious, they also get more detail oriented like that, and they tend to opt out of unflexible high level language features.
  - feelamee 3mo ago
    thx, I don't understand fully, but see something truthy in this. It would be interesting to read more detailed blog post about this.
CyberDildonics 3mo ago
In fact, in one of these projects I was pushed to use STL initially. I'm now working on getting rid of the last of them because we have had concurrency bugs Which part of the STL are you expecting to be thread safe?
- jstimpfle 3mo ago
  Where did I imply that I am expecting any part of the STL to be thread safe?
  - CyberDildonics 3mo ago
    If you aren't, wouldn't that imply that the concurrency problems are with you and not with the standard library?
    - jstimpfle 3mo ago
      Why don't you read again what I said instead of continuing to make implications?
      - CyberDildonics 3mo ago
        You said you had concurrency problems with the STL, but none of it has any intersection with concurrency, that is left to the users. There are no expectations there unless you were using threads, atomics, mutexes etc. and they had bugs.
        jstimpfle 3mo ago
        Try harder, Sherlock. You're very close to proving that I assumed the STL was "thread safe". You've almost got me.
        CyberDildonics 3mo ago
        I'm not trying to prove anything, I'm asking why you "had concurrency problems from using the STL" when the STL doesn't have anything to do with concurrency.