Static is evil, supposedly

Started by
15 comments, last by Oberon_Command 11 years, 9 months ago
why not have that as part of your current sector's information?[/quote]
because their is 5626 sector in RAM at all time, this would only add 5.626MB but I'm trying to reduce memory usage, every pieces count.


from what I read using statics the way I do it is "ok" since they are all defined as final, and thus never changing
.

public class Global {
//Sector size
public static final int CHUNK_Z = 16;
public static final int CHUNK_HEIGHT = 256;
public static final int CHUNK_X = 16;
//nb de display list par chunk
public static final int DL_Y = 16;
//windows parameter
public static final int WINDOW_HEIGHT = 480;
public static final int WINDOW_WIDTH = 640;
public static final int WINDOW_BITPERPIX = 32;
//paths
public static final String ROOT_DIRECTORIE = "C:\\MEngCl\\";
public static final String TEXTURES_PATH = ROOT_DIRECTORIE+"Textures\\";
public static final String WORLD_PATH = ROOT_DIRECTORIE+"World\\";
//display area
public static final short DISPLAY_AREA = 30;
}


thanks for your awnsers ;)
Advertisement
http://gbracha.blogspot.com/2008/02/cutting-out-static.html

Some relevant info, though mostly I agree with Frob's first answer.
I've accidently this blog post and I think its awesome because it explains [static] Singletons, why they're considered evil and how to use them properly.

I've accidently this blog post and I think its awesome because it explains [static] Singletons, why they're considered evil and how to use them properly.


Shared state is shared state, even if it's private and scoped to a single class.

why not have that as part of your current sector's information?

because their is 5626 sector in RAM at all time, this would only add 5.626MB but I'm trying to reduce memory usage, every pieces count.


from what I read using statics the way I do it is "ok" since they are all defined as final, and thus never changing
.

public class Global {
//Sector size
public static final int CHUNK_Z = 16;
public static final int CHUNK_HEIGHT = 256;
public static final int CHUNK_X = 16;
//nb de display list par chunk
public static final int DL_Y = 16;
//windows parameter
public static final int WINDOW_HEIGHT = 480;
public static final int WINDOW_WIDTH = 640;
public static final int WINDOW_BITPERPIX = 32;
//paths
public static final String ROOT_DIRECTORIE = "C:\\MEngCl\\";
public static final String TEXTURES_PATH = ROOT_DIRECTORIE+"Textures\\";
public static final String WORLD_PATH = ROOT_DIRECTORIE+"World\\";
//display area
public static final short DISPLAY_AREA = 30;
}


thanks for your awnsers ;)
[/quote]
I would agree that this use of static is ok, given the..... static nature of the data. I wouldn't complain about it. I couldn't see frob or telastyn really having a problem with it either.

Beginner in Game Development?  Read here. And read here.

 

Nope. Constants aren't mutable state so are fine to share.
I would agree with Telastyn that shared state in the form of mutable static variables is best avoided unless it really makes sense to do things this way. On the other hand, I would advocate the use of static functions (that is, static behaviour as opposed to static state) wherever appropriate, especially with helper functions. If a method doesn't actually need anything that you need to access through the "this" pointer of the class in which the method resides, then you should make it a static method (or free function, if you were using C++, which it seems you aren't) until it does. The "this" pointer is an implicit dependency - making your method an instance method basically states, "I need an instance of this class in order to function correctly." If that statement does not apply to your method, then it should be static. Don't add dependencies to your code unless it's really needed. Of course, if you really need to access instance variables later on, then you should use the method with that in mind. Throwing around a static method in code that's unlikely to ever see an instance of its owner class opens you up to the same kinds of problems that singletons have, most importantly that doing this will increase the amount of interdependencies in your program.

This topic is closed to new replies.

Advertisement