Hacker News Reader

Comment by jurschreuder | Hacker News Reader

I don't know why people use 'new' and 'delete' in all the examples how memory in C++ works because you never normally use them during coding only if you want to make your own container which you might do once to learn about the internals.

C++ by default creates objects by value (opposed to any other language) and when the variable goes out of scope the variable is cleaned up.

'new' you use when you want to make a global raw pointer outside of the normal memory system is how I would see it. You really never use it normally at least I don't.

A good rule of thumb is not to use 'new'.

View on HN

People use `new` and `delete` when explaining memory in C++ because those are the language primitives for allocating and releasing memory in C++.

That rule of thumb is only a useful rule if you don't care about how memory works and are comfortable with abstractions like RAII. That's fine for lots of real code but dismissing `new` and `delete` on principle is not interesting or productive for any discussion.

No the primitives are:

{

  // allocate

  auto my_obj = MyObj{}

} // released

Also they're operators.

I understand C++ has a lot of operators which are variously reserved but not standardized ("asm") largely obsolete but still needed because of perverse C programmers ("goto") still reserved long after their usefulness subsided ("register") or for ideas that are now abandoned ("synchronized") not to mention all its primitive types ("double", "signed", "long", "short", "char8_t") and redundant non-textual operators given ASCII names like ("and_eq", "bitand", "xor")

But it also has dozens, like new and delete which look like features you'd want. So kinda makes sense to at least mention them in this context.

I think this got away from me, 'cos clearly part way through I start talking about keywords not operators, whoops.

Yes, and no?

In production, odds are you are relying on allocators or containers others already wrote. You coming in in 2026 may not ever use the keywords directly, but you'll either be using abstractions that handle that for you (be it STL or something internal) or using some custom allocation call referring to memory already allocated.

But yes, I'd say a more general rule is "allocate with caution".

Unfortunately they are all over the place on corporate code.

It just makes for an easily understandable example. I don't think the post is advocating for the use of new/delete over smart pointers.

> I don't know why people use 'new' and 'delete' in all the examples ...

Why? Because the blog post is titled "Understanding C++ Ownership System".

Such article can end up with a 'false balance' bias by introducing and showing a method one should avoid to motivate the solution. What some people learn is "there are two options".

Maybe it works be better to start with "that's how we do it" and only afterwards following up with "and that's why".

He's making it massively more complex than it actually is

{ // this scope is owner

  // allocate

  auto my_obj = MyObj{};

  // this function scope does not have ownership of my_obj, should take (const MyObj& obj) const reference as parameter

  do_something(my_obj);

} // memory is released

Yup, just emplace the object directly into the container, or at worst create it by value and then add it to the container with std::move.

You need to if you want to create a smart pointer from some class with a private constructor.

even when you write your own container, you do not use new and delete.

Are you sure? It seems as though ultimately Microsoft's STL for example ends up calling std::allocator's allocate function which uses the new operator.

you would use "operator new" (allocates memory only) not "new" (allocates and constructs, and more if using the new[] variant)

You might use placement new though.

And yet, I interviewed 10 people easily where I was using new and delete in the example code and only one person asked "hey - can we use unique_ptr?".

Ownership problems with pointer/references don't end with allocation.

A codebase can use only std::make_unique() to allocate heap, and still pass around raw pointers to that memory (std::unique_ptr::get()).

The real problem is data model relying on manual lifetime synchronization, e.g. pass raw pointer to my unique_ptr to another thread, because this thread joins that thread before existing and killing the unique_ptr.

I don’t disagree. That’s why I don’t write C++ anymore. It’s a masochistic language and trying to do it in a team environment with people who do understand how to do it properly is a mess let alone adding in people who don’t know.

Well in interviews this is tricky. Sometimes the interviewer wants to see I can new/delete properly, sometimes this tells me "well, if that's the style they are using I better go elsewhere"

If it's done as part of a "here is legacy code, suggest ways to improve it" question one should point it out, though.

Don’t worry. The question was super basic and almost every candidate still failed to mention that you need to delete in the destructor, that copying requires a new allocation or that you also need to define the move constructor. It made me sad about the state of C++ developers and thankful that Rust makes such mistakes impossible.

many schools (like mine) don't teach unique pointers in the pure "programming" class sequence, but offer a primer in advanced classes where c++ happens to be used, with the intent to teach manual memory management for a clearer transition to e.g. upper-levels which use c.

Reply on news.ycombinator.com