By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,763 Members | 1,641 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,763 IT Pros & Developers. It's quick & easy.

sizeof() calculated at compile time or run time

P: n/a
gotta question on sizeof keyword

does the sizeof keyword calcuates the size at compile time or run time ??

-- Posted on news://freenews.netfront.net - Complaints to ne**@netfront.net --
Sep 14 '08 #1
Share this Question
Share on Google+
27 Replies


P: n/a
CodeMonk3y wrote:
gotta question on sizeof keyword

does the sizeof keyword calcuates the size at compile time or run time ??
At compile time.

Sep 14 '08 #2

P: n/a
Rolf Magnus wrote:
CodeMonk3y wrote:
gotta question on sizeof keyword
For the OP, sizeof is an operator.
does the sizeof keyword calcuates the size at compile time or run
time ??

At compile time.
I haven't been keeping up with the changes coming to the standard. Are
variable-length arrays (currently in C99) being added? That's one case
where sizeof is a run-time construct, as the size of such an array
can't be determined at compilation. It's not something really needed in
C++, with std::vector and all.


Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Sep 14 '08 #3

P: n/a
Alf P. Steinbach wrote:
* Default User:
I haven't been keeping up with the changes coming to the standard.
Are variable-length arrays (currently in C99) being added?

No.
I thought it unlikely.
That's one case
where sizeof is a run-time construct, as the size of such an array
can't be determined at compilation.

It might be so in C99, but presumably if variable length array
support was added in C++ it would not be so in C++.
Er, what? How would you have C99-style VLAs that could be sized at
compilation?
>
It's not something really needed in
C++, with std::vector and all.

Current practice says otherwise. Several compilers support e.g.
_alloca, to do in an unsafe way what variable length array support
could do simply and safely.
Do they support that specifically for C++, or is it a holdover from C
extensions?

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Sep 14 '08 #4

P: n/a
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.
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. std::string
is a totally new thing, part of the selection of container classes.
Those include methods for determining the size.

Either the syntax and semantics of this "VLA" would have to be so
different as to call into question calling it an array, or you're going
to need some sort of dynamic sizeof operator. I'm not sure why you're
so resistant to the very idea.

I suspect that if VLAs ever do make it into C++, they will look a lot
like C99. Your opinion may vary.
[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).


Brian

Sep 14 '08 #5

P: n/a
Alf P. Steinbach wrote:
* 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.
No, I don't.
Could it be that you misunderstood something?
I'm not following.
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.
I'm not even sure what this is trying to say.
And I think you do not expect sizeof(v) where v is std::vector to
yield dynamic size.
No, I don't. Why would I? A vector is not an array. It has a member
function for yielding the size. A array does not.
Yet std::vector is an array,
No, it is not. It is a standard container. Arrays are defined in the
standard already. Vectors are not arrays.

I now see that you are the one confused.


Brian
Sep 14 '08 #6

P: n/a
Alf P. Steinbach wrote:

You wrote "You expect sizeof an array to give you the size of the
array". That is false in general. It is only true for a very specific
narrow meaning of "array" (see below), which means that here you're
into terminology discussion.
Which is the definition of array used in C++.

There's a reason they didn't call it std::array.
>
And I think you do not expect sizeof(v) where v is std::vector to
yield dynamic size.
No, I don't. Why would I? A vector is not an array. It has a member
function for yielding the size. A array does not.

Consider what distinguishes "raw array" from "array".
Nothing, as there is no such thing yet.

At any rate, you have nothing to back up your statements. Knowing your
history, you aren't willing reasonably discuss these things, so I'll be
killing this thread. You can post your arguments to whomever else might
be interested.

Brian
Sep 15 '08 #7

P: n/a
Alf P. Steinbach wrote:
>
Hm, ending on a personal attack with insinuations & the works, plus
snipping what contradicts your earlier arguments.
I thought dummy spitting is what Usenet is all about :)

--
Ian Collins.
Sep 15 '08 #8

P: n/a
On Sep 14, 11:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
* Default User:
Alf P. Steinbach wrote:
>That's one case
where sizeof is a run-time construct, as the size of such an array
can't be determined at compilation.
It might be so in C99, but presumably if variable length array
support was added in C++ it would not be so in C++.
Er, what? How would you have C99-style VLAs that could be
sized at compilation?
Why should C++ variable length array be C99-style?
But anyway, given that, it would still be problematic in C++
to let sizeof yield the dynamic size of such an array.
*IF* C++ were to add VLA, there are only two possible choices
with regards to sizeof: make it illegal on a VLA, or say that it
is not a constant if used on a VLA. Since the major argument in
favor of VLA in C++ is C compatibility, I suspect that the
latter would be chosen. But it's really just another question
which would have to be addressed. There are a certain number of
complexities with the way VLA's interact with classes as well,
and apparently, no one felt that they were important enough to
do the work necessary to integrate them into C++.
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.
>It's not something really needed in
C++, with std::vector and all.
Current practice says otherwise. Several compilers support e.g.
_alloca, to do in an unsafe way what variable length array support
could do simply and safely.
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.
Which doesn't mean that it isn't a hold-over from the stone
age:-). We have a lot of things which are the same for both
languages in that category.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 15 '08 #9

P: n/a
Alf P. Steinbach schrieb:
* James Kanze:
>On Sep 14, 11:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
>>* Default User:
Alf P. Steinbach wrote:
>That's one case
>where sizeof is a run-time construct, as the size of such an array
>can't be determined at compilation.
It might be so in C99, but presumably if variable length array
support was added in C++ it would not be so in C++.
>>>Er, what? How would you have C99-style VLAs that could be
sized at compilation?
>>Why should C++ variable length array be C99-style?
>>But anyway, given that, it would still be problematic in C++
to let sizeof yield the dynamic size of such an array.

*IF* C++ were to add VLA, there are only two possible choices
with regards to sizeof: make it illegal on a VLA, or say that it
is not a constant if used on a VLA.

No, that's incorrect.

Instead of those silly, problematic choices, there is always the
rational choice, of letting sizeof do what it already does in all other
cases, providing the known compile time size (as for e.g. string and
vector).

It beats me how you could forget that.
He forget that because a C99 VLA doesn't have a "known compile time size".
> Since the major argument in
favor of VLA in C++ is C compatibility, I suspect that the
latter would be chosen.

Since that argument has been defeated (as well it should be, IMHO! :-)
), if VLAs were adopted it would presumably be due to some better
argument such as practical need demonstrated by existing practice using
unsafe alternatives.
But there already is a safe alternative, so there is little need for
another semi-safe alternative.

--
Thomas
Sep 15 '08 #10

P: n/a
On Sep 15, 5:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Sep 14, 11:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
* Default User:
Alf P. Steinbach wrote:
That's one case
where sizeof is a run-time construct, as the size of such an array
can't be determined at compilation.
It might be so in C99, but presumably if variable length array
support was added in C++ it would not be so in C++.
>Er, what? How would you have C99-style VLAs that could be
sized at compilation?
Why should C++ variable length array be C99-style?
But anyway, given that, it would still be problematic in C++
to let sizeof yield the dynamic size of such an array.
*IF* C++ were to add VLA, there are only two possible choices
with regards to sizeof: make it illegal on a VLA, or say that it
is not a constant if used on a VLA.
No, that's incorrect.
Formally, yes. The standard could always define it to return 42
if used on a VLA:-) Practically, however... (Actually, you may
be right. There are some good arguments for having sizeof of a
VLA always evaluate to zero. It's a possibility I hadn't
considered.)
Instead of those silly, problematic choices, there is always
the rational choice, of letting sizeof do what it already does
in all other cases, providing the known compile time size (as
for e.g. string and vector).
Which is? VLA's don't have a known compile time size. If not,
they wouldn't be VLA's.
It beats me how you could forget that.
Maybe because I'm familiar with what a VLA is.
Since the major argument in favor of VLA in C++ is C
compatibility, I suspect that the latter would be chosen.
Since that argument has been defeated (as well it should be,
IMHO! :-) ), if VLAs were adopted it would presumably be due
to some better argument such as practical need demonstrated by
existing practice using unsafe alternatives.
To date, no one has put forward a better argument, at least not
to the committee.
But it's really just another question which would have to be
addressed. There are a certain number of complexities with
the way VLA's interact with classes as well, and apparently,
no one felt that they were important enough to do the work
necessary to integrate them into C++.
Here you're talking about additional reasons why C99 VLAs are
a braindead notion for C++, yes?
In short, for C++ C99 VLAs are an ungood implementation of VLAs.
No. It's actually a very good implementation. But it would
require some work to adapt, like just about everything else.
Unlike many other things (e.g. the new integral types),
apparently no one felt it was worthwhile.
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.
>>>It's not something really needed in
C++, with std::vector and all.
Current practice says otherwise. Several compilers support e.g.
_alloca, to do in an unsafe way what variable length array support
could do simply and safely.
>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.
Which doesn't mean that it isn't a hold-over from the stone
age:-). We have a lot of things which are the same for both
languages in that category.
Uhm, the addition operation is a hold-over from the stone age.
That does not detract from the usefulness and desirability of addition.
There is a difference. The addition operator is actually used
in serious programs. Every coding guideline I've seen for C has
banned alloca.
It would be nice with a safe modern notation such as '+', for
that operation.
It would be nice if it were rigorously defined in all cases,
with no undefined behavior.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 15 '08 #11

P: n/a
On Sep 15, 6:31 pm, "Alf P. Steinbach" <al...@start.nowrote:
* Thomas J. Gritzan:
Alf P. Steinbach schrieb:
[...]
> Since the major argument in
favor of VLA in C++ is C compatibility, I suspect that the
latter would be chosen.
Since that argument has been defeated (as well it should be, IMHO! :-)
), if VLAs were adopted it would presumably be due to some better
argument such as practical need demonstrated by existing practice using
unsafe alternatives.
But there already is a safe alternative, so there is little need for
another semi-safe alternative.
There is no safe alternative today.
You mean you've never heard of std::vector?
Your use of the term "semi-safe" is argumentative and a slur
on the C++ standardization committee, presuming as a matter of
course that they would choose something only semi-safe.
Just the opposite. Both Thomas and the committee agree that
there is no need for the semi-safe alternative of alloca. (Note
that alloca is so unsafe that even the C committee couldn't be
brought to buy it.)
Do you really find the committee's decisions so generally
incompetent that that can be presumed?
You're the one disagreeing with their decision (by default, to
not adopt VLA's or alloca), not Thomas.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 15 '08 #12

P: n/a
On Sep 15, 10:09*pm, James Kanze <james.ka...@gmail.comwrote:
VLA's don't have a known compile time size. *
This and the other characteristics of VLAs makes them even more
peculiar than static arrays; which already is the most striking type
irregularity in C++. A VLA is not a first-class object. It can only
live on the stack; i.e. function scope. It cannot be copied or
aggregated. As far as type is concerned it only decays to a pointer.

My conclusion is that the VLA feature is more of an allocation
mechanism than a type. Rather than adopt VLAs, i.e. another irregular
array type, I think C++ should rather focus on a dynamic stack
allocation mechanism and find a way to make that accessible to any
type.

Here's an superficial idea I shared on stack allocation in a previous
thread ("size of array is not an integral constant-expression"):

In my view a better solution for dynamic stack allocation in C++
would
be a lower-level feature; as support for a standard library class.
The
ideal would be a general "allocation overload" mechanism for
constructors, so that you can differentiate between construction on
the stack and on the heap. Then some mechanism for allocating stack
space would be used by the "stack constructor". This would allow any
library type, e.g. std::vector, to be optimized for stack allocation.

An idea would be for the language to automatically pass an extra
parameter to the constructor if an object is constructed on the
stack.
This parameter has a built-in type, say std::auto_allocator, which
allows allocation of stack space in the parent frame; i.e. the stack
frame in which the construction takes place. For example,

vector (size_t n, std::auto_allocator& a)
: buf (a.alloc (n * sizeof T)) {...}

Aside: Many C++ implementations provide a stack allocation feature as
an extension (alloca). Unfortunately, alloca cannot be used to create
a data type that mimics a VLA since it allocates memory in the stack
frame of the caller; i.e. you will have to call it explicitly; it
cannot be encapsulated.

Regards,
Vidar Hasfjord

Sep 16 '08 #13

P: n/a
On Sep 16, 12:50 am, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Sep 15, 6:31 pm, "Alf P. Steinbach" <al...@start.nowrote:
* Thomas J. Gritzan:
Alf P. Steinbach schrieb:
[...]
>>> Since the major argument in
favor of VLA in C++ is C compatibility, I suspect that the
latter would be chosen.
Since that argument has been defeated (as well it should
be, IMHO! :-)), if VLAs were adopted it would presumably
be due to some better argument such as practical need
demonstrated by existing practice using unsafe
alternatives.
>But there already is a safe alternative, so there is
little need for another semi-safe alternative.
There is no safe alternative today.
You mean you've never heard of std::vector?
std::vector is not an alternative when you want fast stack
allocation.
What does it matter where the memory is allocated? And as for
speed, that's really a question of optimization---good
allocators can be very, very fast too.
You know that.
I don't see what VLAs buy me that std::vector doesn't.
Your use of the term "semi-safe" is argumentative and a slur
on the C++ standardization committee, presuming as a matter of
course that they would choose something only semi-safe.
Just the opposite. Both Thomas and the committee agree that
there is no need for the semi-safe alternative of alloca.
That's meaningless and you know it.
It's a direct rebuttal of your statement that Thomas made a slur
on the C++ standardization committee. Thomas and the committee
are apparently in complete agreement: there is no need for a
semi-safe, alloca based solution.
There is no single "the" alternative.
And that non-existent thing is not semi-safe.
What non-existent thing? VLA's and alloca exist in C, so we can
judge them.
You're doing the same as Thomas.
You mean being reasonable, and understanding the issues.
You're saying the committee would not be able to come with
something competently designed, only "semi-safe" -- but that
reflects on yourself, as a member.
No. We're saying that the committee has already provided a
relatively safe alternative (std::vector), so there's no need to
to adopt a semi-safe solution (VLA's or alloca).
(Note that alloca is so unsafe that even the C committee
couldn't be brought to buy it.)
Do you really find the committee's decisions so generally
incompetent that that can be presumed?
You're the one disagreeing with their decision (by default, to
not adopt VLA's or alloca),
That is untrue and you know it; I haven't argued for adoption
of either alloca or C99 VLAs.
So what are you arguing. If we all agree that std::vector is
sufficient, and nothing else is needed, there's no need to
argue.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 16 '08 #14

P: n/a
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Sep 15, 5:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
On Sep 14, 11:08 pm, "Alf P. Steinbach" <al...@start.nowrote:
* Default User:
Alf P. Steinbach wrote:
>That's one case
>where sizeof is a run-time construct, as the size of such an array
>can't be determined at compilation.
It might be so in C99, but presumably if variable length array
support was added in C++ it would not be so in C++.
>>>Er, what? How would you have C99-style VLAs that could be
sized at compilation?
>>Why should C++ variable length array be C99-style?
>>But anyway, given that, it would still be problematic in C++
to let sizeof yield the dynamic size of such an array.
>*IF* C++ were to add VLA, there are only two possible choices
with regards to sizeof: make it illegal on a VLA, or say that it
is not a constant if used on a VLA.
No, that's incorrect.
Formally, yes. The standard could always define it to return 42
if used on a VLA:-) Practically, however... (Actually, you may
be right. There are some good arguments for having sizeof of a
VLA always evaluate to zero. It's a possibility I hadn't
considered.)
Instead of those silly, problematic choices, there is always
the rational choice, of letting sizeof do what it already does
in all other cases, providing the known compile time size (as
for e.g. string and vector).
Which is? VLA's don't have a known compile time size.
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.
If not, they wouldn't be VLA's.
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.
It beats me how you could forget that.
Maybe because I'm familiar with what a VLA is.
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?
>Since the major argument in favor of VLA in C++ is C
compatibility, I suspect that the latter would be chosen.
Since that argument has been defeated (as well it should
be, IMHO! :-) ), if VLAs were adopted it would presumably
be due to some better argument such as practical need
demonstrated by existing practice using unsafe
alternatives.
To date, no one has put forward a better argument, at least
not to the committee.
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).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 16 '08 #15

P: n/a
On Sep 16, 8:26 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 15, 10:09 pm, James Kanze <james.ka...@gmail.comwrote:
VLA's don't have a known compile time size.
This and the other characteristics of VLAs makes them even
more peculiar than static arrays; which already is the most
striking type irregularity in C++. A VLA is not a first-class
object. It can only live on the stack; i.e. function scope.
That's not true in C, although there are some restrictions.
It cannot be copied or aggregated.
It can certainly be aggregated in C, although it must be the
last element in a structure. And it can be copied in the same
way you copy any array in C: with memcpy.
As far as type is concerned it only decays to a pointer.
No. It has an array type.
My conclusion is that the VLA feature is more of an allocation
mechanism than a type.
Not at all, although from another posting, I gather that that is
what Alf really wants: not VLAs, but a type-safe alloca.
(Something which bears the same relation to alloca that the new
operator bears to malloc. Perhaps a special placement new?)
Rather than adopt VLAs, i.e. another irregular array type, I
think C++ should rather focus on a dynamic stack allocation
mechanism and find a way to make that accessible to any type.
Why? What does that buy us?

[...]
Aside: Many C++ implementations provide a stack allocation
feature as an extension (alloca).
Typically, only because it's part of the basic C library,
inherited from Berkley Unix, many, many years ago. In practice,
it's not used in well written code, and none of the
standardization organizations have wanted anything to do with
it. (It's not Posix, nor standard Unix.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 16 '08 #16

P: n/a
On Sep 16, 11:50*am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
Amen. And automatic optimization of heap allocation to stack
allocation when escape analysis proves it is safe (and the size is
bounded) . This is something that Java compilers have been doing for a
while, probably there are c++ compilers that do it too, but not those
I'm familiar with.

--
gpd
Sep 16 '08 #17

P: n/a
On Sep 16, 12:06 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
Amen. And automatic optimization of heap allocation to stack
allocation when escape analysis proves it is safe (and the
size is bounded) . This is something that Java compilers have
been doing for a while, probably there are c++ compilers that
do it too, but not those I'm familiar with.
It's far more difficult (if not impossible) in C++ because C++
doesn't allow compacting garbage collection. You can't move
objects around in C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 16 '08 #18

P: n/a
On Sep 15, 2:44*am, "CodeMonk3y" <CodeMon...@gpu.comwrote:
gotta question on sizeof keyword

does the sizeof keyword calcuates the size at compile time or run time ??

-- Posted on news://freenews.netfront.net - Complaints to n...@netfront.net --
sizeof() calcuates the size at compile time

vairable array won't measured by sizeof()

just like vector.size()
Sep 16 '08 #19

P: n/a
On Sep 16, 4:21*pm, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:06 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
Amen. And automatic optimization of heap allocation to stack
allocation when escape analysis proves it is safe (and the
size is bounded) . This is something that Java compilers have
been doing for a while, probably there are c++ compilers that
do it too, but not those I'm familiar with.

It's far more difficult (if not impossible) in C++ because C++
doesn't allow compacting garbage collection. *You can't move
objects around in C++.
Hum... if the compiler can prove statically that the lifetime of an
heap allocation is restricted to a lexical scope, it certainly could.
It doesn't require a compacting GC nor a GC at all.

Think for example of a stack allocated std::string: its internal
buffer could be stack allocated as well. I do not think it require
any extraordinary work for the compiler to figure it out.

--
gpd
Sep 16 '08 #20

P: n/a
On Sep 16, 6:18 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 4:21 pm, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:06 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
Amen. And automatic optimization of heap allocation to stack
allocation when escape analysis proves it is safe (and the
size is bounded) . This is something that Java compilers have
been doing for a while, probably there are c++ compilers that
do it too, but not those I'm familiar with.
It's far more difficult (if not impossible) in C++ because C++
doesn't allow compacting garbage collection. You can't move
objects around in C++.
Hum... if the compiler can prove statically that the lifetime
of an heap allocation is restricted to a lexical scope, it
certainly could. It doesn't require a compacting GC nor a GC
at all.
That's another way of obtaining the performance. If the
compiler can determine a maximum size, it wouldn't even have to
use dynamic allocation. Unless the compiler has built-in
knowledge of std::vector, however, it's very difficult to do.
Think for example of a stack allocated std::string: its
internal buffer could be stack allocated as well. I do not
think it require any extraordinary work for the compiler to
figure it out.
Again, it depends. With knowledge of std::string built into the
compiler, it wouldn't be too difficult if the object was never
passed to an external function. Even without built in
knowledge, it would be possible. Once a reference to the string
"escapes" from the function, however, it becomes much, much
harder.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 16 '08 #21

P: n/a
Vidar Hasfjord wrote:
Rather than adopt VLAs, i.e. another irregular
array type, I think C++ should rather focus on a dynamic stack
allocation mechanism and find a way to make that accessible to any
type.
Sounds like premature optimization to me. Humans are notoriously bad at
anticpating where the inefficiencies will be in their code. Write it to
be readable and maintainable, then if it performs poorly, profile it,
and optimize the parts the performance profile says need optimizing.
--
Fran
Sep 17 '08 #22

P: n/a
On Sep 16, 10:45*pm, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 6:18 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 4:21 pm, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:06 pm, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 12:23 am, "Alf P. Steinbach" <al...@start.nowrote:
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.
Amen. And automatic optimization of heap allocation to stack
allocation when escape analysis proves it is safe (and the
size is bounded) . This is something that Java compilers have
been doing for a while, probably there are c++ compilers that
do it too, but not those I'm familiar with.
It's far more difficult (if not impossible) in C++ because C++
doesn't allow compacting garbage collection. *You can't move
objects around in C++.
Hum... if the compiler can prove statically that the lifetime
of an heap allocation is restricted to a lexical scope, it
certainly could. *It doesn't require a compacting GC nor a GC
at all.

That's another way of obtaining the performance. *If the
compiler can determine a maximum size, it wouldn't even have to
use dynamic allocation. *Unless the compiler has built-in
knowledge of std::vector, however, it's very difficult to do.
It only need to 'see' inside the std::vector and find the call to
'new' and the companion call to 'delete'.
>
Think for example of a stack allocated std::string: its
internal buffer could be stack allocated as well. I do not
think it *require any extraordinary work for the compiler to
figure it out.

Again, it depends. *With knowledge of std::string built into the
compiler, it wouldn't be too difficult if the object was never
passed to an external function. *
It only need builtin knowledge of memory allocation primitives
(something I'm sure most compilers already have). If by static
analysis it can prove that a memory allocation is always freed at the
end of scope and it can prove that the allocation size cannot exceed a
certain value (or has a fallback mechanism for that), then it can
convert a call to new in the equivalent of alloca+placement new.
Even without built in
knowledge, it would be possible. Once a reference to the string
"escapes" from the function, however, it becomes much, much
harder.
Of course, this is why you need escape analysis.

--
gpd
Sep 17 '08 #23

P: n/a
On Sep 17, 11:07 am, gpderetta <gpdere...@gmail.comwrote:
On Sep 16, 10:45 pm, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 6:18 pm, gpderetta <gpdere...@gmail.comwrote:
[...]
Hum... if the compiler can prove statically that the lifetime
of an heap allocation is restricted to a lexical scope, it
certainly could. It doesn't require a compacting GC nor a GC
at all.
That's another way of obtaining the performance. If the
compiler can determine a maximum size, it wouldn't even have to
use dynamic allocation. Unless the compiler has built-in
knowledge of std::vector, however, it's very difficult to do.
It only need to 'see' inside the std::vector and find the call
to 'new' and the companion call to 'delete'.
And verify, of course, that no other function called modifies
the pointer. Except, of course, that in most uses, the call to
new isn't in the constructor. The real optimization problem
with std::vector is to make a sequence of successive push_back
rapid.
Think for example of a stack allocated std::string: its
internal buffer could be stack allocated as well. I do not
think it require any extraordinary work for the compiler to
figure it out.
Again, it depends. With knowledge of std::string built into the
compiler, it wouldn't be too difficult if the object was never
passed to an external function.
It only need builtin knowledge of memory allocation primitives
(something I'm sure most compilers already have).
It needs to ensure that no other functions modify the pointer.
A lot do, and there are generally a lot of indirections involved
in calling them.
If by static analysis it can prove that a memory allocation is
always freed at the end of scope and it can prove that the
allocation size cannot exceed a certain value (or has a
fallback mechanism for that), then it can convert a call to
new in the equivalent of alloca+placement new.
The key here (and with std::vector) is, first, proving that
allocation size cannot exceed a certain value, and second, that
doing just one allocation with this value, rather than the
allocation/copy/free which occurs when the capacity is increased
doesn't change the guaranteed semantics, is what requires
internal knowledge: the user may have replaced to global
operator new (making calls to the function "observable
behavior"), and in the case of std::vector, the copy
constructors may have side effects. The transformation is never
the less legal, because the standard explicitly allows
std::string and std::vector to have any capacity they want after
construction, but there's nothing in the code that indicates
this.

The problem with std::string is simpler, because the compiler
knows that copying char or wchar_t has no observable side
effects, so one part of the problem is solved. And I'm sure
that an optimization which ignored possible "observable
behavior" in operator new would be acceptable (although it
should be documented as "not strictly conforming").
Even without built in knowledge, it would be possible. Once
a reference to the string "escapes" from the function,
however, it becomes much, much harder.
Of course, this is why you need escape analysis.
Which generally means intermodule analysis; most people pass
strings and vectors by reference, and not by value. (And even
if the reference is const, if the original object is non-const,
the called function may legally cast away const and modify the
object anyway.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 17 '08 #24

P: n/a
Francis Litterio wrote:
>
>Rather than adopt VLAs, i.e. another irregular
array type, I think C++ should rather focus on a dynamic stack
allocation mechanism and find a way to make that accessible to any
type.

Sounds like premature optimization to me. Humans are notoriously bad at
anticpating where the inefficiencies will be in their code. Write it to
be readable and maintainable, then if it performs poorly, profile it,
and optimize the parts the performance profile says need optimizing.
There's no such thing as abstract "premature optimization", i.e. there's
not such thing as "premature optimization" outside of the context of
concrete piece of code.

To say that C++ doesn't need VLAs or stack allocation mechanism because
of "premature optimization" considerations is no different than to say
that the whole C++ is just one big "premature optimization" compared to,
say, Java.

--
Best regards,
Andrey Tarasevich
Sep 17 '08 #25

P: n/a
Vidar Hasfjord wrote:
>
My conclusion is that the VLA feature is more of an allocation
mechanism than a type.
Well, yes. VLAs are a typed allocation mechanism that is free of the
problems inherent to 'alloca'.
Rather than adopt VLAs, i.e. another irregular
array type, I think C++ should rather focus on a dynamic stack
allocation mechanism and find a way to make that accessible to any
type.
Actually, VLAs, among other things, are an attempt to work around some
problems inherent to explicit allocation mechanisms. VLAs are objects
that need to be _declared_, thus restricting the points of actual
allocation to the set of locations where declarations are permitted by
the language. "Allocation mechanisms" on the other hand, are not usually
tied to declarations, but most of the time are accessible within
_expressions_ (i.e. virtually anywhere), which might easily leads to
problems with allocating stack space, like when 'alloca' is called in
the function call argument list

foo(<smthng>, alloca(42), <smthng>)

Of course, one can argue that the problems that arise in cases like that
are inherent to the "traditional" implementation of stack frame
management and that some alternative approach can be used to solve them.
Although apparently there's no good alternative approach that would
maintain the [fortunately] still-valued efficiency of the code.

--
Best regards,
Andrey Tarasevich
Sep 17 '08 #26

P: n/a
On Sep 16, 11:00*am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 8:26 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 15, 10:09 pm, James Kanze <james.ka...@gmail.comwrote:
VLA's don't have a known compile time size.
This and the other characteristics of VLAs makes them even
more peculiar than static arrays; which already is the most
striking type irregularity in C++. A VLA is not a first-class
object. It can only live on the stack; i.e. function scope.

That's not true in C, although there are some restrictions.
No. Declarations of VLAs must be at either block scope or function
prototype scope. A VLA cannot be extern, static or a member. See
below.
It can certainly be aggregated in C, although it must be the
last element in a structure. *
No. That is a flexible array member (FAM); also introduced in C99.
Flexible array members allow incomplete array struct members without
bounds; and must be the last member as you say. See

http://www.comeaucomputing.com/techtalk/c99
As far as type is concerned it only decays to a pointer.

No. *It has an array type.
My conclusion is that the VLA feature is more of an allocation
mechanism than a type.

Not at all, although from another posting, I gather that that is
what Alf really wants: not VLAs, but a type-safe alloca.
(Something which bears the same relation to alloca that the new
operator bears to malloc. *Perhaps a special placement new?)
Rather than adopt VLAs, i.e. another irregular array type, I
think C++ should rather focus on a dynamic stack allocation
mechanism and find a way to make that accessible to any type.

Why? *What does that buy us?
Not much... :-)

My point is simply that if such an optimized allocation feature is
found to be wanted for C++, then C++ should look for better (more
regular) ways of achieving it. Automatic compiler optimization would
of course be the ideal.

Regards,
Vidar Hasfjord
Sep 17 '08 #27

P: n/a
On Sep 18, 12:37 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 16, 11:00 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 16, 8:26 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 15, 10:09 pm, James Kanze <james.ka...@gmail.comwrote:
VLA's don't have a known compile time size.
This and the other characteristics of VLAs makes them even
more peculiar than static arrays; which already is the most
striking type irregularity in C++. A VLA is not a first-class
object. It can only live on the stack; i.e. function scope.
That's not true in C, although there are some restrictions.
No. Declarations of VLAs must be at either block scope or
function prototype scope. A VLA cannot be extern, static or a
member.
Yes. The C standard seems to distinguish between arrays with a
variable length, used as local arguments, and arrays with a
variable length placed at the end of a struct; in the latter
case, it considers the array to have an incomplete type (which
it calls a flexible array member), rather than being a "variable
length array". I hadn't noticed that before; in my mind, they
were both variable length arrays (since both are used as
variable length arrays).

This has a number of repercusions, and definitely simplifies the
adaptation in C++, since most of the problems concern flexible
array members, and not what C calls variable length arrays.
Off hand, I don't see any problems with adopting this
definition of VLA directly in C++, without any changes from C.
But I imagine there are some; otherwise, I can't see why the
committee didn't do it. Flexible arrays pose all sorts of
problems with regards to inhertance, constructors and
destructors, assignment, etc. (Come to think of it, how does C
handle the problem of assignment?) Interestingly enough, sizeof
is a constant expression when applied to a struct with a
flexible array. Logically, this would suggest that sizeof
should always return 0 when applied to a VLA, but I guess the C
committee wanted to maintain the use of sizeof in array
addressing in the case of an array of VLAs.

It's also a question why the C committee didn't allow something
like:

struct A { int i; int j; double a[i][j]; } ;

There's no reason this can't be made to work, as long as it's
not an object with static lifetime, and it would seem very
useful.
See below.
It can certainly be aggregated in C, although it must be the
last element in a structure.
No. That is a flexible array member (FAM); also introduced in
C99. Flexible array members allow incomplete array struct
members without bounds; and must be the last member as you
say. See
http://www.comeaucomputing.com/techtalk/c99
So I see. I don't know why; I've always thought of them as more
or less the same thing. (Actually, I do know why; I was
influenced by another, very influent member of the C++
committee. Which may explain why the integration of VLA's
wasn't considered.)

Anyway, this point changes my opinion completely with regards to
VLAs. Without the problems which allowing them in a class
introduces, simple C compatibility should be enough of a reason.
(The traditional rule is "as close to C as possible, but no
closer". Unless there's a good reason for not being compatible
with C, we should be.)
As far as type is concerned it only decays to a pointer.
No. It has an array type.
My conclusion is that the VLA feature is more of an allocation
mechanism than a type.
Not at all, although from another posting, I gather that that is
what Alf really wants: not VLAs, but a type-safe alloca.
(Something which bears the same relation to alloca that the new
operator bears to malloc. Perhaps a special placement new?)
Rather than adopt VLAs, i.e. another irregular array type, I
think C++ should rather focus on a dynamic stack allocation
mechanism and find a way to make that accessible to any type.
Why? What does that buy us?
Not much... :-)
On the other hand, as long as the concept of VLA and flexible
arrays is well separated in C, the effort to add VLAs to C++
wouldn't have gone much beyond copy/paste. And they are useful
in the case of multidimensional arrays (which curiously, no one
in this thread has mentionned as a motivation): using
std::vector for a multidimentional array (except within the
implementation of your own multidimentional array class) is
exceedingly painful, and std::valarray doesn't seem to be widely
used either.

Of course, there is the problem that C style arrays are broken
to begin with. But off hand, even ignoring the performance (and
static vs. dynamic initialization issues), I don't see any good
alternative for multidimensional arrays. (But maybe I just
haven't looked hard enough. In my own work, I don't need them.)
My point is simply that if such an optimized allocation
feature is found to be wanted for C++, then C++ should look
for better (more regular) ways of achieving it. Automatic
compiler optimization would of course be the ideal.
I don't think that the optimization is that much of an issue.
Modern allocators can be very fast, and various other
considerations make variable stack allocation more and more
difficult. The real issue, IMHO, is multidimensional arrays.
Because let's face it:
std::vector< std::vector< double
a( 10, std::vector< double >( 20 ) ) ;
instead of:
double a[ 20 ][ 10 ] ;
really isn't very programmer friendly. (Also, of course, the
former cannot easily be passed to other languages, which
generally do have multidimensional arrays, and lay them out
contiguously in memory.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 18 '08 #28

This discussion thread is closed

Replies have been disabled for this discussion.