any way to determine size of array thats a function parameter?

Oops I meant division but said sizeof(). And I cannot stress this enough, my brain doesn't truncate decimal values. I never at any point said that the run-time result would be .5 I said that 4/8 = .5, they are two very distinctively different things. Even if you put:

Code:

---

int f(double *array) {
  size_t size = sizeof(array)/sizeof(*array);
  return (signed)size;
}

int main( void )
{
    double array[] = { 0.0, 1.1, 2.2 };
    printf("returned value is %g\n", (double)f( array ) );
    return 0;
}

---

printf() would still print 0 due to the limitations of the data-type. I'm not certain of why you are arguing with me as I never said prelude was wrong about how the integers will be handled. However, I did say that sizeof(double *)/sizeof(double) is equal to .5. But since quzah has trouble understanding I will modify my original post:


[revision]

Code:

---

int f(double *array) {
  size_t size = sizeof(array)/sizeof(*array);
  return (signed)size;
}

---

Is wrong as you are saying the size of a pointer divided by the size of a double. Which on my machine would be .5, which I guarantee you is not what you were looking for ;) Of course the return of this function will be 0 as the function is using integer math, which will truncate any decimal value.
[/revision]

Well thank goodness for the int datatype to give us a warm helping hand to help us out in truncating needs. I had the same problem reading your post master5001, it reminds me of this paragraph that you had to read and count how many "of"'s there are. The mind knows they're there subconsciously, but it doesn't ever reach you at conscience level, interesting!

Ok fair enough. Your argument is compelling enough that I went ahead and removed some of the hostility from my revision tags.

Quote:

---

Is wrong as you are saying the size of a pointer divided by the size of a double. Which on my machine would be .5, which I guarantee you is not what you were looking for Of course the return of this function will be 0 as the function is using integer math, which will truncate any decimal value.

---

No it isn't. size_t is integeral, thus any value it has will also be integral. As such, you can never have that value be .5 on your machine. It is as stated, impossible. You will never get "sizeof a pointer divided by sizeof a double" to equal anything other than an integer. Period. You are dealing with integers, as stated, and as such, you can never, I repeat NEVER have an integer .5.

Quzah.

>However, I did say that sizeof(double *)/sizeof(double) is equal to .5.
Logically, perhaps, but in every conforming implementation, sizeof evaluates to size_t, which is an unsigned integral quantity. The division is working with integers, so .5 never enters into the equation as far as C is concerned. If you can figure out a good way for a floating-point byte size to be meaningful then you can submit a defect report to ISO. :)

I never said that it did evaluate to any sort of floationg point value, nor do i see any reason why one would want it to. However, if one really wanted too...

Example:

Code:

---

#define sizeof_f(type)  (double)sizeof((type))

---

Of course I am certain that if I said sizeof(double *)/sizeof(double) was equal to zero (note now I NEVER said the compiler will evaluate anything to anything) people would have jumped an my ass and started complaining about how 4/8 is not 0. Point, this is almost an argument of symantics, however its not quite one as I didn't exactly leave any loop-holes in my wording.

>#define sizeof_f(type) (double)sizeof((type))
That's a syntax error, but if you remove the parens around type in sizeof, it will compile and work as you expect.

>people would have jumped an my ass and started complaining about how 4/8 is not 0
And they would have been just as wrong as you were by saying that

Quote:

---

size of a pointer divided by the size of a double. Which on my machine would be .5

---

And we would have jumped on their asses about it. Sure, you can make the statement right by converting the result of sizeof before the division, but since the comment in question was about this code:

Code:

---

size_t size = sizeof(array)/sizeof(*array);

---

It was wrong (regardless of what you really meant), there are no loopholes in your wording or misunderstandings on our part, and you could have avoided all of this by not defending your mistake. I see where you're coming from, really I do. But it causes unnecessary confusion, so it's better to stick with C's rules and explain them if someone questions you.

Quote:

---

Originally Posted by master5001

I never said that it did evaluate to any sort of floationg point value, nor do i see any reason why one would want it to. However, if one really wanted too...

Of course I am certain that if I said sizeof(double *)/sizeof(double) was equal to zero (note now I NEVER said the compiler will evaluate anything to anything) people would have jumped an my ass and started complaining about how 4/8 is not 0. Point, this is almost an argument of symantics, however its not quite one as I didn't exactly leave any loop-holes in my wording.

---

Sure you did, let me quote you:

Quote:

---

Which on my machine would be .5,

---

Your machine, dividing integers will most definately NOT give you .5 for that.

Quzah.

> Which on my machine would be .5
RIGHT! I did not say on my compiler. On my 32-bit x86 architecture cpu, a double is 8 bytes in size and a point to a double is 4 bytes in size. Lets see 4/8 = .5. This particular issue is a good example to people who don't understand why integer math truncates decimals. Indeed it would be the best, as you cannot have a partial byte. Its either all or none on this one. In any event, and back to the original point, this is not the operation the fishjie wants as it will give him a value of 0 when evaluated by the compiler rather than doing it in his head, which doesn't truncate decimals. Since you two want to keep arguing with me and this is going no where all I can do is ask Hammer to be so kind as to close this thread.

I don't know about you but when I do integral math in my head for a program I automatically truncate decimals.

The problem is that you made an incorrect statement, people nicely tried to call you on it and you fought back. Admit that what you said and what you meant are two different things and let it be.

>Since you two want to keep arguing with me
At this point, you can believe what you want to. However, I'll continue to correct you if you keep trying to confuse people with your little machine/compiler distinction.

What an utterly pointless debate...

There is a distinction between my compiler and hardware. I never refer to my compiler as my hardware. I truthfully don't see how what I said is different from what I mean. And ultimately I don't really care at this point. I'm going to just shut off my compiler (since you guys want me to call my machine my compiler now) and from now on state both what I mean and what I don't mean since it may be the only way to make my comments crystal clear.

Quote:

---

Originally Posted by CornedBee

What an utterly pointless debate...

---

rofl, yeah this is pretty deep. But I do believe everyone is correct in this debate, it's just the way they look at it that sparks the disbelieve in the opposition.

I think someone needs a lesson on how computers do integer divison and why 4/8 = 0 and not .5

You see the CPU calculates the number of times the divisor can go into the dividend. This can be simulated with the subtracted method (for ease of use we'll assume unsigned since thats what sizeof produces):

Code:

---

int dividend = 4;
int divisor = 8;
int quotient = 0;
int remainder = dividend;
while ( remainder >= divisor )
{
  quotient += 1;
  remainder -= divisor;
}

printf("%d / %d = %d with remainder = %d\n", dividend, divisor, remainder);

---

Since 4 is not greater then or equal to 8 it never goes into the loop.

And on another point any math involving just compile time constants are resolved by the compiler. So if you had:

Code:

---

int x = 4 + 12

---

you aren't going to see an addition proformed at runtime. You'll see a move instructor putting the value 16 into the spot allocated for x.