• Advertisement

Archived

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

C++ structs vs. variables

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

If you intended to correct an error in the post then please contact us.

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 this post


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

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Why does it matter? What are you making that you would need to worry about this?

Share this post


Link to post
Share on other sites
quote:
Original post by PlayGGY
Why does it matter? What are you making that you would need to worry about this?
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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

Share this post


Link to post
Share on other sites

  • Advertisement