   sizeof object is too large!
  Hi,I an still a junior programmer so please bare with me.I am trying to understand why my object is so large. The object is called a TILE and the only private data member within the TILE is an UNSIGNED SHORT.In my main.cpp:Tile * tile = new Tile( 255 );cout << sizeof( UNSIGNED SHORT );cout << sizeof( *tile );The output is:24So, an UNSIGNED SHORT is 2 bytes and a TILE is 4 bytes.Why is a TILE(which contains only a private UNSIGNED SHORT) larger than the UNSIGNED SHORT alone?Thanks for your help in my understanding of this,AndresPS. I can post TILE code if needed.   
  Many compilers have an option that can be used to pad data structures to certain sizes for alignment reasons. In this case it looks like it may be aligning them to four-byte boundaries. For speed reasons you may want to leave the option on. Turn it off if you really need to save space or your code depends on certain data structure sizes.Probably not the case but: Keep in mind that standards only suggest the minimum size for data types.   ;  The compiler padds the structure to a multiple of 4 bytes for performance reasons. You can avoid the padding if you dissable this option for your compiler.   ;  If you didn't know this, *and* you really need to *care* about it, you are probably doing something else wrong anyway :\ An extra couple bytes of memory is nothing worth worrying about. Worry about unneeded *complexity*.   ;  If you are trying to use this structure to read data to and fro disk, you can surround the stucture declaration with #pragma pack... directives to temporarily disable packing.  Then the size of the structure will be exactly what you ask for.#pragma pack(push, 1) //1-byte (i.e. No) packingstruct Tile{   //...};#pragma pack(pop)  //restore packing to whatever it was before we set it to 1#pragma's are compiler specific, but pack is a very common one.  Usually has that syntax too.   ;Quote:Original post by ZahlmanIf you didn't know this, *and* you really need to *care* about it, you are probably doing something else wrong anyway :\ You elite forum guys are truly the bringers of confidence.I'm sure the poor guy just wanted to know why his 2 byte structure was showing 150% it's size. If you're programming with 328 byte structures, 2 bytes doesn't mean anything. But with a 2 byte structure, that's a major difference. The fact that he's using a short shows he clearly wants to cut the size in half. Even the most intelligent super genius, programming some kind of highly detailed brain cell growth algorithm, may not know about the 4 byte compiler padding. Lighten up man.   ;  Hey guys!Thanks for the replies! That explains to for me and Ill stay away from turning extra padding off. I can find other ways to keep things small, maybe like using an unwrapped UNSIGNED SHORT instead of an object. I wanted it small because its suppose to compile and run in an ARM or X86 processor environment. Thanks for helping learn more about ye compilers.Sincerely,Andres;Quote:Original post by KestThe fact that he's using a short shows he clearly wants to cut the size in half.Lots of people "clearly want to" do things because they are putting together random bits of advice from ancient tutorials (which they can hardly be blamed for; there's lots of crap out there). And lots of people think they want to do things ("save memory") without any real direction (hint: the real savings are almost certainly not in this kind of thing, with any typical real-world design). "Junior programmers" have no business making these kinds of decisions.There's a reason the keyword is 'int' rather than 'integer': it's the shortest, with the intent of making it easier for you to type, and therefore what you reach for by default. After all, it's supposed to represent the machine's default, too.So yes, at the end of the day, something is learned, but it's honestly not worth much worry. Like Shannon said, one common reason for caring about this kind of stuff is for writing structs directly to disk. But this is usually a bad idea anyway, and again the kind of optimization that "junior programmers" shouldn't be attempting.I must sound pretentious because of my high rating, I'm sure. But I didn't exactly get it by being a lounge lizard, you know. I'm trying to be practical here.   