sizeof

P

pete

Ancient_Hacker wrote:
You see, sizeof can take any expression or type as an argement.

The operands of sizeof can only be
either parenthesized object types, or expressions of object type.
 
A

Ancient_Hacker

Richard said:
Ancient_Hacker said:
No, it's required to evaluate to 1 if v has pointer type or array type. So
you appear to be claiming Visual C is non-conforming.


Did I forget to write that you need to coerce the ptr to char*?:

Then you do get the array element size from the macro.

One might wonder if some folks belong to the intentionally-obtuse club.
One might estimate that 98% of "C" experts would realize in an instant
that (char *) is needed to get the right answer. Choosing to instead
be ingenuous and scatter veiled insults may make the writer feel
superior while not being at all helpful.

I concede that somewhere there may be a few C compilers for the
Abaci-37,the Turkmenistan base 3 computer, with DES encypted address
bus, that might not return correct results on that macro. Late news
arrives that an old compiler, for a dying architecture, and a bankrupt
company, has two obscure and (horrors-- non-standard!) options which
might, under certain circumstances, willy-nilly rearrange globals.

Also didnt think it worth mentioning, as it's obvious, that one needs
to take care re structure field packing, although this is easily turned
off in most compilers with a command-line switch,
and also easily tested for.
 
A

Ancient_Hacker

pete said:
The operands of sizeof can only be
either parenthesized object types, or expressions of object type.

I meant you can use considerable flexibility in what you put after
sizeof, witness:

#include<stdio.h>

main()
{ int a,b,c;
int count = 1;

count = sizeof( 6 );
count = sizeof( a + b );
count = sizeof( (double *) &a );
count = sizeof( sizeof(a) );
count = sizeof( &printf );
count = sizeof( printf("foo" ) );
count = sizeof( 1.234E-4 );
count = sizeof( 3.4 / 5.6 );
count = sizeof( (float
***************************************************) &a );
printf( "%d\n", count );
return 0;



}
 
F

Flash Gordon

Ancient_Hacker said:
Did I forget to write that you need to coerce the ptr to char*?:

Then you do get the array element size from the macro.

One might wonder if some folks belong to the intentionally-obtuse club.
One might estimate that 98% of "C" experts would realize in an instant
that (char *) is needed to get the right answer. Choosing to instead
be ingenuous and scatter veiled insults may make the writer feel
superior while not being at all helpful.

You claimed to know what you were doing, and our only evidence of what
you believed was the code you posted. That code was WRONG. I posted an
example using that code and stated what it produced. You then claimed
that another compiler produced a different result to mine, obviously
without testing doing any testing.
I concede that somewhere there may be a few C compilers for the
Abaci-37,the Turkmenistan base 3 computer, with DES encypted address
bus, that might not return correct results on that macro. Late news
arrives that an old compiler, for a dying architecture, and a bankrupt
company, has two obscure and (horrors-- non-standard!) options which
might, under certain circumstances, willy-nilly rearrange globals.

And on PPC based Linux systems using CURRENT versions of gcc. Also on
AIX 5.3 using the gcc version that IBM currently supply. From what I can
see AIX is still very much alive and kicking.
Also didnt think it worth mentioning, as it's obvious, that one needs
to take care re structure field packing, although this is easily turned
off in most compilers with a command-line switch,
and also easily tested for.

All entirely pointless when all C compilers conforming to a widely
implemented 17 year old standard have a sizeof operator that is
*designed* to do the job and is the only method guaranteed to do the
correct thing. Also, if a compiler is inserting padding by default then
there is probably a *very* good reason for it to do so. Such as a
significant performance hit if you don't.
 
R

Richard Heathfield

Ancient_Hacker said:
Did I forget to write that you need to coerce the ptr to char*?:

I have no idea what you intended to write. I was commenting on what you
actually wrote. By the way, unsigned char * would be a better choice.

Also didnt think it worth mentioning, as it's obvious, that one needs
to take care re structure field packing, although this is easily turned
off in most compilers with a command-line switch,
and also easily tested for.

If you're looking for "easy", I suggest using the sizeof operator.
 
D

Dik T. Winter

>
> You're not just assuming that the variables are adjacent; you're also
> assuming that the second declared variable has a higher address than
> the first.

And a third assumption is is that there is no padding between the variables.
And I have used compilers that did padding between variables when they
were "too small".
 
K

Keith Thompson

Ancient_Hacker said:
I meant you can use considerable flexibility in what you put after
sizeof, witness:

#include<stdio.h>

main()
{ int a,b,c;
int count = 1;

count = sizeof( 6 );
count = sizeof( a + b );
count = sizeof( (double *) &a );
count = sizeof( sizeof(a) );
count = sizeof( &printf );
count = sizeof( printf("foo" ) );
count = sizeof( 1.234E-4 );
count = sizeof( 3.4 / 5.6 );
count = sizeof( (float
***************************************************) &a );
printf( "%d\n", count );
return 0;



}

Ok, but once again that's not what you actually wrote. What you
actually wrote was:

You see, sizeof can take any expression or type as an argement.

which is not correct. pete's statement was correct. To be precise,
the relevant portion of the grammar is:

unary-expression:
...
sizeof unary-expression
sizeof ( type-name )

This, of course, covers all the cases in your sample program, but it
does not cover a number of cases implied by your original statement,
such as:
sizeof(void)
sizeof main
sizeof obj.bitfield
sizeof exit(0)
/* All of thses are constraint violations. */

Now I'm sure you know all of this, but that's not really the point.
The point is that you seem to expect us all to assume that you know
what you're talking about, and automatically and quietly translate any
incorrect or imprecise statements you might make into something that's
correct and precise. Nobody else here gets that kind of special
treatment (I certainly don't), and neither will you.

If you're such an expert, take the time and effort to make correct
statements in the first place. If you make mistakes, as we all do,
that's ok, but don't get upset when someone corrects them. We're
going to judge what you write by what you write; we're not going to
waste our time trying to guess what you meant.

Finally, I'll make some comments on the program you posted (as I would
do for anyone else):

"int main(void)" is preferred to "main()".

Proper indentation is helpful, even for small programs. (Possibly you
used tabs for indentation and your news software ate them.)

If you wanted to demonstrate the "considerable flexibility in
what you put after sizeof", you might have shown some examples of
"sizeof ( type-name )".
 
K

Keith Thompson

Ancient_Hacker said:
Did I forget to write that you need to coerce the ptr to char*?:

Yes, you did.
Then you do get the array element size from the macro.

One might wonder if some folks belong to the intentionally-obtuse club.
One might estimate that 98% of "C" experts would realize in an instant
that (char *) is needed to get the right answer. Choosing to instead
be ingenuous and scatter veiled insults may make the writer feel
superior while not being at all helpful.

Nobody was being intentionally obtuse. We know that you need to cast
the pointers to char* for the expression to work properly, but it
wasn't at all clear that you knew that. It's a fairly common error.
In fact, it's common enough that it's in the FAQ; see question 4.4.

Calling yourself "Ancient_Hacker" doesn't make us assume that you're
always right. You made a mistake. It happens.
 
M

Mark McIntyre

Keith Thompson wrote:

<Much>

Have lots of free time, do you?

Apparently you have nothing better to do than make snide remarks about
people who are trying to help you. That suggests something to me.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,184
Messages
2,570,979
Members
47,579
Latest member
CharaS3188

Latest Threads

Top