How to Determine the Size of an Object in C++

How do you determine the size of an object in C++?

To a first order approximation, the size of an object is the sum of the sizes of its constituent data members. You can be sure it will never be smaller than this.

More precisely, the compiler is entitled to insert padding space between data members to ensure that each data member meets the alignment requirements of the platform. Some platforms are very strict about alignment, while others (x86) are more forgiving, but will perform significantly better with proper alignment. So, even the compiler optimization setting can affect the object size.

Inheritance and virtual functions add an additional complication. As others have said, the member functions of your class themselves do not take up "per object" space, but the existence of virtual functions in that class's interface generally implies the existence of a virtual table, essentially a lookup table of function pointers used to dynamically resolve the proper function implementation to call at runtime. The virtual table (vtbl) is accessed generally via a pointer stored in each object.

Derived class objects also include all data members of their base classes.

Finally, access specifiers (public, private, protected) grant the compiler certain leeway with packing of data members.

The short answer is that sizeof(myObj) or sizeof(MyClass) will always tell you the proper size of an object, but its result is not always easy to predict.

Sizeof an Object in c++

First of all in C++ object sizes are determined at compile time. So size cannot change at runtime. Sizeof() actually returns size of the type. All objects of same type have the same size, by language design.

Then, there may be padding, unused bytes between members, so size of a type may actually be a bit larger than just size of all members.

But to answer your actual question: variable length data is not stored in the object itself. Memory for it is allocated separately, and object just stores a pointer to allocated data.

How do I determine the size of my array in C?

Executive summary:

int a[17];
size_t n = sizeof(a)/sizeof(a[0]);

---

Full answer:

To determine the size of your array in bytes, you can use the sizeof
operator:

int a[17];
size_t n = sizeof(a);

On my computer, ints are 4 bytes long, so n is 68.

To determine the number of elements in the array, we can divide
the total size of the array by the size of the array element.
You could do this with the type, like this:

int a[17];
size_t n = sizeof(a) / sizeof(int);

and get the proper answer (68 / 4 = 17), but if the type of
a changed you would have a nasty bug if you forgot to change
the sizeof(int) as well.

So the preferred divisor is sizeof(a[0]) or the equivalent sizeof(*a), the size of the first element of the array.

int a[17];
size_t n = sizeof(a) / sizeof(a[0]);

Another advantage is that you can now easily parameterize
the array name in a macro and get:

#define NELEMS(x)  (sizeof(x) / sizeof((x)[0]))

int a[17];
size_t n = NELEMS(a);

Size of class object in C++

Think of it like this. Let's imagine the standard C++ library didn't have a vector class. And you decided it would be a good idea to have one.

You just might, at a very minimum, come up with something like this. (Disclaimer: the actual vector class for C++ is far more complicated)

template <class T>
class vector
{
    T* items;        // array of items
    size_t length;   // number of items inserted
    size_t capacity; // how many items we've allocated

   public:
     void push_back(const T& item) {
         if (length >= capacity) {
             grow(length * 2); // double capacity
         } 
        items[length] = item;
        length++;
     }

    ...
};

Let's break down an instance of my simple vector class down on a 32-bit system:

 sizeof(items) == 4   // pointers are 4 bytes on 32-bit systems
 sizeof(length) == 4; // since size_t is typically a long, it's 32-bits as well
 sizeof(capacity) == 4; // same as above

So there's 12 bytes of member variables just to start out. Hence sizeof(vector<T>) == 12 for my simple example. And it doesn't matter what type T actually is. The sizeof() operator just accounts for the member variables, not any heap allocations associated with each.

The above is just a crude example. The actual vector class has a more complex structure, support for custom allocators, and other optimizations for efficient iterations, insertion, and removal. Hence, likely more member variables inside the class.

So at the very least, my minimum example is already 12 bytes long. Probably will be 24 bytes on a 64-bit compiler since sizeof(pointer) and sizeof(size_t) typically double on 64-bit.

How to determine size of an object, c#?

I believe what you're seeing is the effect of things needing to align to 8 byte boundaries in 64 bit builds (and 4 byte boundaries in 32 bit builds). 40 is the closest size >= 36 that is on an 8 byte boundary. These links talk about object size:

Of Memory and strings (Jon Skeet's blog)

Benchmarking C# Struct and Object Sizes

Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects

How Much Memory Does a C# String Take Up

How to determine size of the C# Object

If you're just looking for the length of Result if it's a string then you can do the following.

var s = Result as string;
return s == null ? 0 : s.Length;

---

Based on your comment while typing all this up. It sounds like the following is what you actually want

If it's array:

var array = Result as string[];
return array == null ? 0 : array.Length;

---

or if you want the total length of all the items in the array:

var array = Result as string[];
var totalLength = 0;
foreach(var s in array)
{
    totalLength += s.Length;
}

If you want to know the size in bytes then you need to know the encoding.

var array = Result as string[];
var totalSize = 0;
foreach(var s in array)
{
    //You'll need to know the proper encoding. By default C# strings are Unicode.
    totalSize += Encoding.ASCII.GetBytes(s).Length;
}

Knowing the size of a C function in the compiled objectfile

I have found that the output of objdump -t xxx will give definitive function size/length values for program and object files (.o).

For example: (From one of my projects)

objdump -t emma | grep " F .text"

0000000000401674 l F .text 0000000000000376 parse_program_header
00000000004027ce l F .text 0000000000000157 create_segment
00000000004019ea l F .text 000000000000050c parse_section_header
0000000000402660 l F .text 000000000000016e create_section
0000000000401ef6 l F .text 000000000000000a parse_symbol_section
000000000040252c l F .text 0000000000000134 create_symbol
00000000004032e0 g F .text 0000000000000002 __libc_csu_fini
0000000000402240 g F .text 000000000000002e emma_segment_count
00000000004022f1 g F .text 0000000000000055 emma_get_symbol
00000000004021bd g F .text 000000000000002e emma_section_count
0000000000402346 g F .text 00000000000001e6 emma_close
0000000000401f00 g F .text 000000000000002f emma_init
0000000000403270 g F .text 0000000000000065 __libc_csu_init
0000000000400c20 g F .text 0000000000000060 estr
00000000004022c3 g F .text 000000000000002e emma_symbol_count
0000000000400b10 g F .text 0000000000000000 _start
0000000000402925 g F .text 000000000000074f main
0000000000401f2f g F .text 000000000000028e emma_open

I've pruned the list a bit, it was lengthy. You can see that the 5th column (the second wide column with lots of zeros....) gives a length value for every function. main is 0x74f bytes long, emma_close is 0x1e6, parse_symbol_section is a paltry 0x0a bytes... 10 bytes! (wait... is that a stub?)

Additionally, I grep'd for just the 'F'unctions in the .text section, thus limiting the list further. The -t option to objdump shows only the symbol tables, so it omits quite a bit of other information not particularly useful towards function length gathering.

I suppose you could use it like this:

objdump -t MYPROG | grep "MYFUNCTION$" | awk '{print "0x" $(NF-1)}' | xargs -I{} -- python -c 'print {}'

An example:

00000000004019ea l F .text 000000000000050c parse_section_header

$ objdump -t emma | grep "parse_section_header$" | awk '{print "0x" $(NF-1)}' | xargs -I{} -- python -c 'print {}'
1292

Checks out, since 0x50c == 1292.

I used $(NF-1) to grab the column in awk since the second field can vary in content and spaces depending on the identifiers relevant to the symbol involved. Also, note the trailing $ in the grep, causing main to find the main function, not the entry with main.c as its name.

The xargs -I{} -- python -c 'print {}' bit is to convert the value from hex to decimal. If anyone can think of an easier way, please chime in. (You can see where awk is sneaking the 0x prefix in there).

Ah, I just remembered that I have an alias for objdump which presets the demangle option for objdump. It'll make things easier to match if you add --demangle to the objdump invocation. (I also use --wide, much easier to read, but doesn't affect this particular output).

This works on any ELF object, library, program, object file, as long as it's NOT stripped. (I tested with and without debugging symbols too)

Hope this helps.

(I looked, parse_symbol_section IS a stub.)

---

Related Topics