5

I am playing around with sizeof() in GCC on a Linux machine right now and I found something very surprising.

printf ("\nsize of int = %lu\n", sizeof(int));
printf ("\nsize of int* = %lu\n", sizeof(int *));

yields

size of int = 4
size of int* = 8

I thought the size of a pointer to an integer would be much smaller than the actual integer itself!

I am researching embedded software right now and I was under the understanding that passing by reference was more efficient (in terms of power) than passing by value.

Could someone please clarify why it is more efficient to pass by reference than by value if the size of the pointer is larger than the actual value.

phuclv
  • 37,963
  • 15
  • 156
  • 475
icedTea
  • 495
  • 2
  • 7
  • 12
  • 4
    Are you running on a 64-bit operating system? – Andrew Rasmussen Feb 20 '12 at 18:24
  • Don't compare the sizes of objects (or types). Use them as needed. – pmg Feb 20 '12 at 18:31
  • Great! I am on a 64bit machine but why is it more efficient to pass by reference than by value? – icedTea Feb 20 '12 at 18:31
  • 2
    It's not necessarily "inefficient" just because the argument happens to be 64 bits instead of 32 bits. In terms of "power usage", you need to count 1) the #/instructions needed to execute an operation, and 2) the #/cycles needed to complete an instruction. "Pass by reference" can eliminate the need to COPY data. This can be a big savings for data records. It's probably slightly less efficient than "pass by value" for scalar values like "int". – paulsm4 Feb 20 '12 at 18:38
  • to print pointer use [`%p`](http://stackoverflow.com/q/9053658/995714) – phuclv Dec 02 '16 at 06:55

8 Answers8

10

Integer can be any size the compiler writer likes, the only rules (in standard C) are: a) int isn't smaller than a short or bigger than a long, and b) int has at least 16 bit.

It's not uncommon on a 64bit platform to keep int as 32bits for compatibility.

sleske
  • 81,358
  • 34
  • 189
  • 227
Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • Where "you" are someone implementing C, if that's not obvious. – Steve Jessop Feb 20 '12 at 18:29
  • @JerryCoffin - sorry I scanned that number as 32bits. I was sure that it used to be 16bits on early Windows - which of course it was. – Martin Beckett Feb 20 '12 at 19:21
  • @Jerry: another way to ensure at least 32 bits is with `int_least32_t`. It's a required type in C99, and unlike `long` you shouldn't end up with an unnecessarily big 64-bit type on LP64 implementations. The downside is that you don't want to type `int_least32_t` more than once in your program, so you end up typedefing it and introduce an extra level of indirection for readers. – Steve Jessop Feb 21 '12 at 09:41
5

Passing by reference is more efficient than passing by value when the value to be passed is larger than the size of the reference. It makes a lot of sense to pass by reference if what you are passing is a large struct/object. It also makes sense to pass a reference if you want to make persistent modifications to your value.

Stephen
  • 3,515
  • 5
  • 27
  • 33
3

Passing by reference is more efficient because no data (other than the pointer) needs to be copied. This means that this is only more efficient when passing classes with many fields or structs or any other data that is larger than a pointer on the system used.

In the case you mentioned it could indeed be more efficient to not use a pointer because the actual value is smaller than a pointer to it (at least on the machine you were using). Bare in mind that on a 32 bit-machine a pointer has 4 bytes (4*8 = 32bits) while on the 64-bit machine you were apparently using the pointer has 8 bytes (8*8 = 64bits).

On even older 16 bit machines pointers do only require 2 bytes, maybe there are some embedded systems still using this architecture, but I don't know about this...

Ashwani Mehlem
  • 125
  • 1
  • 7
2

In C, a pointer, any pointer, is just a memory address. You're on a 64-bit machine, and at the hardware level, memory addresses are referred to with 64-bit values. This is why 64-bit machines can use much more memory than 32-bit machines.

gsteff
  • 4,764
  • 1
  • 20
  • 17
  • The nn-bits of a certain CPU stands for how large chunks of data it can process in a single instruction, also known as the "data bus". This has nothing to do with how large addresses there are on the computer. In fact the address bus is often of different width than the data bus. On 32/64-bit (data bus) PC computers, the address bus just happens to be as large as the data bus, for convenience. – Lundin Feb 21 '12 at 13:38
2

One thing has nothing to do with the other. One is an address, a pointer to something, doesnt matter if that is a char or short or int or structure. The other is a language specific thing called an int, which the compiler for that system and that version of compiler and perhaps command line options happens to define as some size.

It appears as if you are running on a 64 bit system so all your pointers/addresses are going to be 64 bit. What they point to is a separate discussion, longs are probably going to be 64 bits as well, sometimes ints, shorts probably still 16 bit but not a hard/fast rule and chars hopefully 8 bits, but also not a hard/fast rule.

Where this can get even worse is cross compiling, while using llvm-gcc, before clang was as solid as it is now. With a 64 bit host the bytecode was all being generated based on the 64 bit host, so 64 bit integers, 64 bit pointers, etc. then when you do the backend for the arm target it had to use compiler library calls for all of this 64 bit work. The variables hardly needed to be shorts much less ints, but were ints. the -m32 switch was broken you still got 64 bit integers due to the host not the ultimate target. gcc directly doesnt appear to have this problem and clang+llvm doesnt currently have this problem either.

The short answer is the language defines some data types char, short, int, long, etc and those data types have a compiler implementation defined size. and address is just another implementation defined data type. it is like asking why is a short not the same number of bytes as a long? Because they are different data types one is a short, one is a long. One is an address the other is a variable, two different things.

old_timer
  • 69,149
  • 8
  • 89
  • 168
2

A pointer to an integer can point at a single integer, but the same pointer can also point at ten, twenty, one hundred or one million integers.

Obviously passing a single 8 byte pointer in lieu of a single 4 byte integer is not a win; but passing a single 8 byte pointer in lieu of one million 4 byte integers certainly is.

caf
  • 233,326
  • 40
  • 323
  • 462
0

http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html

When converting 32-bit programs to 64-bit programs, only long types and pointer types change in size from 32 bits to 64 bits; integers of type int stay at 32 bits in size.

In 64-bit executables, pointers are 64-bits. Long ints are also 64-bits, but ints are only 32-bits.

In 32-bit executables, pointers, int's and long ints are all 32-bits. 32-bit executables also support 64-bit "long long" ints.

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • not universally true, perhaps in one instance for one compiler or generation of that compiler (gcc 4.x for example). – old_timer Feb 20 '12 at 18:32
  • As dwelch indicates, different compilers use different memory models. Microsoft uses IL32P64 (32-bit longs and 64-bit pointers) and most Unices (apparently including Mac OS X) use I32LP64 (64-bit longs and 64-bit pointers). I'm not sure about GCC for Windows. – Alex Measday Feb 20 '12 at 23:36
0

A pointer must be able to reference all of memory. If the (virtual) memory is larger than 4 Gi bytes or so, then the pointer must be more than 32 bits.

Doug Currie
  • 40,708
  • 1
  • 95
  • 119