Hacker News Reader

Comment by petke | Hacker News Reader

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost.

I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to use value semantic all the way when you can. And you usually can. Why place something on the heap if it can live on the stack?

View on HN

Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.

You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.

"Dynamic memory allocation", not "direct memory access".

Ah never seen dynamic memory allocation written as DMA before. Maybe obvious from the context but DMA really only has one meaning for me :)

I think he was using a new acronym for Dynamic Memory Allocation rather than Direct Memory Access. I also was confused the first time I read it.

I thought he meant the hardware-related meaning of DMA too, for a second. But the first line of his comment is:

>Well said! Dynamic memory allocation is a really big performance hit

You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ?

Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.

Many programmers have this idea. Oh, this is a big object. I better wrap it in a smart pointer to avoid doing expensive copies when I pass it around. They do it as an optimisation. However because of named return value optimisation and move constructors no expensive copies are done when passing stack values to and from functions. Using smart pointers is actually slower (because of the indirection and reference counting).

I don't think C++ supports variable length arrays?

So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector<>, and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough.

More importantly, it plays nice with other C++ functionalities. For example, zero-copy construction using emplace_back() inside a for loop. (And if you throw an exception in the middle you're guaranteed that destructors are called exactly for those that are already constructed.)

> I don't think C++ supports variable length arrays?

VLAs are not part of the standard but GCC supports them. Clang however does not, at least not without a compiler flag I think.

std::array exists. But it isnt variable length. We might get a dynarray in the next standard. I saw a standards committee panel talk where someone asked about it. Ville Voutilainen promised to write standards proposal. I dont miss it much. Usually std::array does what I want.

My question was regarding whether its the norm that C++ programmers use the heap when stack would have sufficed. Parent seemed to be hinting that they do.

And, yeah its disappointing C99 arrays did not make it to C++, one can use alloca to live a little dangerously, better to wrap it so that it allocates on the heap only if more than a certain size has been asked for. Too bad there is no portable way to find out how much stack space does the current process still have. There should have been a system call for that.

You can still use alloca in C++

Yes and I have at times, but its living a little dangerously. Even if it returns a non-null pointer it does not mean you can write there safely.

No one who cares about performance enough to be using C++ would do something like this. Allocating on the heap when not necessary is a sign of a dangerous amateur.

Pointers (smart or raw or whatever) get used when you need reference semantics. It's true that value semantics are usually better but not always (eg inheritance).

To be sure, though, being able to make proper value types is a strength of C++. Also we should point out most non-trivial value types make extensive (and necessary!) use of the heap under the hood (eg string, vector)

And then, you have Small String Optimization that put the string data back on the stack ;)

It's true that stack allocation is often better, and should be preferred, but that doesn't mean the heap isn't useful.

Because copying the entire in-memory database you're using on every function call is kind of expensive?

C++ has perfect move semantics since C++11, and you can always use a reference to pass things around if you need.

Most often you can pass stack values to and from functions without copying. This is because of move constructors, and named return value optimization. Often its slower to use pointers (the indirection).

For instance this does not do any expensive copies:

std::string getStr() { auto huge_str = getDatabaseDump(); return huge_str; }

void readStr(const std::string& str ){ //read str.. }

int main() { auto str = getStr(); readStr(str); }

But std::string is a wrapper for a heap allocation, and a reference also incurs the same indirection cost as a pointer?

Yes that's true. Internally a lot of library types use heap allocation. Most well designed libraries avoid it if they can, but sometimes the object is simply too large for the stack. For many library types its a undocumented implementation detail we dont know about.

We as users of that library type should not additionally put that object on the heap though, if we dont have too. Its simply unnecessary.

Its makes for one extra unnecessary pointer indirection, it adds unnecessary reference counting if using smart pointers, or unnecessary manual memory management if we use raw pointers. It complicates the interface for our functions if we have to wrap types in smart pointers.

As for c++ references. Yes that's true. As I understand it they are implemented as pointers internally by compilers. But in important ways they behave more like values, rather than pointers. As in if you copy or assign to them, they copy or assign the value (not the pointer). If you take their address they give the address of the value (not the pointer). Because of this there are not as many pitfalls to using them as there is with pointers. I see them mostly just as aliases for values.

In the example above I could have passed the string by value (instead of by reference) to the function. It would still not have done a expensive copy, because of copy elision optimisation. I probably should have done that. It looks a bit funny, and takes some getting used too.

Relevant: https://web.archive.org/web/20140205194657/http://cpp-next.c...

The effects you describe are mainly caused by copy elision (https://en.m.wikipedia.org/wiki/Copy_elision) While move semantics certainly improve performance, they are still expensive in many cases, and it's very hard to make assumptions on their performance without detailed measurements.

The problem with copy elision is that it's an optional compiler optimization and you have to check if the compiler applies it to you particular piece of code. That doesn't scale for large code bases (nor for small ones imho).

That isn't about value semantics, what you are describing is a combination of copy elision and ownership.

Reply on news.ycombinator.com