#### Archived

This topic is now archived and is closed to further replies.

# C++ structs vs. variables

This topic is 5222 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is there any overhead involved in stuffing a bunch of variables into a struct? For instance, if I had a bunch of variables: int a, b, c, d, e, f, g, h, i, j; and I wanted to put them into a struct to make it more mentally managable: struct foo { int a, b, c, d, e, f, g, h, i, j; };, is there now any overhead in accessing those variables? In other words, if I previously did this: SomeFunction(a); and now I do: SomeFunction(my_struct.a), is that any slower?

##### Share on other sites
Twenty years ago I think it was. Today the hardware has direct addressing modes for this type of memory access.

##### Share on other sites
it''s exactly the same - the compiler knows the layout of the struct at compile time.

##### Share on other sites
Architect first, optimize later.
Even if it was slower, optimization should not come at the cost of organization and readability.

##### Share on other sites
What about if I have a lot of structs, or the structs are really big? Ex. my_struct.a.foo.bar.blah.erm.wut.huh I read that direct mode addressing only gives you a small range to work with. So there must be some overhead at some point, right?

##### Share on other sites
quote:
Original post by PlayGGY
These kinds of questions are just interesting to me. I also enjoy the "which one is faster, array[x][y] or array[y][x]?" discussions

##### Share on other sites
a.b.c.d.e.f.h and a.g are exactly the same speed. Here''s why.

Let''s suppose you have an int myInt on the stack (as a local variable). That means that in one of your registers is a stack pointer, and a certain (constant) offset up (or down, depending on architecture), is the beginning of your myInt. This offset is known at compile-time, since it''s just related to all the local variables you define. (In case you were wondering, this is why you used to have to define all your variables at the top of blocks in C). So when you want to, say, assign 3 to myInt, the computer does something like *(SP + 12) = 3, where 12 is the offset into the stack. If instead of myInt you have myStruct which has a struct which has a struct which has an int myOtherInt, etc, you still know--at compile time--where, relative to the stack pointer, myOtherInt is. So you can just change the offset, and you''re good to go.

What will change performance is if your struct stores, not structs, but pointers to structs, since those require extra run-time lookups. a->b->c->d->e->f is considerably slower than f.

"Sneftel is correct, if rather vulgar." --Flarelocke

##### Share on other sites
quote:
Original post by Sneftel
a.b.c.d.e.f.h and a.g are exactly the same speed. Here's why.

quote:
Original post by sjelkjd
it's exactly the same - the compiler knows the layout of the struct at compile time.
You don't know that, since it is totally up to the compiler. He never said which compiler and which platform he is using and neither did you.

There are cases on today's hardware with today's compilers where putting the variables into a struct would result in slower code.

[edited by - JohnBolton on April 3, 2004 3:47:36 PM]

##### Share on other sites
quote:
Original post by JohnBolton
There are cases on today''s hardware with today''s compilers where putting the variables into a struct would result in slower code.

Like what? (not disbelieving, just interested)

"Sneftel is correct, if rather vulgar." --Flarelocke

1. 1
2. 2
3. 3
Rutin
22
4. 4
JoeJ
16
5. 5

• 14
• 29
• 13
• 11
• 11
• ### Forum Statistics

• Total Topics
631775
• Total Posts
3002284
×