OutputCode:int ibuf[5]; // or even int ibuf[5] = {1,2,3,4,5}; printf("Size of ibuf: %i\n", sizeof(ibuf));
Why? Is this the size of the array in bytes? How do I get the number of elements?Code:Size of ibuf: 20
Why then, does this return what I expect it to?
Output:Code:char cbuf[5] = "Hello"; printf("Size of cbuf: %i\n", sizeof(cbuf));
Code:Size of cbuf: 5
Yes.Originally Posted by cnewbie1
With the expression:
Note that ibuf really has to be the array, not a pointer to an element of the array.Code:sizeof(ibuf) / sizeof(ibuf[0])
Look up a C++ Reference and learn How To Ask Questions The Smart Way
sizeof(int)=4
sizeof(char)=1
thats why your output is 20 with 5 integers.
Sorry, a bit slow here. That I didn't get :-/
Each element takes 4 bytes. 4 x 5 elements = 20.
If you're looking suss out the number of elements in an array, take the size of the array and divide it by the size of each element...
(I like laserlight's solution better, btw)Code:int x; int y; int z; int array[10]; x = sizeof(int); // 4 because each int needs 4 bytes. y = sizeof(array); // 40 bytes z = y / x; // 10 elements // or int ArraySize = sizeof(array) / sizeof(int);
Ok. An int needs 4 bytes. But a char actually needs only one?
type this code and run it.
your output should be int=4 and char=1.Code:#include<stdio.h> main() { printf("size of int =%i",sizeof(int)); printf("\nsize of char =%i",sizeof(char)); }
i guess you are using amd??
anyways on different machines you will find different resuilts.Like sizeof(int) on my machine is 2 bytes.
and so you can do for any data type.
No, I'm on a new intel processor.
Ok, so this is processor-dependent, and I'll have to check this for every processor type? Nice to know :-)
My previous programming experience is with Java and PHP, so it's taking a while to get used to not having all those abstract functions like count(array), string data type etc. etc. Thanks for the answers :-)
Well i dont really know on what this depends even me i was interested to know your processor because i've seen sizeof(int)=4 on amd.
i am on intel too but my int is 2 bytes.
so may be it depends on the compiler in the pre-processor directives, or your operating system 64 bit or 32 bit.
Yup, it might depend on several factors. My processor is (naturally) 64-bit, but my OS is 32-bit. Furthermore, I'm using Linux and gcc.
No it's not processor dependent... It's compiler dependent. In a given compiler you can safely expect the sizes always remaining the same.
The reason variables are different sizes is pretty simple... underlying the various types is binary storage. A 1 byte variable can only store values in the range from -127 to +127 ... 2 bytes gives you -32767 to +32767... and so on. So it's a question of capacity. Some variables can be up to 16 bytes (again dependending on the compiler in use).
BTW... if sizeof(Int) is returning 2 bytes, that's a 16 bit compiler... Unless you are working on microcontrollers, it is seriously outdated. There are tons of perfectly good free 32 and 64 bit compilers out there. Many OS versions won't even run 16 bit code anymore...
smorgasbordet - Pelles C
C is an extensible language. That is to say you can write your own libraries of functions and include them into your projects. Many of the so called abstractions like getting the number of elements in an array, flipping the sign of a variable etc. are very easily written and can be built into a static library and called as needed. This may not be standard C, but so long as you are willing to share the library with anyone who has to compile your code it's no problem.My previous programming experience is with Java and PHP, so it's taking a while to get used to not having all those abstract functions like count(array), string data type etc. etc. Thanks for the answers :-)
Someplace in my dusty old archives I believe I still have a string library I wrote years ago (when first learning C) that uses Pascal style strings instead of the C standard... That's part of the joy of working this close to the System... If you don't like it... you can re-create it to your liking.
Hmm...I don't remember anyone mentionining 2 bit int size here. It would be seriously strange with a 16-bit version of gcc in a new Linux distro.
As to the other points you mention, I absolutely agree. That's the main reason I want to learn C, along with the fact that there seems to be fewer and fewer C-programmers out there (at least here in Norway). .NET and Java seems to be the main focus of everyone learning programming nowadays, and the demand for those skills seems to just grow and grow. If I had any economical sense, I'd learn .NET and C#. But, that me :-)
Well, technically it is processor and platform dependent, and the compilers adhere to those requirements.
int is typically described as a variable whose size is of the native size of the processor. So on 16 bit cpu, it would 16 bits, on 32 bit cpu it would be 32 bits, and so on.
Obviously, using a 32-bit integer on a 16-bit cpu would harm performance, so the compiler takes advantage of this when deciding what size the types should be.
You may also want to check out C++. It is even more extensible.
Ideally you are right... but in practice it ends up being the compiler. I say this because I use a 32 bit compiler on a 64bit CPU and several people here are using 16bit compilers on 32 and 64 bit systems. Granted some updating is probably the best bet but the compiler does seem to be calling the shots.
