5 ms·

There is no real need for runtime sized arrays, as one could already use vectors (which are more comfortable to use than C-style arrays anyway) and allocate the

by flebron 14y ago

There is no real need for runtime sized arrays, as one could already use vectors (which are more comfortable to use than C-style arrays anyway) and allocate them on the stack (that's one of the template parameters of std::vector, its allocator). If one were to be a masochist, one could also alloca and then use placement new, with all the shortcomings of alloca. Granted, it's syntactically shorter to say int x[n], but it's the same behavior as above, and one would need to see what changes have to be made to the runtimes and the standard to allow for this, and how to report errors such as "There is no more space on the stack" (which is going to be much more frequent than running out of heap space). As for "generic lambdas", I don't find that typing the type of your parameter is too annoying at the moment, though I haven't used the feature much. Perhaps this is a baby step in a move to make C++ a bit more Haskell-like: Strong typing, but also powerful type inference mechanism. Other languages have more features, that's true. But C++ is still trying to advocate a blazingly fast speed, and pay-for-what-you-use mentality. That the language can still be the fastest, one of the most powerful, and achieve feature parity with current dynamic languages, I think reflects well on the language, not the opposite.

dllthomas 14y ago
Your first two paragraphs here seem contradictory. If the feature can already be implemented, and the cost is merely some syntactic messiness, then there is no change necessary to the runtimes - all you need is a little syntactic sugar. As an aside, there is a grand history of array notation being nothing more than syntax. Try building the following in gcc: int main() { int foo[] = {1, 2, 3}; return 1[foo]; } The expression a[b] is simply translated into a + b, which commutes. There's some constraint applied that something there be a pointer (so 1[2] is rejected) but it's weaker than it "should" be...
- flebron 14y ago
  Sorry, I misspoke - I didn't mean the runtime (what would that really be?) but the compilers. That is, I do not know, a priori, that the internal type system would deal equally well with constant sized arrays, as with variable based ones. Currently the size of all variables on stack is determined at compile time, and the compiler generates code for those offsets. If this now changes, one would have to see what needs to change in the compiler internally, and the executable that gets output by it. It can certainly "be done", but things need to change in order to accomodate it as part of the language.
cygx 14y ago
> There is no real need for runtime sized arrays, as one could already use vectors [...] and allocate them on the stack And how exactly would you do that? alloca() aside, there is no such thing as a stack allocator.
- flebron 14y ago
  There's several projects that have seen the need to allocate variable length things on the stack, Chromium was one[1]. A quick googling sends me to [2] as well. I haven't ever found myself in a situation where I _needed_ my stuff to be stack allocated, but then again I've never done really low level programming or embedded code, and I guess it could happen there. [1] http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_container.h http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_c... [2] http://home.roadrunner.com/~hinnant/stack_alloc.html http://home.roadrunner.com/~hinnant/stack_alloc.html
  - cygx 14y ago
    These just allocate a fixed-sized stack buffer and overflow to the heap - no variable-length stack allocation happens.
    - flebron 14y ago
      Right, because alloca is the only thing (as far as I know) that can resize the stack. There is not going to be anything else that does the same thing. The best one can do is those stack allocators which overflow to heap, or an alloca-based stack allocator. There's an interesting discussion[1] at comp.std.c++ about implementing VLAs in C++0x, and the issues with dynamic stack resizing. [1] https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/K_4lgA1JYeg https://groups.google.com/forum/?fromgroups=#!topic/comp.std...

by flebron 14y ago

dllthomas 14y ago

Your first two paragraphs here seem contradictory. If the feature can already be implemented, and the cost is merely some syntactic messiness, then there is no change necessary to the runtimes - all you need is a little syntactic sugar. As an aside, there is a grand history of array notation being nothing more than syntax. Try building the following in gcc: int main() { int foo[] = {1, 2, 3}; return 1[foo]; } The expression a[b] is simply translated into a + b, which commutes. There's some constraint applied that something there be a pointer (so 1[2] is rejected) but it's weaker than it "should" be...

flebron 14y ago
Sorry, I misspoke - I didn't mean the runtime (what would that really be?) but the compilers. That is, I do not know, a priori, that the internal type system would deal equally well with constant sized arrays, as with variable based ones. Currently the size of all variables on stack is determined at compile time, and the compiler generates code for those offsets. If this now changes, one would have to see what needs to change in the compiler internally, and the executable that gets output by it. It can certainly "be done", but things need to change in order to accomodate it as part of the language.

cygx 14y ago

> There is no real need for runtime sized arrays, as one could already use vectors [...] and allocate them on the stack And how exactly would you do that? alloca() aside, there is no such thing as a stack allocator.

flebron 14y ago
There's several projects that have seen the need to allocate variable length things on the stack, Chromium was one[1]. A quick googling sends me to [2] as well. I haven't ever found myself in a situation where I _needed_ my stuff to be stack allocated, but then again I've never done really low level programming or embedded code, and I guess it could happen there. [1] http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_container.h http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_c... [2] http://home.roadrunner.com/~hinnant/stack_alloc.html http://home.roadrunner.com/~hinnant/stack_alloc.html
- cygx 14y ago
  These just allocate a fixed-sized stack buffer and overflow to the heap - no variable-length stack allocation happens.
  - flebron 14y ago
    Right, because alloca is the only thing (as far as I know) that can resize the stack. There is not going to be anything else that does the same thing. The best one can do is those stack allocators which overflow to heap, or an alloca-based stack allocator. There's an interesting discussion[1] at comp.std.c++ about implementing VLAs in C++0x, and the issues with dynamic stack resizing. [1] https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/K_4lgA1JYeg https://groups.google.com/forum/?fromgroups=#!topic/comp.std...