Re: sizeof() calculated at compile time or run time
* Default User:
Alf P. Steinbach wrote:
* Default User:
Er, what? How would you have C99-style VLAs that could be sized at
compilation?
Why should C++ variable length array be C99-style?
Unless you bend the definition to where it's meaningless, then I don't
see how any array that can be dynamically created can yield its size at
compile time.
In other words, you now see that your earlier notion was ludicruous.
Could it be that you misunderstood something?
Just a hint... ;-)
But anyway, given that, it would still be problematic in C++ to let
sizeof yield the dynamic size of such an array.
C++ has other means. In C++ you don't expect sizeof to e.g. yield the
dynamic size of a string. Similarly for dynamic arrays.
Not similarly at all. "Array" means something in both C and C++. You
expect sizeof an array to give you the size of the array.
I do not expect what you write in the context of a more abstract array.
And I think you do not expect sizeof(v) where v is std::vector to yield dynamic
size.
Yet std::vector is an array, just not a raw array. That's why we have qualified
terms such as "raw array" to make that distinction. And with vla's we'd probably
invent even more terminology, or again redefine the current one. ;-). I guess
what I'm saying is, your argument is a pure terminological one. And it's partly
at odds with current terminology, and anyway, for the purpose of creation, it's
ungood to get trapped by terminology -- and it's not a fruitful discussion.
std::string
is a totally new thing, part of the selection of container classes.
Those include methods for determining the size.
I think you mean, at the time std::string was introduced it was a new thing. :-)
And VLAs in C++ would be a totally new thing -- at the time of introduction.
Either the syntax and semantics of this "VLA" would have to be so
different as to call into question calling it an array,
Terminological, again.
or you're going
to need some sort of dynamic sizeof operator.
Nope, no need for that.
You don't need it for string or vector, you don't need it for anything.
And it's not just "don't need": it's, it would be a Very Bad Idea, because you
could no longer rely on sizeof as a compile time expression. At least not
without introducing some additional language complexity.
I'm not sure why you're
so resistant to the very idea.
See above.
I suspect that if VLAs ever do make it into C++, they will look a lot
like C99. Your opinion may vary.
It does. :-)
[alloca]
Do they support that specifically for C++, or is it a holdover from
C extensions?
Neither. It's for both languages. See e.g.
http://docs.sun.com/app/docs/doc/819-2243/alloca-3c.
That tells you what it is, not why it's available in C++. It suspect
that it was created for C, and used in C++ pre-STL/std. I think it's
more a holdover than something they feel is specifically needed for C++
(if they even think about it much).
alloca is, for example, heavily used for conversion between narrow and wide
character strings in the Windows API (which supports both, with the base
functionality using wide strings and narrow string functions just as thin and
very efficient wrappers, using alloca). For this purpose of efficiency the
language doesn't much matter. You have the same requirements in C as in C++.
Cheers, & hth.,
- Alf
--
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?