Hacker News Reader

Comment by dxuh | Hacker News Reader

As you are officially discouraged to use new and delete directly (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...) and I fully agree with this guideline, I was disappointed to see new being mentioned so early and not immediately being followed up with std::unique_ptr and std::shared_ptr. Especially because you introduced the constructor/destructor subsection with how destructors can be used to free memory. A general mention of std::shared_ptr would have been expected as well, I think.

It is unfortunate that many learning resources don't show modern C++ so the language is perceived worse than it is and also more bugs are written, than is necessary.

View on HN

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.

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)

The site is about writing "good" C++. Having loads of functions that implement "bad" C++ cannot help.

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.

> 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.

> 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.

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.

> (...) 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?

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.

> 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

You could just use std::vector<int> there

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)"

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.

Is:

     int[] mem;

even legal C++?

Not standard C++.

If the [] was after the variable name, because it is the last member, most C++ compilers (GCC, Clang, and MSVC) have a non-standard extension: https://en.wikipedia.org/wiki/Flexible_array_member

Not even non-standard C++ - my g++ compiler errors with:

a.cpp:2:13: error: expected unqualified-id before '[' token

> If the [] was after the variable name

no, that was me being sloppy typing code on my phone

should. It's a guideline to avoid mistakes, it doesn't mean you can't do memory manually in C++, it's just recommended you avoid it unless you have a good reason.

That struct should be just struct bla { int n; std::unique_ptr<int[]> mem; bla(int n) : n(n), mem(std::make_unique<int[]>(n)) { } }. There is no reason to use new/delete there.

Reply on news.ycombinator.com