4 ms·

Its unfortunate that C and C++ kept the mindset that automatically memory managed variables are stored on a SMALL stack, with the consequence of exceeding that

by dzdt 8y ago

Its unfortunate that C and C++ kept the mindset that automatically memory managed variables are stored on a SMALL stack, with the consequence of exceeding that small and unknown size being that your program crashes. For variable sized arrays, there is already a bit of overhead in sizing the allocation. Would it really have been impossible to move large allocations to the heap with automatic free at exit of the scope?

maxlybbert 8y ago
C++ has std::vector, which doesn’t have any implicit size limitations. I haven’t kept up with the details, so this may have changed, but during the discussions for what C++11, the committee decided not to include VLAs in the official standard because the library already included std::vector.
- int_19h 8y ago
  The problem with vector is that it always heap-allocates. The ideal approach is the one where small allocations are on the stack, and large ones are on the heap, without the API user having to do anything about it. C++ has had a proposal for std::dynarray floated for a while, which would basically have semantics allowing stack allocation, but wouldn't mandate it, leaving it as a quality of implementation issue (so it would be legal to implement it on top of vector, but it was assumed that compilers would go for optimizations given the opportunity). It didn't pass, unfortunately.
  - geezerjay 8y ago
    > The problem with vector is that it always heap-allocates. How about std::array ?
    - int_19h 8y ago
      It's not dynamically sized - the size is a template parameter, which means that it has to be a compile-time constant.
  - maxlybbert 8y ago
    I guess in theory, you could pull it off with a very clever allocator. Bloomberg’s BDE has an allocator along those lines ( https://bloomberg.github.io/bde/classbdlma_1_1BufferedSequentialAllocator.html https://bloomberg.github.io/bde/classbdlma_1_1BufferedSequen... ), but I don’t think it made it into the standard (memory_resource header). My point is only that runtime-sized arrays may have made it into the C standard, but they aren’t in the C++ standard.
carlmr 8y ago
>For variable sized arrays, there is already a bit of overhead in sizing the allocation. Would it really have been impossible to move large allocations to the heap with automatic free at exit of the scope? Not a compiler writer here so I'm not sure. I think it wouldn't be too difficult, but then this goes very much against the exact control you normally expect from C. And violating expectations like this is usually not good. It would also produce bigger functions in a somewhat opaque manner, because you would need the code to deal with malloc and free and stack allocation at the same time.
plasticchris 8y ago
Not all software written in c has a heap.
- megous 8y ago
  Not all C programs have stack ether. Say Micochip's XC8 compiler for pic14 family.
  - rbanffy 8y ago
    That has to be "fun" to work with...
    - megous 8y ago
      You just can't recurse and the same function can't be called from isr and from main context at the same time. Basically, nothing is re-entrable. Otherwise it's quite fine. To be sure, you shouldn't be doing those things anyway if you have 64B of RAM and 512 words or ROM. :D
- cesarb 8y ago
  And even if it has a heap, the heap might not be available. In a kernel, the function might have been called in interrupt or atomic context; in userspace, the function might be part of the implementation of the heap itself, or a low-level function called before the heap is initialized.
exDM69 8y ago
> Its unfortunate that C and C++ kept the mindset that automatically memory managed variables are stored on a SMALL stack This is not a property of the language, it's a property of the runtime its running on. In a normal userspace program under Linux (at least), you can stack allocate megabytes and the stack will dynamically resize (note that shrinking the stack might not happen in a timely manner). But in kernel space, there's a conscious decision to keep the stack small and not dynamic. While it's not impossible to have dynamic stack in kernel space, that has a lot of implications.
kevin_thibedeau 8y ago
It's unfortunate when system programmers write unportable code that depends on the assumption of having a large stack.
- enriquto 8y ago
  The word "large" does not really mean anything. You are always using the stack, and there is not portable way to check whether it is full or not. Now that is unfortunate.

by dzdt 8y ago

maxlybbert 8y ago

C++ has std::vector, which doesn’t have any implicit size limitations. I haven’t kept up with the details, so this may have changed, but during the discussions for what C++11, the committee decided not to include VLAs in the official standard because the library already included std::vector.

int_19h 8y ago
The problem with vector is that it always heap-allocates. The ideal approach is the one where small allocations are on the stack, and large ones are on the heap, without the API user having to do anything about it. C++ has had a proposal for std::dynarray floated for a while, which would basically have semantics allowing stack allocation, but wouldn't mandate it, leaving it as a quality of implementation issue (so it would be legal to implement it on top of vector, but it was assumed that compilers would go for optimizations given the opportunity). It didn't pass, unfortunately.
- geezerjay 8y ago
  > The problem with vector is that it always heap-allocates. How about std::array ?
  - int_19h 8y ago
    It's not dynamically sized - the size is a template parameter, which means that it has to be a compile-time constant.
- maxlybbert 8y ago
  I guess in theory, you could pull it off with a very clever allocator. Bloomberg’s BDE has an allocator along those lines ( https://bloomberg.github.io/bde/classbdlma_1_1BufferedSequentialAllocator.html https://bloomberg.github.io/bde/classbdlma_1_1BufferedSequen... ), but I don’t think it made it into the standard (memory_resource header). My point is only that runtime-sized arrays may have made it into the C standard, but they aren’t in the C++ standard.

carlmr 8y ago

>For variable sized arrays, there is already a bit of overhead in sizing the allocation. Would it really have been impossible to move large allocations to the heap with automatic free at exit of the scope? Not a compiler writer here so I'm not sure. I think it wouldn't be too difficult, but then this goes very much against the exact control you normally expect from C. And violating expectations like this is usually not good. It would also produce bigger functions in a somewhat opaque manner, because you would need the code to deal with malloc and free and stack allocation at the same time.

plasticchris 8y ago

Not all software written in c has a heap.

megous 8y ago
Not all C programs have stack ether. Say Micochip's XC8 compiler for pic14 family.
- rbanffy 8y ago
  That has to be "fun" to work with...
  - megous 8y ago
    You just can't recurse and the same function can't be called from isr and from main context at the same time. Basically, nothing is re-entrable. Otherwise it's quite fine. To be sure, you shouldn't be doing those things anyway if you have 64B of RAM and 512 words or ROM. :D
cesarb 8y ago
And even if it has a heap, the heap might not be available. In a kernel, the function might have been called in interrupt or atomic context; in userspace, the function might be part of the implementation of the heap itself, or a low-level function called before the heap is initialized.

exDM69 8y ago

> Its unfortunate that C and C++ kept the mindset that automatically memory managed variables are stored on a SMALL stack This is not a property of the language, it's a property of the runtime its running on. In a normal userspace program under Linux (at least), you can stack allocate megabytes and the stack will dynamically resize (note that shrinking the stack might not happen in a timely manner). But in kernel space, there's a conscious decision to keep the stack small and not dynamic. While it's not impossible to have dynamic stack in kernel space, that has a lot of implications.

kevin_thibedeau 8y ago

It's unfortunate when system programmers write unportable code that depends on the assumption of having a large stack.

enriquto 8y ago
The word "large" does not really mean anything. You are always using the stack, and there is not portable way to check whether it is full or not. Now that is unfortunate.