Re: array size known/not known in compile time
* James Kanze:
Alf P. Steinbach wrote:
* James Kanze:
Alf P. Steinbach wrote:
* James Kanze:
[VLA] is likely to use dynamic
allocation under the hood in all but the simplest cases.
It seems to me you mean, you can think of /one/ pretty esoteric case
where dynamic allocation would be a practical necessity. Otherwise it's
not meaningful to do dynamic allocation to implement a feature meant to
avoid dynamic allocation. What is that case?
I would imagine that it is the general case.
Then it shouldn't be hard to provide a concrete example of this general
case?
Not having access to all of the C compilers which support VLA,
it's hard to give specific examples (all of which depend on the
compiler implementation). Off hand, I'd expect that as soon as
the array reached a certain size, you'd have problems---a lot of
systems limit stack size, and the only other available memory is
the heap. (On some systems, too, you cannot simply arbitrarily
increase the size of the stack.)
I'd expect the opposite: that a compiler would not add inefficient
safety measures to handle stack-size-relative and recursion-relative and
risk-relative "large" size for a non-static local variable.
I've never seen a compiler implement
struct Larg { char ohoi[verylargeindeed]; };
void foo(){ Larg o; ... }
by doing something like
void foo(){ std::auto_ptr<Larg> _p( new Larg ); Larg& o( *_p ); ... }
and I would complain very loudly if it did... And as for Larg, so also
for any type, especially a VLA which has stack alloc as a cornerstone.
But then, I don't regularly examine the produced machine code; perhaps
current compilers really do lend such "helping" hands behind the scenes,
resulting in the inordinately slow software we nowadays have to use?
Most of the real use I've seen for VLA has been in dynamically
allocated memory anyway---as an alternative to the dirty struct
hack. That, and multi-dimensional arrays where none of the
dimensions is known at compile time. This is the first time
I've heard performance mentionned as an issue.
It's extremely common in Windows software, but then using alloca, not
VLA (it amounts to the same thing except alloca is very very unsafe).
The reason being that Windows API and libraries are partly 8 bit per
char and partly 16 bit per char. Doing dynamic allocation and
deallocation for every little string conversion has a high cost.
[snip]
... a compiler does not in general know about the intended usage of the
vector and of the stack (how much we're willing to put on the stack),
and so a compiler cannot in general do the optimization on behalf of the
programmer.
A compiler may not know the intended usage, but it can certainly
find out the actual usage. (Not many do at present, doubtlessly
because the compiler writers have been too busy implementing
just implementing the standard language to have had time to
attact optimization in general.)
I disagree. But even if I agreed that it could, which I don't, there is
the question of whether such "help" for e.g. std::vector and std::string
is desirable. For no apparent reason your little program runs out of
stack space... If you have control, as with VLA, then you can control
it. If you don't have control, then you're left at the mercy of
arbitrary uninformed decisions made by the "Office Assistant" compiler,
which knows nothing of e.g. expected recursion depth, stack requirements
of called functions, the handling or not of std::bad_alloc in the code,
etc., in short the real factors behind a decision to use VLA or not.
And
the fact that std::vector is part of the standard means that a
compiler is free to use the same techniques as VLA's, in the
rare cases in which they can avoid a dynamic allocation.
I'm sorry but that's not meaningful to me.
The fact (assuming it is a fact) that there are very few cases where
std::vector buffer allocation can be optimized as stack allocation, is
an argument that std::vector is a practical alternative to VLAs?
It seriously weakens one of the arguments for VLAs.
Sorry, that's still meaningless to me -- a contradiction, where a
simple, trivial, not at all hard to understand argument in favor of VLAs
is construed as somehow (unspecified) being an argument against VLAs.
Not against. Just not a real argument for either.
A slight improvement here. I gather from comments made above that (A)
it is assumed that the compiler can detect where it's a good idea to do
stack based allocation, and (B) it is assumed that such cases are a
subset of the (assumed) rare cases where e.g. std::vector can be safely
tweaked that way. Regarding (A), there's no way the compiler can know
what the programmer knows and wants, as discussed above, and regarding
(B), well, (B) doesn't then matter at all ;-).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]