4 ms·

As you are officially discouraged to use new and delete directly (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-

• zabzonk 5y ago
  In my opinion, the site you linked to has a major problem - many of the example functions have a "void" return type. This indicates that they must have side-effects (or why else call them?) and we would normally not want to write functions that have side effects. A rule of thumb: if your function doesn't have a return type, consider that your design maybe wrong in some way.
  • detaro 5y ago
    What the functions return is utterly irrelevant for the examples, so adding return types and statements just makes the example more complex for no good reason (and distracts from examples where the example is about the returns)
    • zabzonk 5y ago
      The site is about writing "good" C++. Having loads of functions that implement "bad" C++ cannot help.
      • josefx 5y ago
        Good C++ code shouldn't throw around heap allocations, shared or otherwise. Smart pointers are like duct tape, they help keeps things together but most of the time there are better solutions. Your complaint about void will be noted once you fix your programs ownership semantics. Note: Any negative reactions to smart pointers on my side may be fueled by a disturbing amount of cargo culting that I had to witness since their inclusion in the standard.
        • zabzonk 5y ago
          > Your complaint about void will be noted By whom? > once you fix your programs ownership semantics. How do you heck know how my programs need fixing? > Any negative reactions to smart pointers on my side may be fueled by a disturbing amount of cargo culting that I had to witness since their inclusion in the standard. Any positive reactions to smart pointers on my side may be fuelled by over 30 years experience in using them.
          • josefx 5y ago
            > How do you heck know how my programs need fixing? You where the one complaining that sample one liners with void return types where bad code. In my experience shared_ptr is overkill in nearly all trivial code examples, so any one liner containing one is bad code. > Any positive reactions to smart pointers on my side may be fuelled by over 30 years experience in using them. Hope you never had to deal with code reviews that suggested putting scoped std::vector uses in shared_ptr s to avoid stack overflows. Or really any code that put objects into smart pointers because it could not because it should.
            • zabzonk 5y ago
              I have never, ever used, or suggested the use of shared_ptr, which I believe is not a construct that should be in C++ or any other language.
              • rualca 5y ago
                > (...) shared_ptr, which I believe is not a construct that should be in C++ or any other language. What's your rationale for that assertion?
  • mhh__ 5y ago
    This is true, but two points: Firstly, don't teach too much at the same time, and secondly sometimes you have to just launch the missiles.
• klyrs 5y ago
  > The pointer returned by new should belong to a resource handle (that can call delete). If the pointer returned by new is assigned to a plain/naked pointer, the object can be leaked Unless I'm reading this wrong (and I'm seeking to be corrected here), it's still fine to use new/delete in certain contexts struct bla { int n; int[] mem; bla(int n) : n(n), mem(new int[n]{}) {} ~bla() { delete[] mem; } /* forbid copies (for uniqueness) and moves (to keep this short) */ bla(bla &) = delete; bla(bla &&) = delete; bla &operator=(bla &&) = delete; }; Edit to remove unnecessary null-checking
  • f00zz 5y ago
    You could just use std::vector<int> there
    • klyrs 5y ago
      Of course you could. That wasn't my question -- my question was about the wording of the recommendation; "...should belong to a resource handle (that can call delete)"
  • makecheck 5y ago
    Note above, the “delete” operator is safe to call on nullptr values, and it is also not necessary to set pointers to nullptr in destructors (since the object is going away anyway). The example above therefore could just say “delete [] mem;” in the destructor with nothing else. Yet this is also a good example of why you wouldn’t need “delete” or a destructor at all, if “mem” changes to std::unique_ptr<int[]> type. And even then, you should probably seriously consider std::vector or std::array before trying a unique_ptr array.
  • zabzonk 5y ago
    Is: int[] mem; even legal C++?
    • klyrs 5y ago
      no, that was me being sloppy typing code on my phone