• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

static initializers in c

19 posts in this topic

if i will wrote

 

int x = init();

 

in the static space this function init() will call even before the winmian

is called

 

I am writing c programs but compile it with c++ mode.. strange i never

used this kind of initialisers I was unaware of this.. (i think it may be handy though also maybe can bring some trouble, you must scan all the source to check what is called first etc)

 

1) I wonder is this a part of c standard as well or this is only c++ (and will not work in c)?

2) what with an order of calling this if i got more this than one (can i assume something on this order of calling or control order of it?)

3) is this generally encouraged way of writing in c (has it some downsides or pitfals?)

Edited by fir
0

Share this post


Link to post
Share on other sites

 


1) I wonder is this a part of c standard as well or this is only c++ (and will not work in c)?

C++ inherited it from C.  It predates the standards and is a fundamental part of the language(s).

 

 

2) what with an order of calling this if i got more this than one (can i assume something on this order of calling or control order of it?)

Static initialization is always performed in lexical order within a translation unit.  The order in which static initialization is performed between translation units is undefined (and will change from build to build).

 

3) is this generally encouraged way of writing in c (has it some downsides or pitfals?)

I would generally discourage the use of global (C) or namespace-level (C++) variables.  No, really.  They effectively preclude the use of threading or unit testing and they cause maintainers to swear like sailors at the free clinic.

 

Also, because sequencing between translation units is undefined and arbitrary, it often causes unexpected trouble.

 

 

TNx for answer.

You sure this is in c? does you know in each of version of this

in the old 89 too? (strangle how long i was unaware of that if this is in c)

As to order between modules (.o files i link in mingw) isnt it maybe

dependant on command line order of this files passed tolinker..?

0

Share this post


Link to post
Share on other sites

 

As to order between modules (.o files i link in mingw) isnt it maybe

dependant on command line order of this files passed tolinker..?

 

 

It might be, but there is no standard so you can't depend on it. Might be now, then change when you update the compiler for example. That's the problem with relying on undefined behaviour.

0

Share this post


Link to post
Share on other sites

As to order between modules (.o files i link in mingw) isnt it maybe
dependant on command line order of this files passed tolinker..?

 
It might be, but there is no standard so you can't depend on it. Might be now, then change when you update the compiler for example. That's the problem with relying on undefined behaviour.


The order is unspecified. "Undefined" means something else. Edited by Álvaro
0

Share this post


Link to post
Share on other sites

 

 

As to order between modules (.o files i link in mingw) isnt it maybe

dependant on command line order of this files passed tolinker..?

 

 

It might be, but there is no standard so you can't depend on it. Might be now, then change when you update the compiler for example. That's the problem with relying on undefined behaviour.

 

Well if i will build this once and for all it probably will not change at

runtime - so the formula of this order for mingw would be welcome -

does anybody maybe know?

(though i know it then it is limited to some environment only)

-2

Share this post


Link to post
Share on other sites
You really should heed the advice you have been given.

Another piece of advice: You should avoid global variables in general, and then this problem doesn't even exist. If you do use global variables for something, initialize them explicitly.

For instance, the `main' function in my C++ chess program starts with some initializations. The exact code looks like this (comments added for you):
 
int main() {
  // This is a hook so I can do any platform-specific initializations
  platform_initialize();
  
  // The pseudo-random number generator is an example of global state
  std::srand(std::fmod(now(), 1.0)*1000000);
  
  // Precompute some lookup tables
  initialize_magics();
  initialize_square_piece_tables();
  initialize_material_hash_table();
  
  // ...
}
Edited by Álvaro
2

Share this post


Link to post
Share on other sites

Well I chceked it 

 

 c:\mingw\bin\gcc main.c -std=c99 

 

and it does not compile, so maybe this is

not in c, though?

0

Share this post


Link to post
Share on other sites

You really should heed the advice you have been given.
 

 

many people give me advices with wich i generally agree (though i also

know 90%  of this advices so it is a bit strange to read advices i know of)

I am asking on some things often not because i want to do this but just to know how it works

0

Share this post


Link to post
Share on other sites

It certainly exists in both.
 
C89:

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.

C99:

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.

The ordering requirement existed even back in the K&R book from 1978. I don't know if it was specified in the earlier compilers, but even if the ordering wasn't specified (in order within the file, each file in unspecified order) since that is the easiest way to process it that is the likely behavior.

Now with that in mind, just because you can doesn't mean you should. **DON'T RELY ON STATIC INITIALIZATION**. I have seen actual shipped games where the static initialization took over ten seconds. We wanted to beat the previous team owners into oblivion when we did the port. The previous team masked it by mandatory splash screens.

 

 

Well I chceked it 

 c:\mingw\bin\gcc main.c -std=c99 

and it does not compile, so maybe this is not in c, though?

Post your exact error message and the relevant lines and surrounding code indicated by the actual error messages. The concept of static initialization is probably not the bug.

main.c :
 
int init() {}
int x = init();
int main() {return 0;}
 
 
>c:\mingw\bin\gcc main.c -std=c99
main.c:2: initializer element is not constant
 
ps.  maybe i gave it a bad name "static initializers" but i didnt know how to name such static (global) space initialization thing like "int x = init();" so i called it here "static initializers" (maybe "static space initializers" would be better here
Edited by fir
0

Share this post


Link to post
Share on other sites

 

 

As to order between modules (.o files i link in mingw) isnt it maybe
dependant on command line order of this files passed tolinker..?

 
It might be, but there is no standard so you can't depend on it. Might be now, then change when you update the compiler for example. That's the problem with relying on undefined behaviour.

 


The order is unspecified. "Undefined" means something else.

 

 

Sure you are correct but out of curiosity, what is the difference?

0

Share this post


Link to post
Share on other sites

If global variables are initialized in an unspecified order, they will be initialized, you just don't know in what order. If you write a program that invokes undefined behavior, all bets are off: You can't predict what will happen at all.

 

Here's a good description of undefined behavior: http://blog.regehr.org/archives/213

2

Share this post


Link to post
Share on other sites

 

Sure you are correct but out of curiosity, what is the difference?


Undefined, unspecified and implementation-defined behavior

 

 

3.4.4 1 unspecified behavior use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

 

How is the order of statics across translation units unspecified then? Does the standard provide one or more standard orders? I thought it was undefined across different translation units.

 

[EDIT] Actually after reading that link's definition of "undefined" I guess it does make some sense. I always thought "undefined" was anything that was not specified by the standard but if "undefined" requires non-portable or erroneous data or program constructs, "unspecified" I guess covers everything else that is undefined but not erroneous. I suppose "undefined" is where even the compiler makes no guarantee of what will happen, regardless of standard and "unspecified" is where the compiler is doing something predictable and deterministic but not something the standard enforces.

Edited by Aardvajk
0

Share this post


Link to post
Share on other sites
Yeah, undefined behavior means your code is not C++, as defined by the C++ standard.

Undefined behavior has also been called "catch fire semantics" to underscore the fact that anything can happen, even your computer going ablaze, when undefined behavior is invoked. Edited by King Mir
0

Share this post


Link to post
Share on other sites

How is the order of statics across translation units unspecified then? Does the standard provide one or more standard orders?


Yes, the standard does provide one or more possible orderings. The options available to the implementation are all of the ordering permutations of the translation units. Initializing all the statics of A.obj before B.obj is just as valid as doing B.obj before A.obj. The standard guarantees that they're all linked together and their statics will be initialized in some order. How that order is determined is not specified by the standard and each implementation is free to order them however it wants, even differently between successive runs.

If the implementation were expected to order TU initialization in a self-consistent manner then the behavior would be implementation-defined instead of unspecified. This is not a requirement the standard wanted to place on implementations. The implementation may not even be in control of the choice such as in a multi-threaded linker (so the statics initialized first are dependent on whichever translation unit's worker thread happened to be scheduled by the OS to run first). If the standard wanted to place restrictions on the implementation so that you the user could predict the initialization order on every conforming implementation (even if it differed between implementations), the standard would have made this behavior implementation-defined and whole classes of possible compilation optimizations would be illegal.

If the behavior were undefined behavior then that would mean that the TUs' static objects may be initialized in some order clearly documented by the implementation, or the implementation can elect to initialize only some of them and not document how it makes that choice, or all of them may be left uninitialized, or they all might be initialized to the same value as one of them, or the implementation may raise an error and abort upon seeing any static initializations, or the implementation could happily generate code that causes a CPU exception. Every implementation could do something different and none of them would be considered buggy in terms of standards compliance. Undefined behavior has a beneficial purpose in places but certainly not for static initialization ordering. Edited by SeanMiddleditch
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0