So are you guys saying that there aren't any actual hazards with globals? If so, that would be great, because this is indeed a one-man project and probably no other person alive will ever be using my code. But I thought I remembered someone talking about "cache-thrashing" in the context of global-usage. Is that something I need to worry about?
Speaking of which, is the 3-4 K of arrays in my class in my game project really something I need to worry about? Maybe I'm just paranoid... Could any computer have a stack so small that this would cause an overflow if I were to use static allocation?
I apologize - I have never really gotten into this sort of low-level hardware memory stuff before and I feel nervous about anything that could be a potential problem with my game.
is bad to use new/delete for huge class?
Unmaintainable code is an actual hazard.
Heavy use of globals means that your code is behaving very non-locally. When you have a large pile of code that is behaving non-locally, it means that any part of your program can cause any other part of your program to break horribly.
In addition, such non-local behaviour also means that your memory access becomes, well, non-local. Accessing memory all over the place can cause your caches to be flushed on you. However, this is not usually what is meant by "globals are bad".
Changing your globals to "allocate a monolithic singleton class, and hide your globals in there", with no other changes to your code other than getting at your variables through that global class, still results in non-localized data flow and memory access. About the only advantage that replacing a pile of global variables with a global singleton is the possibility to create/destroy your global state at a time of your choosing, duplicate it (in case you want to, say, change your code so that there are two engines instead of one), or as a stepping stone to other code redesign steps (encapsulation, refactoring, etc).
To summerize: Globals are bad because they are a symptom of non-locality in code. Non-locality makes code harder to maintain, extend, improve and verify. And yes, it can also cause cache thrashing. Replacing globals with a "global class that holds the globals" has little impact on the non-locality of global-using code.
In general, you should follow "good practices" when writing code to generate clean, readable, O-notation scaling, modular code, and then check to see what makes the code slow. It isn't an exagerration when people say "10% of the code takes up 90% of the execution time". Once you have your program running, you can often easiliy find that 10%, and make it 10 times faster.
Then a different 10% of your code will take up 90% of the time. Repeat.
Heavy use of globals means that your code is behaving very non-locally. When you have a large pile of code that is behaving non-locally, it means that any part of your program can cause any other part of your program to break horribly.
In addition, such non-local behaviour also means that your memory access becomes, well, non-local. Accessing memory all over the place can cause your caches to be flushed on you. However, this is not usually what is meant by "globals are bad".
Changing your globals to "allocate a monolithic singleton class, and hide your globals in there", with no other changes to your code other than getting at your variables through that global class, still results in non-localized data flow and memory access. About the only advantage that replacing a pile of global variables with a global singleton is the possibility to create/destroy your global state at a time of your choosing, duplicate it (in case you want to, say, change your code so that there are two engines instead of one), or as a stepping stone to other code redesign steps (encapsulation, refactoring, etc).
To summerize: Globals are bad because they are a symptom of non-locality in code. Non-locality makes code harder to maintain, extend, improve and verify. And yes, it can also cause cache thrashing. Replacing globals with a "global class that holds the globals" has little impact on the non-locality of global-using code.
In general, you should follow "good practices" when writing code to generate clean, readable, O-notation scaling, modular code, and then check to see what makes the code slow. It isn't an exagerration when people say "10% of the code takes up 90% of the execution time". Once you have your program running, you can often easiliy find that 10%, and make it 10 times faster.
Then a different 10% of your code will take up 90% of the time. Repeat.
It would likely take you 1-2 days to rewrite all the code properly, read in classes, once you understand the concepts (if you don't already). Once you do that you'll have much easier to maintain and modify code. Otherwise, you'll run into the same problems most newer programmers hit... the 8000 lines of code and stuck on how to put in some new cool features.
Best of luck with it all.
Best of luck with it all.
I suggest taking a course in object oriented programming, or object oriented analysis and design.[cool]
What you have written is not how to program with C++.
btw, I'm serious.
What you have written is not how to program with C++.
btw, I'm serious.
Author
I guess you guys are right. I do seem to catch a lot of flak for this around here :) OO principles don't come naturally to me - if I try to use them I always seem to want to find ways to nullify them (like by giving classes pointers to eachother and stuff like that.) I can handle dealing with terribly-written code; I've been doing it for a long time now. All I am really concerned about is that my game does not error out on another computer.
But I really want to figure out this stack problem for good. Is there anything dangerous about creating a 3-4 kB object non-dynamically? How big can I safely make static-allocated objects? Will the stack contain the entire contents of my object during the entire life of my program, or only during construction of the object? And does an object take up more space on the stack if it has a lot of methods?
Thanks!
But I really want to figure out this stack problem for good. Is there anything dangerous about creating a 3-4 kB object non-dynamically? How big can I safely make static-allocated objects? Will the stack contain the entire contents of my object during the entire life of my program, or only during construction of the object? And does an object take up more space on the stack if it has a lot of methods?
Thanks!
It's not object oriented in any way, so the class doesn't do anything for you.
As for procedural code, it's fine. It's not that much code.
The only big problem with it right now is the static arrays.
TRI tris[TRIS_SIZE];
SYNTH_POINT pnts[POINTS_SIZE];
MM_POLYGON polys[MAX_POLYGONS];
MM_CIRCLE circles[MAX_CIRCLES];
Those should be dynamically allocated (see std::vector).
As for procedural code, it's fine. It's not that much code.
The only big problem with it right now is the static arrays.
TRI tris[TRIS_SIZE];
SYNTH_POINT pnts[POINTS_SIZE];
MM_POLYGON polys[MAX_POLYGONS];
MM_CIRCLE circles[MAX_CIRCLES];
Those should be dynamically allocated (see std::vector).
Quote:Original post by synth_cat
I guess you guys are right. I do seem to catch a lot of flak for this around here :) OO principles don't come naturally to me - if I try to use them I always seem to want to find ways to nullify them (like by giving classes pointers to eachother and stuff like that.) I can handle dealing with terribly-written code; I've been doing it for a long time now. All I am really concerned about is that my game does not error out on another computer.
Forget the "principles" you think you know. Start with the idea of *modelling* things, and then start learning from scratch. But basically, the goal is to provide a simple interface and code to it. Oh, and learn to believe abstractions.
Quote:But I really want to figure out this stack problem for good. Is there anything dangerous about creating a 3-4 kB object non-dynamically? How big can I safely make static-allocated objects?
The stack is typically about 1MB total. You do need to share, and you do need to remember that things passed by value will be re-copied on the stack. For each level of function calling (beware recursion) you should expect at least 4 bytes * (1 + number of parameters): for each parameter, either a primitive or a reference (because you should be passing big things by reference, possibly const reference), and for the return address.
Quote:Will the stack contain the entire contents of my object during the entire life of my program, or only during construction of the object?
It will contain everything that is physically part of your object, for the object's lifetime: i.e. until the end of the scope in which it is declared. You should probably do some research into how the stack works; [google] is probably not too bad for this if you toss in some other C / C++ jargon.
Note that things that are logically but not physically part of your object (for example, a dynamic allocation managed by the class) will typically not be on the stack.
Quote:And does an object take up more space on the stack if it has a lot of methods?
Basically, no. Ordinary (non-virtual) member functions are basically syntactic sugar for free functions. Even virtual member functions, in typical implementations (the standard says very little, but in practice, everyone does more or less the same thing) don't cost per-object, just per-class - and the relevant "vtable" stuff is not on the stack.
The object size *is* increased by the size of one pointer per polymorphic base (i.e. base class which defines at least one virtual function). See here.
Author
About the std::vector for dynamicly-allocated arrays . . . I only need to worry about this for arrays over, say, 100 Kb, right? Would it be necessary for an array of only 4 kb? Otherwise, I would prefer to create arrays the simple way, like in the coe I have shown. It does not matter to me so much if my arrays are inflexible (I have been brought up to think of them thatr way, after all.) - I just want them to not cause any problems like the stack overflow.
Could you please show me a small snippet showing how I would use std::vector to create my large arrays? (This is something I do not remember ever seeing in code before.)
By the way, my thanks for all the help so far!
-synth_cat
Could you please show me a small snippet showing how I would use std::vector to create my large arrays? (This is something I do not remember ever seeing in code before.)
By the way, my thanks for all the help so far!
-synth_cat
Quote:Original post by synth_cat
Could you please show me a small snippet showing how I would use std::vector to create my large arrays? (This is something I do not remember ever seeing in code before.)
-synth_cat
This line:
TRI tris[TRIS_SIZE];
becomes this:
#include <vector> //put it at the top
std::vector<TRI> tris; //put this in the class declaration
tris.resize(TRIS_SIZE); //put this into the constructor
EDIT: That's an example of "static" usage of vectors, very similar to what you have been doing with static arrays. I call it "static" because the resize() operation allocates enough memory for you and after that you probably don't need to resize the vector. Vectors can be used dynamically as well, just get rid of the resize() operation and use vector.push_back() to insert the elements. Here is the doc.
Author
Well, thanks for that explanation, deathkrush!
So, I'm curious: If I were to only use resize() to create this array, without any of the dynamic stuff ever being used, what would be the exact advantages over just saying "TRI tris[TRIS_SIZE]?" I ask this because I do not intend to resize my arrays during execution; there are various design reasons why this would be problematic.
Is the syntax for accessing a data element of a vector the same as for an array? For example, would this work?
I know I keep asking this question, but can someone tell me at what point it becomes requisite to use these special array-creation methods? Or should I just use vectors for all the arrays I ever make, just to be safe?
So, I'm curious: If I were to only use resize() to create this array, without any of the dynamic stuff ever being used, what would be the exact advantages over just saying "TRI tris[TRIS_SIZE]?" I ask this because I do not intend to resize my arrays during execution; there are various design reasons why this would be problematic.
Is the syntax for accessing a data element of a vector the same as for an array? For example, would this work?
using namespace stdvector<TRI> tris; tris.resize(TRIS_SIZE);tris[TRIS_SIZE-1].some_member=200; I know I keep asking this question, but can someone tell me at what point it becomes requisite to use these special array-creation methods? Or should I just use vectors for all the arrays I ever make, just to be safe?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
