4 ms·

> "Proofing the code"? Does that mean anything at all? Since you're already schooling me on the meaning of terms, you probably have enough experience to have r

> "Proofing the code"? Does that mean anything at all? Since you're already schooling me on the meaning of terms, you probably have enough experience to have realized that the typical code begins life in a stubbed out form that is barely functional enough to deliver first results. It is then iteratively enhanced and made more widely applicable, more robust, more refined, better specified, more performant, and so on. In the process, the code is undergoing many revisions, and moving data structures from automatic storage (stack) to the heap is very typical. Another word I'm thinking of for this process is "consolidation", which I have also used. My apologies if I don't speak in your terms / in the most precise terms.

moloch-hai 4y ago
I don't have experience of this "moving from ... stack to the heap", in C++. Correct code is the same wherever the objects live, whether stack, member, or heap. Changing it costs time and adds faults. This proofing process is another example of what makes coding C more costly and buggy than coding C++. I did it for years, and miss it not at all.
- jstimpfle 4y ago
  If writing systems-level code solving for non-trivial requirements, the majority of the state has a lifetime that outlives any particular function call. That's when you need to move that state to the heap. There's no clear scope anymore, ownership has to be moved from function scopes to RAII managed container structures. Things are quickly getting more complicated and expensive (software complexity/bloat, compile times, binary size...) when you have to nest your structures in templated containers that don't know what you're nesting in them... This is where all the complexity with 17 constructor types and 99 move semantics with const, non-const, r-valued references and abstract virtual base classes came from, and there might be less than a dozen persons left on the planet who really understand it all...
  - moloch-hai 4y ago
    With RAII, it is trivial to move things from stack to heap, or to a member of something that might be on the stack or heap or in a container, without changing any of the code that implements the object. Most usually you don't need to declare or define any constructors, assignment operators, or a destructor; the compiler provides them, and guarantees they are correct. (Sometimes you provide one constructor as a convenience for users.) It has been many years since I found a use for an abstract virtual base class. Literally millions of people understand it all, and use it every day with no difficulty. You don't need to invent difficulties, or waste days "proofing" code that may be written exactly once and never touched again.
    - BenFrantzDale 4y ago
      To clarify, I think by “move things from stack to heap” you mean “move values from stack to heap”, where, e.g., `std::vector<int>` is a value. The vector’s data is still on the heap (or in the allocator’s pool for `std::pmr::vector<int>`) but the value in the sense of value-semantics is moved from stack to heap.
- Too 4y ago
  I guess what they mean is moving to static memory allocation, not to the heap. That is something done rather frequently when proofing embedded C code, because it's simply to easy to mess up manual memory management. Only reason to move from stack to heap would be for huge data structures not give stackoverflow, something that can be hard to test for.

moloch-hai 4y ago

I don't have experience of this "moving from ... stack to the heap", in C++. Correct code is the same wherever the objects live, whether stack, member, or heap. Changing it costs time and adds faults. This proofing process is another example of what makes coding C more costly and buggy than coding C++. I did it for years, and miss it not at all.

jstimpfle 4y ago
If writing systems-level code solving for non-trivial requirements, the majority of the state has a lifetime that outlives any particular function call. That's when you need to move that state to the heap. There's no clear scope anymore, ownership has to be moved from function scopes to RAII managed container structures. Things are quickly getting more complicated and expensive (software complexity/bloat, compile times, binary size...) when you have to nest your structures in templated containers that don't know what you're nesting in them... This is where all the complexity with 17 constructor types and 99 move semantics with const, non-const, r-valued references and abstract virtual base classes came from, and there might be less than a dozen persons left on the planet who really understand it all...
- moloch-hai 4y ago
  With RAII, it is trivial to move things from stack to heap, or to a member of something that might be on the stack or heap or in a container, without changing any of the code that implements the object. Most usually you don't need to declare or define any constructors, assignment operators, or a destructor; the compiler provides them, and guarantees they are correct. (Sometimes you provide one constructor as a convenience for users.) It has been many years since I found a use for an abstract virtual base class. Literally millions of people understand it all, and use it every day with no difficulty. You don't need to invent difficulties, or waste days "proofing" code that may be written exactly once and never touched again.
  - BenFrantzDale 4y ago
    To clarify, I think by “move things from stack to heap” you mean “move values from stack to heap”, where, e.g., `std::vector<int>` is a value. The vector’s data is still on the heap (or in the allocator’s pool for `std::pmr::vector<int>`) but the value in the sense of value-semantics is moved from stack to heap.
Too 4y ago
I guess what they mean is moving to static memory allocation, not to the heap. That is something done rather frequently when proofing embedded C code, because it's simply to easy to mess up manual memory management. Only reason to move from stack to heap would be for huge data structures not give stackoverflow, something that can be hard to test for.