Hacker News Reader

Comment by zabzonk | Hacker News Reader

This is full of misunderstandings. When variables are allocated on the stack, the space for them with all compilers I have ever used (or written) is allocated on the stack once by adjusting the stack pointer - i.e. for all of the variables of the function. There is no pushing or popping - function variables have addresses on the stack. When the function ends, the stack pointer is reset to it's original value, possibly with destructors for the things on the stack being called.

Also, in modern compilers, parameter variables are mostly passed to functions via registers, with the stack not being involved at all.

View on HN

> Also, in modern compilers, parameter variables are mostly passed to functions via registers, with the stack not being involved at all.

Given that this is a C++ thread I'll be pedantic and say that this is really the ABI rather than the compiler as per se.

ABI is a factor in every language;* so I’m not sure I understand the point you’re trying to make.

* even interpreted ones, though the calling conventions and layout are quite different from what is typically written up in the documentation of most compiled languages.

The term "modern compiler" was used, which implies that an old compiler might (say) not do so despite complying with some ABI, i.e. the registers aren't an optimization.

I have never used a compiler that didn't allocate frames in a single move of the sp, and I've been using compilers since the 1970. Surely "modern" has to mean some change more recent than that.

That isn't the part of your comment I was block-quoting.

Given that the C++ Standard has nothing to say about an ABI (neither does the C Standard, for that matter), then what a compiler does on a particular platform, and what a platform ABI specifies (if it does) are possibly kind of linked.

The word compiler is only mentioned 12 times in the whole standard give or take.

My point was that it's not a question of whether the compiler is modern or not, i.e. I work with an old compiler backend on a modern system and it still gets the ABI correct even if it ends up spilling back to memory too often.

I took it as a "conceptual abstraction". It presented a mental model focused on the relationship between variables' lifetimes, intentionally glossing over the implementation details of any particular compiler.

If it is glossing over implementation details, why does it mention the stack? That _is_ an implementation detail.

AFAIK (I never looked at an official standard, only at drafts) the standard doesn’t mention the word “stack” at all

A C++ compiler is free to allocate environment frames for every block on the heap.

There are different tiers of abstraction. This post picked a level of granularity that the author felt would be helpful for a certain subset of readers.

Whether the "stack" is formalized or not, it's the mental model (and the vocabulary) that's most often used when working with this stuff. I don't think there's anything wrong with the fact that they focused on the forest and not the trees.

Yes, there are different tiers of abstraction, but I think this article, about lifetimes, would be better if it just discussed scope.

As is, it goes into implementation details for block scoped storage, but just posits that new and delete exist without mentioning any detail. That’s unbalanced.

Rereading it, it also assumes you know C well enough to know about malloc, so maybe, just saying “C++ can automatically do stuff when variables go out of scope or when you allocate or free memory. Here’s what it can do…” might be sufficient)

Since this would be too easy for c++, there is also (sometime mandatory) copy elision.

> When variables are allocated on the stack, the space for them with all compilers I have ever used (or written) is allocated on the stack once by adjusting the stack pointer - i.e. for all of the variables of the function.

it's not a given

    int algo(int*, int n);
    int computation(int i, int n) {
        int alloc[n];
        return algo(alloc, n);    
    }

on some compilers (Keil for instance afair), alloc will be heap-allocated (and freed when leaving the function) even if it's "automatic storage" (what most people call the stack).

Isn't variable sized array non-standard in C++? Variable sized array is kind of a special thing anyway so I wouldn't be surprised if some compilers do something special with it.

Yes, the term "automatic storage" is more accurate here.

Reply on news.ycombinator.com