3 ms·

a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std:

by p0w3n3d 3mo ago

a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.

RossBencina 3mo ago
In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?
- pjmlp 3mo ago
  With what will most likely become [[unsafe]] profile in C++29, assuming WG21 actually gets their profiles story right.
  - bluGill 3mo ago
    I don't think adding unsafe will be possible - it will break too much existing code. We might be able to add something new that is only possible in an unsafe context, but there is too much existing code. However I do expect a [[safe]] profile (or perhaps several, depending on which paper you read) that everyone is encourage to opt-in to. Likely combines with compiler warnings and static analysis to encourage that use. (Also syntax is still open for debate)
    - pjmlp 3mo ago
      Check the WG21 mailing proposals. I was for Safe C++ paper, based on Circle experience, but it was shot down due to politics. So we're left with the profiles camp actually delivering, followed by the remaining compilers caring to actually implement them, otherwise it will be static and dynamic analysis as usual.
      - will4274 3mo ago
        It wasn't shot down due to politics. It was shot down because it solved the wrong problem.
        pjmlp 3mo ago
        Yeah, that is why there was a paper created specifically to kill any other proposal, by the profiles folks with WG21 majority, and ironically profiles are just as annotation heavy, but since it is profiles, it is alright. I call that politics, and in the end the most likely outcome is that by C++29 nothing will be delivered by the profiles group, that is any better than using clang-tidy already today.
  - saghm 3mo ago
    Classic C++, any issue is at most three years away from going away! There will definitely not be any other issues that are also three years from getting fixed when you reach that year though
    - pjmlp 3mo ago
      Actually no, because you are missing the time between standard being ratified and actuality being widely available in all major compilers. By the way, it is also classical Web standards, C, Vulkan, OpenCL, and everything else that has a similar process. Ideally we should have gotten rid of C and C++, but I haven't yet found a better Typescript for C.
      - saghm 3mo ago
        Fair enough, three years might be more of an upper bound than a lower bound. And yeah, the issue of having to wait is common to standard-based processes, but I've never seen anything else based on a standard so frequently have people need to jump in and try to dissuade people that issues matter because of the rolling timeline so frequently, regularly, and for such a long time as C++. Obviously it would be unreasonable to expect it to become perfect and not need any more changes, but like, I was hearing people complain about various aspects of `unique_ptr` a decade ago, and it seems like we're not even past that yet.
bluGill 3mo ago
For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance. That last 5% though you are doing weird things and so need to do something manually. (as the other poster said, make_unique is implemented with new) Of course the 5% is overall. Some projects never have anything that gets into that last 5%, while others it is more like 50% of the code can't use make_*. If at all possible your use of new/delete should be limited to a data structure/container than handles it, and not scatters all over.
- RossBencina 3mo ago
  "For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance." For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead: https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc
  - bluGill 3mo ago
    I watched that about 7 years ago when it first came out, and at an hour long I'm not about to watch it again... From what I can recall those are things that rarely are important. There is a cost, but in most real world code they only add a few nanoseconds - I have more important things to worry about.
    - superxpro12 3mo ago
      As a firmware developer commonly operating on devices with 32MHz of cpu, i am offended sir.
      - bluGill 3mo ago
        Even at 32Mhz you typically have more important things to worry about. These nanoseconds are unlikely to add up - the overhead from the underlying new/delete is going to be much worse.

by p0w3n3d 3mo ago

a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.

RossBencina 3mo ago

In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?

pjmlp 3mo ago
With what will most likely become [[unsafe]] profile in C++29, assuming WG21 actually gets their profiles story right.
- bluGill 3mo ago
  I don't think adding unsafe will be possible - it will break too much existing code. We might be able to add something new that is only possible in an unsafe context, but there is too much existing code. However I do expect a [[safe]] profile (or perhaps several, depending on which paper you read) that everyone is encourage to opt-in to. Likely combines with compiler warnings and static analysis to encourage that use. (Also syntax is still open for debate)
  - pjmlp 3mo ago
    Check the WG21 mailing proposals. I was for Safe C++ paper, based on Circle experience, but it was shot down due to politics. So we're left with the profiles camp actually delivering, followed by the remaining compilers caring to actually implement them, otherwise it will be static and dynamic analysis as usual.
    - will4274 3mo ago
      It wasn't shot down due to politics. It was shot down because it solved the wrong problem.
      - pjmlp 3mo ago
        Yeah, that is why there was a paper created specifically to kill any other proposal, by the profiles folks with WG21 majority, and ironically profiles are just as annotation heavy, but since it is profiles, it is alright. I call that politics, and in the end the most likely outcome is that by C++29 nothing will be delivered by the profiles group, that is any better than using clang-tidy already today.
- saghm 3mo ago
  Classic C++, any issue is at most three years away from going away! There will definitely not be any other issues that are also three years from getting fixed when you reach that year though
  - pjmlp 3mo ago
    Actually no, because you are missing the time between standard being ratified and actuality being widely available in all major compilers. By the way, it is also classical Web standards, C, Vulkan, OpenCL, and everything else that has a similar process. Ideally we should have gotten rid of C and C++, but I haven't yet found a better Typescript for C.
    - saghm 3mo ago
      Fair enough, three years might be more of an upper bound than a lower bound. And yeah, the issue of having to wait is common to standard-based processes, but I've never seen anything else based on a standard so frequently have people need to jump in and try to dissuade people that issues matter because of the rolling timeline so frequently, regularly, and for such a long time as C++. Obviously it would be unreasonable to expect it to become perfect and not need any more changes, but like, I was hearing people complain about various aspects of `unique_ptr` a decade ago, and it seems like we're not even past that yet.

bluGill 3mo ago

For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance. That last 5% though you are doing weird things and so need to do something manually. (as the other poster said, make_unique is implemented with new) Of course the 5% is overall. Some projects never have anything that gets into that last 5%, while others it is more like 50% of the code can't use make_*. If at all possible your use of new/delete should be limited to a data structure/container than handles it, and not scatters all over.

RossBencina 3mo ago
"For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance." For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead: https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc
- bluGill 3mo ago
  I watched that about 7 years ago when it first came out, and at an hour long I'm not about to watch it again... From what I can recall those are things that rarely are important. There is a cost, but in most real world code they only add a few nanoseconds - I have more important things to worry about.
  - superxpro12 3mo ago
    As a firmware developer commonly operating on devices with 32MHz of cpu, i am offended sir.
    - bluGill 3mo ago
      Even at 32Mhz you typically have more important things to worry about. These nanoseconds are unlikely to add up - the overhead from the underlying new/delete is going to be much worse.