sizeof...

[thushianthan15]

Greetings!!
Currently i am learning C from K&R.I have DOS & Linux in my
system.When i used sizeof() keyword to compute the size of integer , it
shows different results in DOS and Linux.In DOS it shows integer
occupies 2 bytes , but in Linux it shows 4 bytes.Is sizeof operator
"really" shows the machine data or register size ?
Please help
me!!

[Jack Klein]

On Mon, 30 May 2005 06:07:36 GMT, Keith Thompson <ks***@mib.or g> wrote
in comp.lang.c:

CBFalconer <cb********@yah oo.com> writes:

Prashant Mahajan wrote:

All C objects are a multiple of sizeof(char), which is defined
to be one. Usually char is 8 bits, but not always. ^^^^^^^
^^^^^^^^^

Can you please tell where/what are the diffrent sizes of char?I am
new to C and I haven't seen any compiler where size of char is
diffrent from 8 .Please specify.

He did. There is no system where sizeof(char) is not one.

As long as we're being pedantic, why do you assume that the phrase
"size of" refers to the C "sizeof" operator?

Perhaps from the C standard?

6.5.3.4 The sizeof operator (paragraph 2)

"The sizeof operator yields the size (in bytes) of its operand"

In C, there is no way to know the size of an object or type without
using the sizeof operator, with one exception.

That exception, of course, being the character types, for which sizeof
yields a value of 1, and which occupy 1 byte, by definition.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Mark McIntyre]

On Mon, 30 May 2005 18:02:43 +0200, in comp.lang.c , Paul Mesken
<us*****@eurone t.nl> wrote:

On Mon, 30 May 2005 12:13:03 +0100, Mark McIntyre
<ma**********@ spamcop.net> wrote:

And you have proof positive of this for all concievable hardware?
Including specialist math hardware designed to do divisions
ultra-fast?
Let's do it somewhat simpler : _you_ come up with a _single_ piece of
hardware that does divisions quicker than additions.

I have no need to. I'm making no claims at all. You're the one
asserting its slower, and using this as the basis for some requirement
to understand assembler or hardware or something.
I would be mightily impressed.

And I care because?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Paul Mesken]

On Tue, 31 May 2005 00:03:07 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

On Mon, 30 May 2005 18:02:43 +0200, in comp.lang.c , Paul Mesken
<us*****@euron et.nl> wrote:

On Mon, 30 May 2005 12:13:03 +0100, Mark McIntyre
<ma********** @spamcop.net> wrote:

And you have proof positive of this for all concievable hardware?
Including specialist math hardware designed to do divisions
ultra-fast?

Let's do it somewhat simpler : _you_ come up with a _single_ piece of
hardware that does divisions quicker than additions.

I have no need to. I'm making no claims at all. You're the one
asserting its slower, and using this as the basis for some requirement
to understand assembler or hardware or something.

It's completely logical that a division will always be slower than an
addition, given the algorithms that are used to implement it.

Here's an overview :

http://www.ecst.csuchico.edu/~julian...97division.pdf

And as for proof that divisions are slower than additions on all
conceivable hardware :

Of course, I don't have such proof since I don't know all conceivable
hardware (who knows? some quantum computer).

But that doesn't disproof my assertion. Everyone with a tiny bit of
knowledge about how divisions and additions are implemented in
hardware will realize that additions are quicker (implementing an
addition with boolean primitives is about the very first excercise one
does when learning hardware implementation) .

It's simply logical.

Of course, you can choose to ignore this and program as if divisions
are just as quick as additions.

Personally, I'll never choose ignorance over knowledge. Ignorance is a
flaw, not a feature.

I would be mightily impressed.

And I care because?

You have to ask that to me?

[Jack Klein]

On Mon, 30 May 2005 02:04:29 +0200, Paul Mesken <us*****@eurone t.nl>
wrote in comp.lang.c:

On Sun, 29 May 2005 18:31:15 -0500, Jack Klein <ja*******@spam cop.net>
wrote:

Caring about whether or not there is a performance penalty
for one thing or another thing is off-topic here, is a micro
optimization , and has nothing to do with the C language, which does
not specify anything at all about the speed or efficiency of anything.

[snip]
If speed and efficiency are of no concern then there are better
languages than C. C is not the only portable language (how about
Java?).

Java? Portable? You have just disqualified yourself from any serious
discussion of C on various architectures. Such as the 98% of
processors and controllers manufactured in the world today that are
not used as the main CPU in desktop/laptop/server applications.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Paul Mesken]

On Tue, 31 May 2005 01:11:56 -0500, Jack Klein <ja*******@spam cop.net>
wrote:

On Mon, 30 May 2005 02:04:29 +0200, Paul Mesken <us*****@eurone t.nl>
wrote in comp.lang.c:

If speed and efficiency are of no concern then there are better
languages than C. C is not the only portable language (how about
Java?).

Java? Portable? You have just disqualified yourself from any serious
discussion of C on various architectures.

Well, lucky me then that such discussions aren't topical here ;-)

[Malcolm]

"Jack Klein" <ja*******@spam cop.net> wrote

In C, there is no way to know the size of an object or type without
using the sizeof operator, with one exception.

size_t sizeof(int)
{
int *mem = malloc(1024);
unsigned char *ptr = (unsigned char *) mem;
size_t answer = 0;
memset(mem, 0, 1024);
*mem = ~0;
while(ptr[answer] != 0)
answer++;

return answer;
}

(OK maybe we've got padding bytes. So write to mem[1] and check.)

[Anonymous 7843]

In article <ir************ *************** *****@4ax.com>,
Jack Klein <ja*******@spam cop.net> wrote:

In C, there is no way to know the size of an object or type without
using the sizeof operator, with one exception.

look at the declaration for the object and figure it out (human error possible)

offsetof() the type's sucessor in a struct (padding may add to apparent size)

pointer differences in an array of the type (padding)

set last (subpart) to a known value and use memchr to search for it
(begs the question of the size of the last subpart, but that should
be smaller and simpler and not be turtles all the way down)
--
7842++

[pete]

Malcolm wrote:

"Jack Klein" <ja*******@spam cop.net> wrote

In C, there is no way to know the size of an object or type without
using the sizeof operator, with one exception.

size_t sizeof(int)
{
int *mem = malloc(1024);
unsigned char *ptr = (unsigned char *) mem;
size_t answer = 0;
memset(mem, 0, 1024);
*mem = ~0;
while(ptr[answer] != 0)
answer++;

return answer;
}

(OK maybe we've got padding bytes. So write to mem[1] and check.)

sizeof(int) isn't limited to 1024.

~0 is equal to zero on one's complement machines.
Assignment is by value.

--
pete

[Malcolm]

"Paul Mesken" <us*****@eurone t.nl> wrote

But that doesn't disproof my assertion. Everyone with a tiny bit of
knowledge about how divisions and additions are implemented in
hardware will realize that additions are quicker (implementing an
addition with boolean primitives is about the very first excercise one
does when learning hardware implementation) .

But replacing a division with an addition is a micro-optimisation. Only
rarely will it make any real difference to a program's running time.
As for the single counterexample, consider this.

I've got a weighing factor I've got to apply to some variables. If I didn't
have to worry about running time at all I would implement it like this.

double weight = loadweightfacto r();
....
x[i] /= weight;

However let's say that the array x consists of integers, and the weight is
usually 5/16. (ie 3.2)

So let's optimise our code

if( weight == 5/16)
{
/* in loop */

x[i] = ((x[i] << 2) + x[i]) >> 4;
y += strlen(str);
}

So we've got rid of our division and replaced it with a addition and two
shifts.

However this thing is running on a Pentium. It is not entirely impossible
that the floating point pipeline is idle, whilst the main pipeline is
overloaded. So what we have done is replaced a free instruction with several
instructions that actually cost microseconds.

So it isn't always the case that replacing a division with an addition will
speed things up.

[Mark McIntyre]

On Tue, 31 May 2005 01:42:19 +0200, in comp.lang.c , Paul Mesken
<us*****@eurone t.nl> wrote:

It's completely logical that a division will always be slower than an
addition, given the algorithms that are used to implement it.
And I say again, you can prove this to be completely true, for all
hardware, including specially optimised hardware? Imagine a system
that does addition on an 8080 and division on a Pentium. Which
operation is faster?

This may sound daft. But its perfectly possible to build hardware with
a FP unit which runs at higher clock speeds than the main cpu (in fact
it probably makes sense, FP operations often take more clock cycles).
So I can easily envisage hardware on which addition and division were
of comparable speeds, or better.

Or consider for instance floating point addition, and integer division
by two. Which is faster?
Of course, I don't have such proof since I don't know all conceivable
hardware
Indeed. But no need to invoke magic. Today's hardware could do it.But that doesn't disproof my assertion.
The thing about assertions is, to make them into facts, you have to
prove them to be true.
Everyone with a tiny bit of knowledge
I'm sure we all remember what they say about a little knowledge.
Of course, you can choose to ignore this and program as if divisions
are just as quick as additions.
Or you can program as if thats something you should not be worrying
about yet. Do you recall the three laws of optimisation?
Personally, I'll never choose ignorance over knowledge. Ignorance is a
flaw, not a feature.

And arrogance about ones knowledge is a bigger one, IMHO. YMMV.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >