Thread: When to use a .cpp file

Originally Posted by brewbuck

You are aware that the compiler pads the structures for you, right?

It depends on the compiler and its default settings. In fact, Visual C++ 2003 and Visual C++ 2005 do not do what you just assumed.

Code:

#include <iostream> 
#include <string> 
 
struct Actor
{
	unsigned short int a;
};

int main()
{
	std::cout << sizeof(Actor) << std::endl;

	system("pause");
	return 0;
}

Returns 2 bytes bud

I would suggest that you read the docs a little more carefully. It will become your best friend.

In most cases, just go to Project - Properties - C/C++ - Code Generation - Struct Member Alignment

In code, you can do this...

Code:

#define ALIGN32 __declspec(align(32))

ALIGN32 struct Actor
{
	unsigned short int a;
};

During runtime, sizeof(Actor) returns 32.

Of course, you would want each field to be 4-bytes if possible so the Pentium doesn't scream in tongues due to the wreaking havoc in memory addressing. But the unsigned short int data type clearly suggests that the struct is not aligned 32-bytes by default by the compiler.

I wouldn't say they're stupid. I would say they are smart... not wasting any memory than having to. If you were writing a real-time application, it would be important to turn on 32-bit alignment (or more). If you're writing a word processor, this extra memory would have been a waste. It a smart move, if you ask me. Not everyone benefits from it. You will see compilers that have it on by default, but the bigger/bloated your word processor will be too for no particular reason. It just depends on the problem trying to be solved, and default settings will not always be the right way to go, regardless of what OS taste you have.

Not a good example of padding... In most cases padding is put between members, not after the last member

what about

Code:

#include <stdio.h>

struct test
{
	char a;
	int b;
};
int main(void)
{
	printf("&#37;d\n", sizeof(struct test));
	return 0;
}

The struct would be 5 bytes then. A better idea so its accessed in a DWORD boundary would be this...

Code:

struct test
{
        int ch;
        int n;
};

It wastes space since it's now 8 bytes, but it may be better for the Pentium if you're doing any high performance stuff. Theres less addressing havoc. I'm not sure what you mean with padding between members.

In all worst cases, given you have a compiler that doesn't help, you can give the struct dummy variables so it is 32-bit. The point is it doesn't matter how you do it, but as long as you do it when it comes to critical-performance applications. Never assume the compiler is doing it for you.

The struct would be 5 bytes then

Have you tested it on VS2005? Because this compiler - that you claim does not do padding, shows the sizeof struct as 8

Yes. My point on that example was if you aren't padding for some odd reason, keep each member 32-bit if possible. 8 bytes is slightly better than the 5-byte example. Pentiums like 32-bit! Better yet, you can pad it with dummy variables if the compiler doesn't have alignment options. But that's getting pretty rare but I have seen them.

Anyway, this thread is getting a little off topic caused by me and others (it was about cpp files initially somewhere ). Thanks for the conversation in text-mode.

I don't see why you want to make each var int if you do not need it.
Keep your types as you need. Leave compiler worry about padding.
When you come to size or speed issues - solve them.
The unconditional optimization - is evil

That's the problem... people think the compiler knows what they are trying to do but it just ends up making horrible products.

You use two ints because you do need it in performance-critical applications.

int + char = (4 + 1) = 5 bytes.

The pentium is 32-bit. Do the math. You're going to wreck havoc in memory addressing. I come from a real-time programming background. I don't think it matters if you're doing event-driven software. There's no gain from keeping everything 32-bit as possible when building a word processor, so you can use as much horrible solutions as you want and let the compiler do all the default settings for you... no one will notice. That's the majority of the general software industry for you

I'm doing RT programming - and I know what I'm talking about... You think you smarter than the compiler... Take a profiler - and prove it... Otherwise - all your talking is just a blah-blah

I'm not sure what you mean with padding between members.

An example would be:

Code:

struct test
{
    char a;
    int b;
    char c;
};

versus:

Code:

struct test
{
    int b;
    char a;
    char c;
};

On my machine both the MinGW port of g++ 3.4.2 and VS2005 pad such that the former takes 12 bytes and the latter 8 bytes.

I think that even without profiling this kind of rearrangement of members is reasonable. Unless you are crazy about listing members in alphabetical order or grouping them in specific ways, their order usually does not matter too much, so you might as well potentially save some space.

Never assume the compiler is doing it for you.

I think that you should assume the compiler is doing for you, but check on it if it is critical.

Hmm, that is interesting. I'm getting 12 and 8 as well. Each structure has the same variables and data type, but its arrangement is adjusting the structure's size. I'm not understanding what it's doing internally. That will be worth looking into.

Vart, fit the problem you are trying to solve. If you're happy with the default settings, more power to you.

I'm not understanding what it's doing internally

It adds padding to save the member alignment

Code:

struct test
{
    int b;
    char a;
    char c;
};

b ends on the WORD boundary that is as well the byte boundary, so a and c are located here without padding...

Code:

struct test
{
    char a;
    int b;
    char c;
};

a ends on the BYTE boundary but it is NOT a WORD boundary, so 3 bytes padding is added before b...

I think that even without profiling this kind of rearrangement of members is reasonable.

I didn't say you need profiling to arrange struct members from bigger sizes to smalles to get to decrease the size of the struct for free...

But changing chars to ints just because you think it will work faster - you should prove it before applying such a change... You gain on the memory access speed - you loose in the cache utilization...