ITYM that *the C99 standard* defines no compile time size for
C99 VLAs.
By definition, a VLA doesn't have a size known at compile time.
That's what the V means: variable.
In practice the fixed size is the size of a pointer or offset.
Where does the pointer suddenly come from? A VLA does convert
implicitly into a pointer, just like any other C style array,
but it's not a pointer, and it doesn't imply a pointer in any
way.
For a C++ VLA it would be that or a higher fixed size (the
pointer or offset is practically unavoidable), e.g. see some
way below.
ITYM that if C99 VLAs didn't conform to C99 standard they
wouldn't be C99 VLAs.
The V in VLA means variable. If the size isn't variable, then
its not a VLA. At least in English.
Yes, it's easy to get trapped in familiar notions, where
anything else seems impossible or doesn't pop up when one
tries to list possibilities.
Or to be trapped by the actual meaning of words in the English
language? The V in VLA means variable. Not a compile time
constant.
Other examples include inability of people to imagine
reasonable semantics for virtual constructors, even teachers
asking students to provide rationalizations why they "can not"
exist (this teaches the students the entirely wrong thing,
namely to rationalize and conform instead of to think
critically independently).
It's actually a good test to see if the student has understood
what virtual means. I'm not sure myself what you mean by a
virtual constructor.
And not to mention the example of static virtual member
function!
The problem there is more that no one has ever found a use for
them. What's the point of declaring a function static if you
need an object on which to call it?
I guess it's one of those features that you don't know you
need until you've been exposed to it.
So you're saying that that no one in the committee has been
exposed to C99? Or to alloca? I have a hard time believing
that.
In Windows, where since early 1990's there's been this divide
between narrow and wide characters, alloca() is much used.
With which compiler? I couldn't find it in the Microsoft
documentation. I did find an _alloca, which looks very much
like the traditional alloca, but the documentation said it is
deprecated.
Not only by the API itself, but also in Microsoft's and
others' libraries, usually via macros. But I guess the need
for converting beween narrow and wide strings hasn't been that
great on *nix.
Typically, no. UTF-8 rules
.
In practice, of course, you do choose one internally, either
UTF-8 or UTF-32, and the conversion occurs at the IO level.
Independently of that, however: what does alloca do here that
std::vector doesn't. I'd say, in fact, that alloca isn't
usable, because you can't realloc, when you find you don't have
enough space. (And you can't really know the length of the
results until you've converted.)
But this is a very interesting question because it brings up
all kinds of nifty usage scenarios, which suggest something
more powerful than C99 VLAs for C++. For example, one
scenario is a function that receives two string arguments,
concatenates them and possibly some more small strings, uses
the concatenation result as a file path and returns handle to
opened file. Here with the strings as simple C strings old
alloca() or a C99 VLA can be used for the result string, very
efficient, but if strings are abstracted in class, efficiency
is difficult!
Now you're kidding. I use std::string for this all the time,
and I've never had the slightest performance problems. At least
on the implementations I use, I can do an awful lot of dynamic
allocation, and the actual time needed is still not even
measurable compared to the time necessary to open a file.
I guess what's needed is some language feature that can pass a
computation of required memory size to alloca() (so that
alloca() can be performed in clean stack frame), and then make
result of alloca() available to the class instance.
Actually, what is needed is just an efficient heap allocator.
Something which all of the systems I normally use have.
And language definition, C++ standard, would have to state
that auto_alloc_ptr or derived class can only be instantiated
by declaring a local variable.
And maybe not in a catch block (Microsoft, at least, says that
its _alloca function should not be used in an exception
handler).
For minimum fixed size of a VLA, i.e. sizeof( myVLAinstance ),
consider
template< typename T >
class vla: private auto_alloc_ptr<T>
{
// ...
};
I think you can see the picture (regarding sizeof) now, yes?
I think that all you're proposing is a somewhat limited version
of auto_ptr, with a (hopefully) faster allocator. I don't see
what that buys us compared to std::vector (with a fast
allocator). And you've yet to show a use case scenario where
std::vector (even with the standard allocator) wouldn't be
superior.
And it has nothing to do with VLA's (which are arrays, not
pointers).
[...]
Why place more strict requirements on VLA than on any other
type?
Any other type has UB if the stack overflows.
It would be silly to require VLA to not be UB in that case.
That's the way C does it. So what you really want is the C
style VLAs. Except that the use case you describe requires
either allocating a worst case maximum (and thus either doing a
lot of additional calculations up front, or guaranteeing stack
overflow), or dyanamic resizing (which isn't possible with VLAs
or alloca).
