views:

146

answers:

4

Hi, suppose I have a class defined as follows

class foo
{
    char [10] bar;
}

How would the size of this class differ when in a 64 bit environment compared to a 32 bit one, assuming no padding/packing.

I believe the 64 bit version of the class would be 4 more bytes in length since:

  1. The class must contain a char* in order to point to the start of the array bar
  2. an char* is 8 bytes in a 64 bit environment vs 4 bytes in a 32 bit environment

Am I correct?

Thanks!

A further question about how arrays actually work If there is no pointer stored when you declare an array, how come you can get an address out of the array name and do things like bar[0], bar[1], etc?

+4  A: 

No you are not. char [] bar; won't even compile, char bar[10]; is the correct syntax, and no, no pointer is stored, sizeof(char) is always 1 and sizeof bar will be 10, regardless of the architecture.

Now for your additional question: You must understand the notion of lvalues and rvalues and lvalue-to-rvalue conversions. Usually lvalue-to-rvalue conversions "do nothing". An excetion is that an lvalue-to-rvalue conversion for array of T is conversion to a pointer to T which points to the first element of the array.

Also a function declaration taking an array of T by value is equivalent to a function declaration taking a pointer to T.

Armen Tsirunyan
sizeof(bar) will be 10 regardless, but sizeof(foo) might not (and often won't) be.
Jerry Coffin
@Jerry Coffin> wk1989 did say "assuming no padding/packing".
Klaim
I routinely work on machines where sizeof(char) == 2. There is a big world out there...
florin
@florin: in that case you work on machines (or rather, compilers) that don't respect the standard. In C++, `sizeof(char)` is 1. It may be larger than 8 bits, however.
jalf
@florin You don't by any chance think of C# do you?
Armen Tsirunyan
@jalf: or smaller that 8 bits, come to think of that :)
Armen Tsirunyan
@Armen: no -- `char` must be able to store 256 distinct values, so it's a minimum of 8 bits.
Jerry Coffin
@Jerry: char must be large enough to store the basic execution character set, but I haven't counted those. If there are more than 128 items in it then you are right, otherwise no
Armen Tsirunyan
@Armen: The C standard, §5.2.4.2.1 gives a range of 256 as the minimum. The C++ standard pretty much echoes that requirement (the obvious difference being that it mostly talks about things like `std::numeric_limits<unsigned char>::max()` instead of `UINT_MAX`).
Jerry Coffin
@Jerry: Ok then, I forfeit :)
Armen Tsirunyan
+2  A: 

sizeof(char) is defined as 1 in the C++ standard, no matter what your architecture is. Your struct is an array of 10 chars, not a pointer to an array.

Also, the proper declaration would be char bar[10].

You're probably thinking about char *bar - now that would be a 4 bytes vs 8 bytes in 32-bit vs 64-bit.

EboMike
Can you point me to the section of the standard that specifies that sizeof(char) == 1? I routinely work on machines where sizeof(char) == 2.
florin
@florin: §5.3.3/1: "sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1. The result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined."
Jerry Coffin
Ha, there was a discussion about that in another question here on stackoverflow, and I think it had a link. I'll see if I can dig it up.
EboMike
Never mind. Thanks Jerry :)
EboMike
@florin: What sort of system do you work on? I'm curious.
David Thornley
@David Thornley: I work on some embedded DSPs, and sometimes I have to port some code that makes bad assumptions about sizes, padding and alignment. Chasing those buggers is no fun.
florin
+2  A: 

The one way you might see a difference would be if the compiler decided to insert some padding after the array so if you were to create an array of these objects, each would be nicely aligned. For example, on a 32-bit target it might pad it out to 12 bytes, but on a 64-bit target to 16 bytes instead.

Without padding, however, the two would be the same size -- you're not defining a pointer, so the difference in pointer size has no effect here.

Jerry Coffin
+1  A: 

The example you give will not become larger on a 64-bit environment.

class foo
{
    char bar[10];
};

However, it's also quite useless because it has no public members.

Many classes look more like this:

class foo2
{
public:
    char bar[10];
    virtual ~foo2() {}
};

A class with any virtual members at all, such as foo2 has, will grow when the pointer size grows. However, with most compilers, there is only one pointer regardless of how many virtual members.

Either way, it's only a concern for classes that you create a large number of (> say 20000 instances).

Ben Voigt