tryick use of sizeof again[Explaination Wanted]
goac...@gmail.com
int v=sizeof ++ch;
cout<<ch<<endl;// output: 'a'
why not 'b'?
thanks
Lew Pitcher
> char ch='a';
>
> int v=sizeof ++ch;
>
> cout<<ch<<endl;// output: 'a'
>
> why not 'b'
Who knows the vagarities of C++? Why not ask in comp.lang.c++ instead
of here? We don't deal with C++ here, only C
jacob navia
sizeof expressions are NOT evaluated. Only the type is important
to get the size of it.
Charlie Gordon
1189783522.9...@w3g2000hsg.googlegroups.com...
Why be unnecessarily obtuse when the issue is not C++ specific.
sizeof expr computes the size in bytes of the object denoted by expr without
producing code for evaluating that expression. Therefore ch is not
incremented.
--
Chqrlie.
Punkie
indeed. Consider sizeof to be
size_t sizeof(type)
and not
size_t sizeof(int)
christian.bau
> Why be unnecessarily obtuse when the issue is not C++ specific.
How do you know it is not C++ specific? For example, after
char c - '0';
c += sizeof ('0');
what is the value stored in c? There are subtle differences between
the sizeof operator in C and C++, and someone knowing absolutely
everything about C but nothing about C++ would most likely not know
the right answer to the problem I wrote.
Keith Thompson
If you're going to post code here, please make sure it's C, not C++.
It's also helpful to post a (small) complete program rather than an
isolated snippet.
'cout', '<<', and 'endl' are specific to C++.
Your underlying question happens, in this particular case, to be
equally valid in both languages, but there are subtle differences
between C and C++ that even the C experts here may not be aware of.
Just this once, I'll show you a C version of your program.
#include <stdio.h>
int main(void)
{
char ch = 'a';
int v = sizeof ++ch;
printf("%c\n", ch);
return 0;
}
Next time, please either post C in the first place, or post to
comp.lang.c++. If you're having trouble knowing the difference, you
need to learn one language or the other (perhaps eventually both).
A newsgroup is not a good place to do that, but
alt.comp.lang.learn.c-c++ might be more appropriate for your purposes
than comp.lang.c.
Several people have already given you the answer to your question --
which is unfortunate, since the question looks very much like
homework. An expression like 'sizeof ++ch' isn't something that you'd
write if your goal is to accomplish something. It was almost
certainly written by someone trying to make a specific point.
If you want us to do your homework for you, please post your
instructor's e-mail address so we can submit our solutions directly.
We're willing to provide hints if you've done some of the work
yourself and you're stuck on something, but we won't (usually) do it
for you.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
This is not the case for the problem at hand. Both C and C++
do not evaluate the expression of a sizeof.
Martin Wells
sizeof is a handy way of ensuring that an expression is legal without
actually evaluating the expression. For instance, you could have code
something like the following:
typedef ... SomeType;
void Func(SomeType const *p)
{
sizeof (p->val); /* Ensure that SomeType has a member called
val */
}
Martin
Martin Wells
> the sizeof operator in C and C++, and someone knowing absolutely
> everything about C but nothing about C++ would most likely not know
> the right answer to the problem I wrote.
There's no subtle differences between C and C++ in this respect. Or
even differences for that matter.
Martin
Keith Thompson
(I assume you mean the operand, not the expression.)
That's nearly correct. In C, if the type of the operand is a variable
length array type, then the operand is evaluated. C++, as far as I
know, doesn't have variable length arrays.
Of course, there are no VLAs in the posted code.
Ian Collins
Please don't snip attributions.
As Keith pointed out, VLAs muddy the waters.
#include <stdio.h>
int main(void) {
const int N = 42;
int data[N];
printf( "%d\n", sizeof data );
}
Gives the same result in C and C++, bit in the former the operand is
evaluated, in the latter it is not.
--
Ian Collins.
CBFalconer
Why did you snip away the expression that triggered the query?
I.e:
>>> int v = sizeof ++ch;
which has the same answer in C and C++ (I think), i.e. that sizeof
does not implement (or evaluate) the expression, it simply
considers its type. The answer it gives will usually be different
in C and C++, because they are different languages and define
things differently. Which is also the reason for not asking C++
questions in c.l.c.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Charlie Gordon
de news: 1189792886....@g4g2000hsf.googlegroups.com...
Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int) in C (how
stupid and counter-intuitive!)
someone knowing absolutely everything about C but nothing about C++ would
fit my definition of obtuse perfectly.
--
Chqrlie.
Charlie Gordon
1189804031.5...@k79g2000hse.googlegroups.com...
Wrong!
But you snipped the code and attribution.
sizeof('1') evaluates differently in C and C++. In C it is equivalent to
sizeof(int), while in C++ it evaluates like sizeof(char). On most
architectures, this will yield a different value.
--
Chqrlie.
Keith Thompson
I would argue that that's not a difference in the behavior of the
sizeof operator. The operator behaves exactly the same in both
languages, yielding the size in bytes of its operand. The meaning of
the operand just happens to be different.
But it does illustrate the point that there are subtle differences
between the two languages. Asking about C++ code here in comp.lang.c
can sometimes lead to confusion; it will inevitably lead to arguments
like this one.
Charlie Gordon
lnejh02...@nuthaus.mib.org...
> "Charlie Gordon" <ne...@chqrlie.org> writes:
>> "Martin Wells" <war...@eircom.net> a écrit dans le message de news:
>> 1189804031.5...@k79g2000hse.googlegroups.com...
>>>> There are subtle differences between
>>>> the sizeof operator in C and C++, and someone knowing absolutely
>>>> everything about C but nothing about C++ would most likely not know
>>>> the right answer to the problem I wrote.
>>>
>>> There's no subtle differences between C and C++ in this respect. Or
>>> even differences for that matter.
>>
>> Wrong!
>> But you snipped the code and attribution.
>>
>> sizeof('1') evaluates differently in C and C++. In C it is equivalent to
>> sizeof(int), while in C++ it evaluates like sizeof(char). On most
>> architectures, this will yield a different value.
>
> I would argue that that's not a difference in the behavior of the
> sizeof operator. The operator behaves exactly the same in both
> languages, yielding the size in bytes of its operand. The meaning of
> the operand just happens to be different.
How can you demonstrate the true nature of 'h' without resorting to the
sizeof operator ?
The very reason it is an int is quite obscure, multibyte character constants
are not defined in any standard way, it would be foolish to use them.
> But it does illustrate the point that there are subtle differences
> between the two languages. Asking about C++ code here in comp.lang.c
> can sometimes lead to confusion; it will inevitably lead to arguments
> like this one.
I know. But isn't it more helpful to explain these subtle differences than
to brutally bash OPs for trespassing without cause ?
--
Chqrlie
Keith Thompson
That's beside the point, which is that (as far as I know) sizeof
behaves identically in C and C++.
>> But it does illustrate the point that there are subtle differences
>> between the two languages. Asking about C++ code here in comp.lang.c
>> can sometimes lead to confusion; it will inevitably lead to arguments
>> like this one.
>
> I know. But isn't it more helpful to explain these subtle differences than
> to brutally bash OPs for trespassing without cause ?
Not all of us *know* the subtle differences.
And I for one did not brutally bash the OP for posting C++ code.
I brutally bashed the OP for posting an apparent homework question.
Chris Torek
In article <ln4phw1...@nuthaus.mib.org>
Keith Thompson <ks...@mib.org> wrote:
>That's beside the point, which is that (as far as I know) sizeof
>behaves identically in C and C++.
Well, one can argue this; but one can also argue otherwise, because
sizeof applied to a Variable Length Array in C99 is different. The
potential flaw in this second argument is that C++ does not have
VLAs (yet).
Even if the sizeof operator is considered "the same" (e.g., if one
is using C89 or C95), there are still subtle traps:
#include <stdio.h>
struct A { char block[8]; };
int main(void) {
struct B {
struct A {
char block[512];
} a;
};
printf("sizeof(struct A) = %lu\n",
(unsigned long) sizeof(struct A));
return 0;
}
Compile this program with a C compiler and with a C++ compiler,
and run the two executables:
% ln prog.c prog.c++
% cc -o cprog prog.c -O4 -W -Wall -ansi -pedantic
% g++ -o c++prog -O4 prog.c++ -W -Wall
% ./cprog
sizeof(struct A) = 512
% ./c++prog
sizeof(struct A) = 8
%
Exercise: explain the results. :-)
>Not all of us *know* the subtle differences.
Indeed, there are many I do not know, since the C++ language I
learned in the 1980s is not the C++ language we have today. I got
bitten by a version of the above difference once, though. It makes
an interesting example, I think.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Jack Klein
<ne...@chqrlie.org> wrote in comp.lang.c:
> "Lew Pitcher" <lpit...@teksavvy.com> a écrit dans le message de news:
> 1189783522.9...@w3g2000hsg.googlegroups.com...
> > On Sep 14, 11:16 am, goacr...@gmail.com wrote:
> >> char ch='a';
> >>
> >> int v=sizeof ++ch;
> >>
> >> cout<<ch<<endl;// output: 'a'
> >>
> >> why not 'b'
> >
> > Who knows the vagarities of C++? Why not ask in comp.lang.c++ instead
> > of here? We don't deal with C++ here, only C
>
> Why be unnecessarily obtuse when the issue is not C++ specific.
Yes it is. Nowhere in the C standard does it define what "sizeof" is,
means, or does in C++. Now it may just happen that C++ defines sizeof
this way, but whether it does or not is 100% completely off-topic
here.
> sizeof expr computes the size in bytes of the object denoted by expr without
> producing code for evaluating that expression. Therefore ch is not
> incremented.
Kindly quote chapter and verse from _any_ version of the C standard
that defines this, or any other behavior, for sizeof in C++.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
goac...@gmail.com
Thanks for your detailed illustration.
However, unfortunately , this is NOT any homework.
Just some personal interest.
Suggest you be more tolerant to freshmen, even if you're expert. I'm
sorry to say you seemed to like a bear with a sore head from the above
words.
Of course, I'm sorry about the cout issue.
Martin Wells
> int main(void) {
> const int N = 42;
>
> int data[N];
>
> printf( "%d\n", sizeof data );
>
> }
>
> Gives the same result in C and C++, bit in the former the operand is
> evaluated, in the latter it is not.
That's wrong -- the operand is evaluated in *neither* language.
In C++, this will print something like 168 (i.e. sizeof(int) * 42)
because N is a compile-time constant. In C89, the code won't compile.
In C99... well... I can't really say I care.
Martin
Ian Collins
--
Ian Collins.
Charlie Gordon
u0kme3dmjaegq7s91...@4ax.com...
> On Fri, 14 Sep 2007 19:19:27 +0200, "Charlie Gordon"
> <ne...@chqrlie.org> wrote in comp.lang.c:
>
>> "Lew Pitcher" <lpit...@teksavvy.com> a écrit dans le message de news:
>> 1189783522.9...@w3g2000hsg.googlegroups.com...
>> > On Sep 14, 11:16 am, goacr...@gmail.com wrote:
>> >> char ch='a';
>> >>
>> >> int v=sizeof ++ch;
>> >>
>> >> cout<<ch<<endl;// output: 'a'
>> >>
>> >> why not 'b'
>> >
>> > Who knows the vagarities of C++? Why not ask in comp.lang.c++ instead
>> > of here? We don't deal with C++ here, only C
>>
>> Why be unnecessarily obtuse when the issue is not C++ specific.
>
> Yes it is. Nowhere in the C standard does it define what "sizeof" is,
> means, or does in C++. Now it may just happen that C++ defines sizeof
> this way, but whether it does or not is 100% completely off-topic
> here.
>
>> sizeof expr computes the size in bytes of the object denoted by expr
>> without
>> producing code for evaluating that expression. Therefore ch is not
>> incremented.
>
> Kindly quote chapter and verse from _any_ version of the C standard
> that defines this, or any other behavior, for sizeof in C++.
Well we can't say what it does for C++ from the C standard, big deal!
At least we can explain what it does in C for the two lines
char ch = 'a';
int v = sizeof ++ch;
The expression ++ch is _not_ evaluated, only its type is determined by the
compiler to be char, which by definition has a size of 1. ch is unchanged.
Here are the appropriate quotations for the C language.
6.5.3.4 The sizeof operator
p2 semantics
The sizeof operator yields the size (in bytes) of its operand, which may be
an
expression or the parenthesized name of a type. The size is determined from
the type of
the operand. The result is an integer. If the type of the operand is a
variable length array
type, the operand is evaluated; otherwise, the operand is not evaluated and
the result is an
integer constant.
Annex J (informative)
J.1 Unspecified behavior
The following are unspecified:
Whether or not a size expression is evaluated when it is part of the operand
of a
sizeof operator and changing the value of the size expression would not
affect the
result of the operator (6.7.5.2).
For C++, ask the appropriate group, I suspect the interpretation will be the
same, but I am not an expert at C++.
--
Chqrlie.
CBFalconer
However the following minor correction functions under C90:
#include <stdio.h>
int main(void) {
# define N 42
int data[N];
printf("%lu\n", (unsigned long)sizeof data);
return 0;
CBFalconer
>
... snip ...
>
> How can you demonstrate the true nature of 'h' without resorting
> to the sizeof operator ? The very reason it is an int is quite
> obscure, multibyte character constants are not defined in any
> standard way, it would be foolish to use them.
What's obscure? chars are represented by an integer value. The
obvious place to hold an integer value is an int, provided it has
the capacity. Any other choice would cause program slowdowns in
one way or another. I never heard of any computer that held things
other than integers, although those integers (or collections of
integers) can be interpreted in various esoteric ways.
CBFalconer
>
... snip ...
>
> Even if the sizeof operator is considered "the same" (e.g., if one
> is using C89 or C95), there are still subtle traps:
>
> #include <stdio.h>
>
> struct A { char block[8]; };
>
> int main(void) {
> struct B {
> struct A {
> char block[512];
> } a;
> };
>
> printf("sizeof(struct A) = %lu\n",
> (unsigned long) sizeof(struct A));
> return 0;
> }
>
> Compile this program with a C compiler and with a C++ compiler,
> and run the two executables:
>
> % ln prog.c prog.c++
> % cc -o cprog prog.c -O4 -W -Wall -ansi -pedantic
> % g++ -o c++prog -O4 prog.c++ -W -Wall
> % ./cprog
> sizeof(struct A) = 512
> % ./c++prog
> sizeof(struct A) = 8
> %
>
> Exercise: explain the results. :-)
Obviously the local scope struct A is in effect for the printf
call, but as far as I am concerned this is wrong. That scope
should only appear when a struct B is open. I.e. the 512 result
should only appear for "sizeof struct B.a". In fact, since there
is no way to create an object of that type, it should not be
'sizable' at all.
Charlie Gordon
46EBFA5F...@yahoo.com...
> Charlie Gordon wrote:
>>
> ... snip ...
>>
>> How can you demonstrate the true nature of 'h' without resorting
>> to the sizeof operator ? The very reason it is an int is quite
>> obscure, multibyte character constants are not defined in any
>> standard way, it would be foolish to use them.
>
> What's obscure? chars are represented by an integer value. The
> obvious place to hold an integer value is an int, provided it has
> the capacity. Any other choice would cause program slowdowns in
> one way or another. I never heard of any computer that held things
> other than integers, although those integers (or collections of
> integers) can be interpreted in various esoteric ways.
I'm sorry but the very fact 'a' be an int constant literal as opposed to a
char constant literal is counter intuitive to most C programmers and the
reasons for that are indeed obscure. After all, the grammar in C99 6.4.4.4
calls it a character-constant.
C++ chose to change that in order for overloaded functions to be called in a
more understandable way.
Since you are so adamant about everything being held as an integer (which is
only vaguely related to the issue), why is L'a' not an int as well ?
On my system:
sizeof("a"[0]) = 1
sizeof('a') = 4
sizeof(L'a') = 2
sizeof(L"a"[0]) = 2
--
Chqrlie.
Charlie Gordon
46EBFA5F...@yahoo.com...
> Charlie Gordon wrote:
>>
> ... snip ...
>>
>> How can you demonstrate the true nature of 'h' without resorting
>> to the sizeof operator ? The very reason it is an int is quite
>> obscure, multibyte character constants are not defined in any
>> standard way, it would be foolish to use them.
>
> What's obscure? chars are represented by an integer value. The
> obvious place to hold an integer value is an int, provided it has
> the capacity. Any other choice would cause program slowdowns in
> one way or another. I never heard of any computer that held things
> other than integers, although those integers (or collections of
> integers) can be interpreted in various esoteric ways.
I'm sorry but the very fact 'a' be an int constant literal as opposed to a
Keith Thompson
Since I do care ...
In C99, N is not a constant expression (though it's very likely to be
evaluted at compile time anyway), and 'data' is a VLA, therefore the
argument to sizeof *is* evaluated.
But 'data' is just an object, and the result of evaluating it is
discarded, since sizeof still depends only on the type of its
argument. So what difference does it make whether the argument is
evaluated or not?
The only case I can think of is where the VLA is volatile.
Can anyone think of a case where the evaluation of the argument of
sizeof (when it's a VLA) has a visible effect on the behavior of the
program?
Keith Thompson
>> Several people have already given you the answer to your question --
>> which is unfortunate, since the question looks very much like
>> homework. An expression like 'sizeof ++ch' isn't something that you'd
>> write if your goal is to accomplish something. It was almost
>> certainly written by someone trying to make a specific point.
>>
>> If you want us to do your homework for you, please post your
>> instructor's e-mail address so we can submit our solutions directly.
>> We're willing to provide hints if you've done some of the work
>> yourself and you're stuck on something, but we won't (usually) do it
>> for you.
>
>
> However, unfortunately , this is NOT any homework.
> Just some personal interest.
Ok. But we do get a lot of people posting obvious homework questions
here, showing no sign of any effort to try to do the work themselves.
People even copy-and-paste their actual homework questions, without
indicating that they're homework.
And, as I said, your question *looks like* homework. I'm glad to
learn that it isn't.
Incidentally, when you post a followup, please delete any quoted
material that isn't relevant to your followup, particularly thee
signature (the stuff at the end following the "-- " delimiter).
Thanks.
Ian Collins
> Martin Wells wrote:
>> Ian:
>>
>>> int main(void) {
>>> const int N = 42;
>>>
>>> int data[N];
>>>
>>> printf( "%d\n", sizeof data );
>>>
>>> }
>>>
>>> Gives the same result in C and C++, bit in the former the operand is
>>> evaluated, in the latter it is not.
>> That's wrong -- the operand is evaluated in *neither* language.
>>
>> In C++, this will print something like 168 (i.e. sizeof(int) * 42)
>> because N is a compile-time constant. In C89, the code won't compile.
>> In C99... well... I can't really say I care.
>
> However the following minor correction functions under C90:
>
> #include <stdio.h>
>
> int main(void) {
> # define N 42
> int data[N];
>
> printf("%lu\n", (unsigned long)sizeof data);
> return 0;
> }
>
>
--
Ian Collins.
Ian Collins
> Chris Torek wrote:
> .... snip ...
>> Even if the sizeof operator is considered "the same" (e.g., if one
>> is using C89 or C95), there are still subtle traps:
>>
>> #include <stdio.h>
>>
>> struct A { char block[8]; };
>>
>> int main(void) {
>> struct B {
>> struct A {
>> char block[512];
>> } a;
>> };
>>
>> printf("sizeof(struct A) = %lu\n",
>> (unsigned long) sizeof(struct A));
>> return 0;
>> }
>>
>>
>
> Obviously the local scope struct A is in effect for the printf
> call, but as far as I am concerned this is wrong. That scope
> should only appear when a struct B is open. I.e. the 512 result
> should only appear for "sizeof struct B.a". In fact, since there
> is no way to create an object of that type, it should not be
> 'sizable' at all.
>
one would write sizeof(struct B::A), or simply sizeof(B::A).
--
Ian Collins.
raf...@dcc.ufmg.br
When would someone want to do something like that? I mean, why wouldn't you know
if SomeType has a val member or not? You can determine it before compilation.
Harald van Dijk
> Martin Wells <war...@eircom.net> writes:
>>> int main(void) {
>>> const int N = 42;
>>>
>>> int data[N];
>>>
>>> printf( "%d\n", sizeof data );
>>>
>>> }
>>>
>>> Gives the same result in C and C++, bit in the former the operand is
>>> evaluated, in the latter it is not.
>>
>> That's wrong -- the operand is evaluated in *neither* language.
>>
>> In C++, this will print something like 168 (i.e. sizeof(int) * 42)
>> because N is a compile-time constant. In C89, the code won't compile.
>> In C99... well... I can't really say I care.
>
> Since I do care ...
>
> In C99, N is not a constant expression (though it's very likely to be
> evaluted at compile time anyway), and 'data' is a VLA, therefore the
> argument to sizeof *is* evaluated.
>
> But 'data' is just an object, and the result of evaluating it is
> discarded, since sizeof still depends only on the type of its argument.
> So what difference does it make whether the argument is evaluated or
> not?
>
> The only case I can think of is where the VLA is volatile.
>
> Can anyone think of a case where the evaluation of the argument of
> sizeof (when it's a VLA) has a visible effect on the behavior of the
> program?
#include <stdio.h>
int f(void) {
puts("f is called!");
return 0;
}
int main(void) {
enum { constant_size = 1 };
const int nonconstant_size = 1;
char nonvla[constant_size];
char vla[nonconstant_size];
printf("sizeof (&nonvla)[f()] = %zu\n", sizeof (&nonvla)[f()]);
printf("sizeof (&vla)[f()] = %zu\n", sizeof (&vla)[f()]);
return 0;
}
This should print:
sizeof (&nonvla)[f()] = 1
f is called!
sizeof (&vla)[f()] = 1
Ian Collins
Should it?
--
Ian Collins.
Flash Gordon
<snip>
> Can anyone think of a case where the evaluation of the argument of
> sizeof (when it's a VLA) has a visible effect on the behavior of the
> program?
size_t size=5
int array[++size];
--
Flash Gordon
Harald van Dijk
This is the behaviour mandated by the standard and implemented by the
compiler I'm using. If you believe the standard would have been better if
sizeof on VLAs were specified differently, then I don't necessarily
disagree, but if you believe the standard requires (or allows) any
different output, then could you please explain why?
Harald van Dijk
No, sizeof(array) will always return 6 in this case. The array size is
evaluated when the declaration is reached, but not re-evaluated
afterwards.
Keith Thompson
> On Sat, 15 Sep 2007 12:52:39 -0700, Keith Thompson wrote:
Nope.
Here's what the standard says (C99 6.5.3.4p2):
If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated and
the result is an integer constant.
The type of the operand in both of your sizeof expressions is char,
not a VLA type. f() is never called. (I tried it, and the behavior
under the implementation I used is consistent with this.)
Harald van Dijk
> "Harald van D )&k" <tru...@gmail.com> writes:
>> On Sat, 15 Sep 2007 12:52:39 -0700, Keith Thompson wrote:
> [...]
>>> sizeof (when it's a VLA) has a visible effect on the behavior of the
>>> program?
>>
>> #include <stdio.h>
>> int f(void) {
>> puts("f is called!");
>> return 0;
>> }
>> int main(void) {
>> enum { constant_size = 1 };
>> const int nonconstant_size = 1;
>>
>> char nonvla[constant_size];
>> char vla[nonconstant_size];
>>
>> printf("sizeof (&nonvla)[f()] = %zu\n", sizeof (&nonvla)[f()]);
>> printf("sizeof (&vla)[f()] = %zu\n", sizeof (&vla)[f()]);
>>
>> return 0;
>> }
>>
> a VLA type.
I think you've overlooked the &. The operands to both sizeof operators
have array types.
christian.bau
> christian.bau wrote:
> > On Sep 14, 6:19 pm, "Charlie Gordon" <n...@chqrlie.org> wrote:
>
> >> Why be unnecessarily obtuse when the issue is not C++ specific.
>
>
> > char c - '0';
> > c += sizeof ('0');
>
> > what is the value stored in c? There are subtle differences between
> > the sizeof operator in C and C++, and someone knowing absolutely
> > everything about C but nothing about C++ would most likely not know
> > the right answer to the problem I wrote.
>
> do not evaluate the expression of a sizeof.
How do you know that C++ doesn't evaluate the expression? Show me
exactly the page and line in the C Standard that tells us that C++
doesn't evaluate the argument of the sizeof operator.
Oh, you can't do that. There is no such statement in the C Standard.
There may be one in the C++ Standard, and I am sure the guys who read
comp.lang.c++ know everything about it, but this is comp.lang.c.
Ian Collins
My thinking was the same as Keith's.
I just tried it with a couple of compilers and got
sizeof (&nonvla)[f()] = 1
sizeof (&vla)[f()] = 1
from both.
--
Ian Collins.
Harald van Dijk
That the operand to sizeof is a char? If you change the array length from
1 to 2 you will see the printed size change; if it had type char, it
would remain 1.
> I just tried it with a couple of compilers and got
>
> sizeof (&nonvla)[f()] = 1
> sizeof (&vla)[f()] = 1
>
> from both.
Which compilers are those? GCC 4.1 doesn't call f. GCC 4.2 and Intel CC
10.0 do.
raf...@dcc.ufmg.br
We learn by repetition.
We learn by repetition.
We learn by repetition.
"Why be unnecessarily obtuse when the issue is not C++ specific."
"Why be unnecessarily obtuse when the issue is not C++ specific."
"Why be unnecessarily obtuse when the issue is not C++ specific."
See, the guy probably only used "cout" because he found it easier or he didn't
even relise there really is a difference between C and C++. The bad thing here
is not telling the guy that, but it's being overly obnoxious about the whole
thing. Would it be too hard to say something like the following?
"Hey, that cout thing is actually C++. We deal with C here. I can see from your
code that you're struggling with sizeof's argument not being evaluated. I can
tell you that in the C programming language..."
If you don't understand the guy's struggle, simple don't answer the thread. It's
really simple. No need for bashing him, making his life difficult over so
little. Other people realised that and answered him properly and he seemed
to make him satisfied. That's orienting, that's being helpful. Giving him crap
because he had a line that's not standard C is being obtuse.
Flash Gordon
I meant to say
sizeof array[++size];
Obviously I my brain was disconnected at the time.
--
Flash Gordon
Checking down the back of the sofa to see if my brain is there.
Ian Collins
>
>> I just tried it with a couple of compilers and got
>>
>> sizeof (&nonvla)[f()] = 1
>> sizeof (&vla)[f()] = 1
>>
>> from both.
>
> Which compilers are those? GCC 4.1 doesn't call f. GCC 4.2 and Intel CC
> 10.0 do.
gcc 4.0.2 and Sun cc.
--
Ian Collins.
Harald van Dijk
> Harald van Dijk wrote, On 15/09/07 22:13:
>> On Sat, 15 Sep 2007 21:05:53 +0100, Flash Gordon wrote:
>>> Keith Thompson wrote, On 15/09/07 20:52:
>>>
>>> <snip>
>>>
>>>> Can anyone think of a case where the evaluation of the argument of
>>>> sizeof (when it's a VLA) has a visible effect on the behavior of the
>>>> program?
>>> size_t size=5
>>> int array[++size];
>>
>> No, sizeof(array) will always return 6 in this case. The array size is
>> evaluated when the declaration is reached, but not re-evaluated
>> afterwards.
>
> I meant to say
> sizeof array[++size];
> Obviously I my brain was disconnected at the time.
array[++size] is an expression of type int, so ++size will not be
evaluated.
Peter Nilsson
6.5.3.4p2: "... If the type of the operand is a variable
length array type, the operand is evaluated; otherwise,
the operand is not evaluated and the result is an
integer constant."
Since you don't apply sizeof to an operand of variable
length array type, I don't see how or why f should be
called.
I believe the evaluation clause in 6.5.3.4p2 is more for
cases like...
sizeof (int [nonconstexpr])
Since pointer arithmetic is required to work on VLAs,
such pointers (including those created by using the name
of a VLA) necessarily carry information about the VLAs
size, either directly or indirectly.
Consider...
#include <stdio.h>
#include <stdlib.h>
int foo()
{
return 1 + rand() % 10;
}
size_t bah(char (*vlap)[*])
{
return sizeof *vlap;
}
int main()
{
int vla[foo()];
printf("%zu\n", bah(&vla));
return 0;
}
The function foo() is only called once. A compiler that
calls foo() twice would be broken.
--
Peter
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>Can anyone think of a case where the evaluation of the argument of
>sizeof (when it's a VLA) has a visible effect on the behavior of the
>program?
Gcc with flags "-std=c99 -pedantic -Wall' thinks the following program
is legal:
#include <stdio.h>
int main(void)
{
int n = 42;
printf("%d\n", (int)sizeof(char [n++]));
printf("%d\n", (int)sizeof(char [n++]));
return 0;
}
and it prints:
42
43
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Keith Thompson
You're right (and gcc gets this wrong).
Flash Gordon
I've definitely been working too many hours this week. Normal service
will be restored once I've taken my brain out and washed all the rubbish
out of it.
--
Flash Gordon
Charlie Gordon
fchthe$23po$1...@pc-news.cogsci.ed.ac.uk...
> In article <lnd4wjz...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>
>>Can anyone think of a case where the evaluation of the argument of
>>sizeof (when it's a VLA) has a visible effect on the behavior of the
>>program?
>
> Gcc with flags "-std=c99 -pedantic -Wall' thinks the following program
> is legal:
>
> #include <stdio.h>
>
> int main(void)
> {
> int n = 42;
> printf("%d\n", (int)sizeof(char [n++]));
> printf("%d\n", (int)sizeof(char [n++]));
> return 0;
> }
>
> and it prints:
>
> 42
> 43
While it seems logic to do so, the language of the standard is not clear:
6.5.3.4p2: "... If the type of the operand is a variable
length array type, the operand is evaluated; otherwise,
the operand is not evaluated and the result is an
integer constant."
What if the type of char[n++] ?
How can we evaluate char[n++] ?
char [n++] *is* a type, it does not *have* a type.
I don't think the language of the standard correctly specifies what should
be the behaviour of such code.
A more compelling example would be
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
if (argc > 1) {
int n = strtol(argv[1], NULL, 0);
int matrix[n][n];
int i = 1;
printf("i=%d, n=%d\n", i, n);
printf ("sizeof(matrix) = %zd\n", sizeof(matrix));
printf ("sizeof(matrix[i++]) = %zd\n", sizeof(matrix[i++]));
printf("i=%d\n", i);
printf ("sizeof(char[i++]) = %zd\n", sizeof(char[i++]));
printf("i=%d\n", i);
}
return 0;
}
with gcc upto version 4.1.3, I get what I interpret as non conforming
behaviour:
$ ./vla 2
i=1, n=2
sizeof(matrix) = 16
sizeof(matrix[i++]) = 8
i=1
sizeof(char[i++]) = 1
i=2
I think we have a defect here: the argument to sizeof should be evaluated is
it *is* a variable length array type, not if it is an expression whois type
can be determined from static analysis.
--
Chqrlie.
Richard Bos
> "christian.bau" wrote:
> > "Charlie Gordon" <n...@chqrlie.org> wrote:
> >
> >> Why be unnecessarily obtuse when the issue is not C++ specific.
> >
> > How do you know it is not C++ specific? For example, after
> >
> > char c - '0';
> > c += sizeof ('0');
> >
> > what is the value stored in c? There are subtle differences
> > between the sizeof operator in C and C++, and someone knowing
> > absolutely everything about C but nothing about C++ would most
> > likely not know the right answer to the problem I wrote.
>
> Why did you snip away the expression that triggered the query?
Because it's immaterial to his point, which is that _all_ such
expressions _may_ be different in C++, and only comp.lang.c++ can tell
you for certain.
> I.e:
>
> >>> int v = sizeof ++ch;
>
> which has the same answer in C and C++ (I think),
Precisely. _You think_. comp.lang.c++ would _know_.
Richard
Keith Thompson
> CBFalconer <cbfal...@yahoo.com> wrote:
[...]
>> I.e:
>>
>> >>> int v = sizeof ++ch;
>>
>> which has the same answer in C and C++ (I think),
>
> Precisely. _You think_. comp.lang.c++ would _know_.
You're assuming that the folks in comp.lang.c++ know enough about C to
be sure about such things. (That may be an accurate assumption.)
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
>
... snip ...
>>
>> >>> int v = sizeof ++ch;
>>
>> which has the same answer in C and C++ (I think),
>
> Precisely. _You think_. comp.lang.c++ would _know_.
No, they wouldn't. In general their knowledge of C is probably
similar to my knowledge of C++ - i.e. fair, but not comprehensive.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Flash Gordon
> Richard Bos wrote:
>> CBFalconer <cbfal...@yahoo.com> wrote:
>>
> ... snip ...
>>>>>> int v = sizeof ++ch;
>>> which has the same answer in C and C++ (I think),
>> Precisely. _You think_. comp.lang.c++ would _know_.
>
> No, they wouldn't. In general their knowledge of C is probably
> similar to my knowledge of C++ - i.e. fair, but not comprehensive.
I think the point is they would _know_ the behaviour in C++. After all,
the original code _was_ C++ because it used C++ specific features on
another line.
--
Flash Gordon
Kelsey Bjarnason
On Sat, 15 Sep 2007 00:31:53 +0200, Charlie Gordon wrote:
> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int) in C (how
> stupid and counter-intuitive!)
There were legitimate reasons for this, however.
> someone knowing absolutely everything about C but nothing about C++ would
> fit my definition of obtuse perfectly.
Actually, that'd fit my definition of "C programmer who hasn't learned C++."
CBFalconer
> On Sat, 15 Sep 2007 00:31:53 +0200, Charlie Gordon wrote:
>
>
>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int)
>> in C (how stupid and counter-intuitive!)
>
> There were legitimate reasons for this, however.
>
>> someone knowing absolutely everything about C but nothing about
>> C++ would fit my definition of obtuse perfectly.
>
> Actually, that'd fit my definition of "C programmer who hasn't
> learned C++."
LOL. Accurate.
CBFalconer
Which (I think) is just what I said. An answer requires knowledge
of both systems.
Kelsey Bjarnason
> Kelsey Bjarnason wrote:
>> On Sat, 15 Sep 2007 00:31:53 +0200, Charlie Gordon wrote:
>>
>> [snips]
>>
>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int)
>>> in C (how stupid and counter-intuitive!)
>>
>> There were legitimate reasons for this, however.
>>
>>> someone knowing absolutely everything about C but nothing about
>>> C++ would fit my definition of obtuse perfectly.
>>
>> Actually, that'd fit my definition of "C programmer who hasn't
>> learned C++."
>
> LOL. Accurate.
He do seem to think that learning C magically imparts a deep knowledge of
C++, don't he?
Weird stuff.
Richard Bos
> Flash Gordon wrote:
> > CBFalconer wrote, On 17/09/07 08:29:
> >> Richard Bos wrote:
> >>> CBFalconer <cbfal...@yahoo.com> wrote:
> >>>
> >> ... snip ...
> >>
> >>>>>>> int v = sizeof ++ch;
> >>>>
> >>>> which has the same answer in C and C++ (I think),
> >>>
> >>> Precisely. _You think_. comp.lang.c++ would _know_.
> >>
> >> No, they wouldn't. In general their knowledge of C is probably
> >> similar to my knowledge of C++ - i.e. fair, but not comprehensive.
> >
> > I think the point is they would _know_ the behaviour in C++. After
> > all, the original code _was_ C++ because it used C++ specific
> > features on another line.
>
> Which (I think) is just what I said. An answer requires knowledge
> of both systems.
No, it requires knowledge of C++. It was a question about the behaviour
of the posted code, which was C++ code; it was not a question about the
potential difference in behaviour between that code and similar C code.
Richard
Flash Gordon
Yes, I meant what Richard has just posted.
--
Flash Gordon
Charlie Gordon
akf3s4-...@spanky.localhost.net...
Not at all !
Knowing absolutely everything about C (I wonder who on earth would dare
pretend that), and having never even peeked at C++ shows a weird but
absolute will of self-confinement. That may not be the exact current
meaning of obtuse, but it shows both close- and strong-mindedness, which
together hint at blunt lack of intelligence.
Come on, most of us know enough C++ to have made up our minds about staying
with C for a number of applications where the latter is inappropriate. We
may disagree on what these applications are, if not all. But making this
choice out of sheer prejudice is being obtuse.
--
Chqrlie.
Charlie Gordon
> [snips]
>
> On Sat, 15 Sep 2007 00:31:53 +0200, Charlie Gordon wrote:
>
>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int) in C
>> (how
>> stupid and counter-intuitive!)
>
> There were legitimate reasons for this, however.
I could not find which.
The standard partly retreated on this issue, making sizeof(L'a') ==
sizeof(wchar_t)
Can you elaborate ?
>> someone knowing absolutely everything about C but nothing about C++ would
>> fit my definition of obtuse perfectly.
>
> Actually, that'd fit my definition of "C programmer who hasn't learned
> C++."
Not really: C programmer is much more restrictive than "someone knowing
absolutely everything about C". For such a person to not know anything
about C++ requires a strong will of not knowing.
--
Chqrlie.
Richard Heathfield
<snip>
> Knowing absolutely everything about C (I wonder who on earth would dare
> pretend that), and having never even peeked at C++ shows a weird but
> absolute will of self-confinement. That may not be the exact current
> meaning of obtuse, but it shows both close- and strong-mindedness, which
> together hint at blunt lack of intelligence.
I'd just like to add my two cents here, if I may.
On those rare occasions when I feel obliged to say something about C++ in
this group, I almost invariably qualify it with protestations of ignorance
of the finer details of that language.
This is *not* because I haven't ever studied C++. I have. And I have
written a great many programs in C++ over the years, and I'm perfectly
sure that I know more about C++ than almost anyone I've ever met in person
(the most notable exception I can think of is Sarah Thompson, last heard
of working at NASA, but there are a few others about the place, too).
In fact, I think it would be fair to say that I have about as deep and
thorough a knowledge of C++ as I had of C when I started using this
newsgroup regularly about eight or nine years ago.
Those who were here eight or nine years ago will no doubt recall just how
flawed that knowledge was. I have no reason to believe that my current C++
knowledge is any less flawed now than my C knowledge was then, which is
why I always hedge my statements about C++ with riders and qualifiers.
That does not mean I am wholly ignorant of C++, of course. It just means
that I don't want people taking my word for it on a C++ matter when it may
turn out that they know more about it than I do.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Charlie Gordon
_tCdnTr4xvUxL3Lb...@bt.com...
Thank you for this clarification, I feel exactly the same.
--
Chqrlie.
Kelsey Bjarnason
On Tue, 18 Sep 2007 10:08:54 +0200, Charlie Gordon wrote:
> Knowing absolutely everything about C (I wonder who on earth would dare
> pretend that), and having never even peeked at C++ shows a weird but
> absolute will of self-confinement.
Oh? How about Pascal? Visual Basic? Haskell? Malbolge? Presumably if
one confines oneself to C without looking at these, one is similarly
self-confined, right?
After all, each is a language, separate and distinct from C - like C++ is.
So the argument must hold as well for them as for C++, unless you're now
going to tell us that C and C++ are really the same language, or some such
rot.
> That may not be the exact current
> meaning of obtuse, but it shows both close- and strong-mindedness, which
> together hint at blunt lack of intelligence.
Actually, it shows nothing more than focusing on the tools you know, and
possibly the ones you're required to use. Spend too much time dicking
around trying to learn every language or tool you encounter, you won't get
anything done.
You'll also tend to trip over your own tongue, so to speak, as you end up
trying to remember whether a given construct works this way or that way
and in which languages and under what circumstances.
> Come on, most of us know enough C++ to have made up our minds about staying
> with C for a number of applications where the latter is inappropriate.
Let's restore some context:
<quote>
char c - '0';
c += sizeof ('0');
what is the value stored in c? There are subtle differences between the
sizeof operator in C and C++, and someone knowing absolutely everything
about C but nothing about C++ would most likely not know the right
answer to the problem I wrote.
</quote>
This is not about "knowing enough C++ to have made up our minds", it is
knowing enough C++ to know the subtle differences between how it operates
and how C operates, which even an expert C programmer is not going to
know.
How does one find out those subtleties? Not by discussing the subject in
a C newsgroup. How does one get help on code which may - or may not, we
simply don't know, that's kinda the point - rely on such subtleties?
Probably by asking in the proper group.
Kelsey Bjarnason
On Tue, 18 Sep 2007 10:12:18 +0200, Charlie Gordon wrote:
>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int) in C
>>> (how
>>> stupid and counter-intuitive!)
>>
>> There were legitimate reasons for this, however.
>
> I could not find which.
> The standard
Which standard? You can't even figure out, apparently, what language is
being discussed.
Peter J. Holzer
Since the comment at the start of this subthread was from Charlie, he
doesn't have to figure out what language is being discussed, he knows
it. It is possible, though, that you didn't figure out which language
Charlie was talking about ...
hp
PS: I'd give long odds the language is C.
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Kelsey Bjarnason
> On 2007-09-18 17:01, Kelsey Bjarnason <kbjar...@gmail.com> wrote:
>> [snips]
>>
>> On Tue, 18 Sep 2007 10:12:18 +0200, Charlie Gordon wrote:
>>
>>>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int) in C
>>>>> (how
>>>>> stupid and counter-intuitive!)
>>>>
>>>> There were legitimate reasons for this, however.
>>>
>>> I could not find which.
>>> The standard
>>
>> Which standard? You can't even figure out, apparently, what language is
>> being discussed.
>
> Since the comment at the start of this subthread was from Charlie, he
> doesn't have to figure out what language is being discussed, he knows
> it. It is possible, though, that you didn't figure out which language
> Charlie was talking about ...
>
> hp
>
> PS: I'd give long odds the language is C.
Which one - there's at least three to go with. :)
Ben Bacarisse
> [snips]
>
> On Tue, 18 Sep 2007 10:08:54 +0200, Charlie Gordon wrote:
>
>> Knowing absolutely everything about C (I wonder who on earth would dare
>> pretend that), and having never even peeked at C++ shows a weird but
>> absolute will of self-confinement.
>
> Oh? How about Pascal? Visual Basic? Haskell? Malbolge? Presumably if
> one confines oneself to C without looking at these, one is similarly
> self-confined, right?
>
> After all, each is a language, separate and distinct from C - like
> C++ is.
Are distinct things in your world only ever either the same or
different? Do distinct things ever have similarities and connections
between them? Can these similarities and connections ever vary by
degree?
I know Haskell simply because I am interested in that family of
languages and it's history. The relationship between C and C++ is, I
am sure, well known to you and its seems plausible to me that an
interest in one might be correlated to an interest in the other.
I am trying to find out, in part, if you really see the world in black
and white or if you just like to have a Barney (== a fight).
--
Ben.
Charlie Gordon
All of "them" have the same definition of sizeof('a').
--
Chqrlie.
Charlie Gordon
You are so amazingly gifted at playing stupid ;-)
If you followed the conversation, It is obvious from context that you
snipped that the only Standard I even mentionned is C99. It you know shy
sizeof('a') is the same as sizeof(int) in the C language, please enlighten
us! The choice made by the C++ folks makes so much more sense.
Also please tell us why you think the C99 standard defines sizeof(L'a') as
equal to sizeof(wchar_t).
Otherwise, you are just trolling and your posts lead nowhere,
--
Chqrlie.
Peter J. Holzer
> "Kelsey Bjarnason" <kbjar...@gmail.com> a écrit dans le message de news:
> rrc5s4-...@spanky.localhost.net...
>>
>>>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int)
>>>>> in C (how stupid and counter-intuitive!)
>>>>
>>>> There were legitimate reasons for this, however.
> It you know shy sizeof('a') is the same as sizeof(int) in the C
> language, please enlighten us!
You would have to ask dmr for a definitive answer, but it is consistent
with the integer promotion rules: Whenever an expression has an integer
type smaller than int, it is promoted to int or unsigned int,
respectively. In the case of a constant this promotion would be done by
the compiler anyway, so there is little use for integer constants of
smaller size. Consequently, there are no constants of type char or
short. Only int and long (and long long in C99) and their unsigned
brethren.
(K&R C didn't have float constants either - all floating point constants
were double)
> The choice made by the C++ folks makes so much more sense.
C++ also has a good reason to make the distinction. In C it doesn't make
any difference except in programs deliberately written to show the
difference.
> Also please tell us why you think the C99 standard defines sizeof(L'a') as
> equal to sizeof(wchar_t).
Because the C89 standard did the same? It is a bit inconsistent - I
would have expected something like "a wide character constant has the
type which results from applying the integer promotion rules to type
wchar_t". But it really makes little difference, since even though the
constant may be shorter than int, the integer promotions are applied to
it, making it at least as wide as an int for every operation except
sizeof.
hp
Charlie Gordon
slrnff5hu4.7g...@zeno.hjp.at...>> "Kelsey Bjarnason" <kbjar...@gmail.com> a crit dans le message de news:
>> rrc5s4-...@spanky.localhost.net...
>>> On Tue, 18 Sep 2007 10:12:18 +0200, Charlie Gordon wrote:
>>>
>>>>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int)
>>>>>> in C (how stupid and counter-intuitive!)
>>>>>
>>>>> There were legitimate reasons for this, however.
> [...]
>> It you know shy sizeof('a') is the same as sizeof(int) in the C
>> language, please enlighten us!
>
> You would have to ask dmr for a definitive answer, but it is consistent
> with the integer promotion rules: Whenever an expression has an integer
> type smaller than int, it is promoted to int or unsigned int,
> respectively. In the case of a constant this promotion would be done by
> the compiler anyway, so there is little use for integer constants of
> smaller size. Consequently, there are no constants of type char or
> short. Only int and long (and long long in C99) and their unsigned
> brethren.
I don't buy your "promotional" argument. I think it must be related to
multi-character character constants that were allowed and used back in the
early C days, when people used to pack characters into ints. For instance
login names were originally restricted to 6 characters in order to fit in a
36 bit word. Handy 3 letter abbreviations such as 'dmr' and 'bwk' fit
nicely in 18 bit half words. Parsing such biests without the help or the
need of constant folding involved packing them in a single "character
constant", which of course had to be as large as an int. 6-bit bytes were a
sensible choice on the PDP-10, much less wasteful than 9-bit.
> (K&R C didn't have float constants either - all floating point constants
> were double)
>
>> The choice made by the C++ folks makes so much more sense.
>
> C++ also has a good reason to make the distinction. In C it doesn't make
> any difference except in programs deliberately written to show the
> difference.
>
>
>> Also please tell us why you think the C99 standard defines sizeof(L'a')
>> as
>> equal to sizeof(wchar_t).
>
> Because the C89 standard did the same? It is a bit inconsistent - I
> would have expected something like "a wide character constant has the
> type which results from applying the integer promotion rules to type
> wchar_t". But it really makes little difference, since even though the
> constant may be shorter than int, the integer promotions are applied to
> it, making it at least as wide as an int for every operation except
> sizeof.
C89 did that because it is the sensible choice, but they could not revert
the awkward historical glitch about char constants, and had to engrave those
as having type int.
--
Chqrlie.
Ben Bacarisse
> On 2007-09-20 22:21, Charlie Gordon <ne...@chqrlie.org> wrote:
>> "Peter J. Holzer" <hjp-u...@hjp.at> a écrit dans le message de news:
>> slrnff5hu4.7g...@zeno.hjp.at...
>>> On 2007-09-19 08:23, Charlie Gordon <ne...@chqrlie.org> wrote:
>>>> "Kelsey Bjarnason" <kbjar...@gmail.com> a crit dans le message de news:
>>>> rrc5s4-...@spanky.localhost.net...
>>>>> On Tue, 18 Sep 2007 10:12:18 +0200, Charlie Gordon wrote:
>>>>>
>>>>>>>> Yeah right sizeof('a') == 1 in C++ and sizeof('a') == sizeof(int)
>>>>>>>> in C (how stupid and counter-intuitive!)
>>>>>>>
>>>>>>> There were legitimate reasons for this, however.
>>> [...]
>>>> It you know shy sizeof('a') is the same as sizeof(int) in the C
>>>> language, please enlighten us!
>>>
>>> You would have to ask dmr for a definitive answer, but it is consistent
>>> with the integer promotion rules:
<snip>
>> I don't buy your "promotional" argument. I think it must be related to
>> multi-character character constants that were allowed and used back in the
>> early C days, when people used to pack characters into ints.
<snip>
> While I don't claim to know much about C compilers before the
> mid-1980's, I doubt this would ever have worked. AFAIK a char was always
> at least 8 bits on all C compilers, and while it is possible that a
> multi-character constant used a special 6-bit-encoding instead of just
> stuffing 8-bit-chars together, it seems a bit far-fetched.
>
> Also, my copy of K&R I doesn't mention multi-character constants at all.
> It's the German translation, though - can anybody check the
> original?
My old K&R (1978) makes no reference to multi-character constants.
Many compilers supported them (I have even used then <blush>) but they
were always regarded non-standard (even before *the* standard) and
non-portable.
--
Ben.
David Thompson
wrote:
<snip: sizeof and VLAs>
> I believe the evaluation clause in 6.5.3.4p2 is more for
> cases like...
>
> sizeof (int [nonconstexpr])
>
> Since pointer arithmetic is required to work on VLAs,
> such pointers (including those created by using the name
> of a VLA) necessarily carry information about the VLAs
> size, either directly or indirectly.
>
Not directly, because...
> Consider...
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int foo()
> {
> return 1 + rand() % 10;
> }
>
> size_t bah(char (*vlap)[*])
this isn't allowed: 6.7.5.2p4.
> {
> return sizeof *vlap;
> }
>
> int main()
> {
> int vla[foo()];
> printf("%zu\n", bah(&vla));
> return 0;
> }
>
> The function foo() is only called once. A compiler that
> calls foo() twice would be broken.
The definition must use a specific variable bound (!) like:
char* after (size_t n, int (*vlap)[n] )
{ return (char*) & vlap [1]; }
int main ()
{ int n, vla [n=foo()]; /* or int n = foo(), vla [n]; */
printf ("%d\n", (int) (after (n,&vla) - (char*)&vla) );
/* or HERE IN CALLER can use sizeof vla for bytes,
or sizeof vla / sizeof vla[0] for bound */
return 0; }
which indeed calls foo only once, but must pass the (resulting) bound
explicitly for the callee to know it.
- formerly david.thompson1 || achar(64) || worldnet.att.net