# The dangers of static variables

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

## Recommended Posts

##### Share on other sites
Would the problem you're describing be as important if you had only used this assertation trick in .cpp files?

##### Share on other sites
Quote:
 Original post by TrillianWould the problem you're describing be as important if you had only used this assertation trick in .cpp files?

This is only a problem with static variables in header files. Our new implementation that doesn't cause 20 minute link times looks like this.

    // -- base assert definition    #define Assert_(mask, e, msg) do {                                                                  if(!(e)) {                                                                                          uint32 returnaddr;                                                                       GetRA_(returnaddr);                                                                                  NRadEngine::CJournal::Log msg;                                                                  if(CJournal::ShowAssert(mask, #e, __FILE__, __LINE__, __FUNCTION__,                                                     returnaddr))                                                         { Break_ }                                                                              } } while(0)

I posted this because I've seen a few publications and code bases that use static variables in a header file. It's fairly common.

EDIT: source is missing \ on each line because it messes up formatting in source tags

##### Share on other sites
Quote:
 Original post by David NeubeltThis is only a problem with static variables in header files.

These static variables aren't in header files. The fact that the definition of the macro that defines the static variables appears in a header file doesn't cause the static variables to exist in the header file.

If static variables are the cause of the problem, they would cause it just as well if the macro definition instead appeared directly in each source file. The problem isn't "static variables in header files" but "static variables".

A further nitpick is that "skipassert##__LINE__" won't do what you imply it does, and whilst there are workarounds to make it do what is intended, there is no way that the value of __FILE__ could ever be part of a valid variable name, since __FILE__ is replaced with a string.

##### Share on other sites
Quote:
 Original post by Nathan BaumThese static variables aren't in header files. The fact that the definition of the macro that defines the static variables appears in a header file doesn't cause the static variables to exist in the header file.If static variables are the cause of the problem, they would cause it just as well if the macro definition instead appeared directly in each source file. The problem isn't "static variables in header files" but "static variables".

According to a developer, on Microsoft's linker, I was corresponding with during this ordeal, he told me that the cost would not apply if the assert were not in a header file.

Quote:
 A further nitpick is that "skipassert##__LINE__" won't do what you imply it does, and whilst there are workarounds to make it do what is intended, there is no way that the value of __FILE__ could ever be part of a valid variable name, since __FILE__ is replaced with a string.

We have multiple shipping products on multiple platforms and compilers with that code. I'm pretty sure it works. (EDIT: it doesn't quite work and the code doesn't look like that)

[Edited by - David Neubelt on July 14, 2007 10:10:46 PM]

##### Share on other sites
Quote:
 Original post by David NeubeltAccording to a developer, on Microsoft's linker, I was corresponding with during this ordeal, he told me that the cost would not apply if the assert were not in a header file.

I can get further clarification on why it only applies for header files if you are curious why.

-= Dave

##### Share on other sites
The only way I can see this having any effect on link times is if you were doing the assert in inline functions that were getting used very frequently, in which case the linker would have to resolve those symbols to the same memory location. But as Nathan pointed out, what you have shown wouldn't even compile since __FILE__ is replaced with a string. A lie, it does compile because your variable is literally called "skipassert__LINE____FILE__" because the macros aren't expanded before concatenating the symbol. Ever used this macro twice within the same scope?

Quote:
 Original post by David NeubeltAccording to a developer, on Microsoft's linker, I was corresponding with during this ordeal, he told me that the cost would not apply if the assert were not in a header file.

The linker doesn't even know header files exist, that's what the preprocessor is for.

##### Share on other sites
Quote:
 Original post by joanusdmentiaThe only way I can see this having any effect on link times is if you were doing the assert in inline functions that were getting used very frequently, in which case the linker would have to resolve those symbols to the same memory location.
Yes you are correct - I didn't relay all of the information. The cost only applies when the assert is in a header file and the function containing the assert has multiple instances of the assert.

Quote:
 But as Nathan pointed out, what you have shown wouldn't even compile since __FILE__ is replaced with a string.

Like I said, multiple shipping products, I'm not making this up but since you refuse to believe me then please compile this.
#define MyAssert static bool eAssertSkipped_##__FILE__##__LINE__ = false;int main() {    MyAssert;    return 0;}

-= Dave

[/source]

##### Share on other sites
I corrected my post as you were writing your reply. It compiles, but try using it twice and it won't.

#define MyAssert static bool eAssertSkipped_##__FILE__##__LINE__ = false;int main() {    MyAssert;    MyAssert; // ERROR: eAssertSkipped___FILE____LINE__ already defined    return 0;}

##### Share on other sites
Quote:
 Original post by joanusdmentiaI corrected my post as you were writing your reply. It compiles, but try using it twice and it won't.

Hmm - you're right - I wonder how we got it to work, I need to dig up source history when I get to work and correct the original post.

1. 1
Rutin
29
2. 2
3. 3
4. 4
5. 5

• 13
• 13
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632961
• Total Posts
3009487
• ### Who's Online (See full list)

There are no registered users currently online

×