Local Player Corpse

[Cypher]

ho, sorry, my bad english, i misunderstood static object with static variables

like :

bad:

void myFunction( float rox_value )
{
    static float ugly_var;
}

good:

class CRox
{
private:
   static CRox* m_instance;
public:
   CRox* GetInstance() { return m_instance;}
}
CRox* CRox::m_instance = 0;

Of course static class member is nice for singleton, factory class etc.

Static local variables are also useful in many situations.

Poor example:

void SomeSub()
{
static bool First = true;
if (First)
{
// do some once-only stuff
First = false;
}

// Do regular stuff
}

Another example:

void SomeSub()
{
unsigned int TimesCalled = 0;
++TimesCalled;
// do shit here
std::cout << "SomeSub has been called " << TimesCalled << " times!" << std::endl;
}

There is nothing inherently 'ugly' about static variables except for the fact they're not really thread-safe. Global variables are ugly yes, but static variables are highly useful in a large number of situations.

[arthas dominion]

hmm i am only complimenting cause i wana post

[sebdoingbot]

hi,

@Cypher.

Really, imo, there is always better ways than static variable.

Initialisation ? Use a class member static bool b_Initialised.

Counting ( Profiling issue i think ), i code a Profling class.

I only use static variable for ugly debuging wip code.

Maybe we should modify this thread to,

Static variable, good or bad ?



cheers,

Seb

[Cypher]

hi,

@Cypher.

Really, imo, there is always better ways than static variable.

Initialisation ? Use a class member static bool b_Initialised.

Counting ( Profiling issue i think ), i code a Profling class.

I only use static variable for ugly debuging wip code.

Maybe we should modify this thread to,

Static variable, good or bad ?



cheers,

Seb

"Initialisation ? Use a class member static bool b_Initialised."

There's ZERO difference between a static local variable and static class member. I don't get what you think the difference is but there isn't one. Objects have the exact same rules and are initialized in exactly the same way.

Also, all you've done is relocate the static data in all your examples, rather than solve the problem.

Also, modify what thread? Global and static data is not thread-safe. If you want to use static/global data safely from multiple threads (INCLUDING STATIC CLASS MEMBERS) you need to wrap them in a critical section or similar. This is of course assuming your class is complex enough that asynchronous access would cause race conditions.

Please explain why local static variables are 'ugly'. Because all you've done so far is say that rather than the static data being a function local variable you should wrap it in some class. You haven't actually achieved anything at that point other than moving the location of the variable.

EDIT: Also wanted to point out that the static keyword can be used to signify that a variable is local to a translation unit. Although this is a deprecated feature it is still used in production code. (The correct alternative is to use unnamed namespaces)

EDIT2: Just remembered another advantage. LOCAL static objects are created the first time the declaration is encountered, so if you never call the function the local static object is never constructed. On the other hand, CLASS static objects (along with global or namespace scope objects) are constructed upon execution of the application, which means you suffer the costs of construction even if you don't use the object. When developing a library where not all feature are going to be used by every client local static objects clearly win in terms of performance.

[shomoiog]

At the beginning of C++ a lot of part time expert programmers started to write articles and books on the new coding style. Static "C" variables where considered "ugly" in the "c with classes" for one main reason: names conflict hell. Most authors picking up the trend forgot to mention that using static members instead of old c style static variables/functions is "better" mainly for name decoration. I assume the pure oo languages emerging (especially java at the time) had something to do with the new "cool" coding style. Let's face it, 99% of the static members are either public or using pointless access wrappers, so the other theoretical motivation (encapsulation/access control) is not really an issue.

Most people learning at the time (and teaching other generations since then) either don't know or don't mention why is "ugly" to use c style static variables and why is "better" to add them as members. Of course now we have namespaces, but it was a time when naming was an art so that you don't conflict with other libraries. Not to mention that there are still a lot of c++ books that don't advocate enough the use of namespaces, or old school coders that don't "dig" them.

And by "thread" our french friend means this forum thread, not an execution thread. I hope this clears up a bit why he used the term "ugly". But all your points are valid Cypher, in the end is just a naming convention, other than access control, the result is the same (excluding local static objects).

[Cypher]

At the beginning of C++ a lot of part time expert programmers started to write articles and books on the new coding style. Static "C" variables where considered "ugly" in the "c with classes" for one main reason: names conflict hell. Most authors picking up the trend forgot to mention that using static members instead of old c style static variables/functions is "better" mainly for name decoration. I assume the pure oo languages emerging (especially java at the time) had something to do with the new "cool" coding style. Let's face it, 99% of the static members are either public or using pointless access wrappers, so the other theoretical motivation (encapsulation/access control) is not really an issue.

Most people learning at the time (and teaching other generations since then) either don't know or don't mention why is "ugly" to use c style static variables and why is "better" to add them as members. Of course now we have namespaces, but it was a time when naming was an art so that you don't conflict with other libraries. Not to mention that there are still a lot of c++ books that don't advocate enough the use of namespaces, or old school coders that don't "dig" them.

And by "thread" our french friend means this forum thread, not an execution thread. I hope this clears up a bit why he used the term "ugly". But all your points are valid Cypher, in the end is just a naming convention, other than access control, the result is the same (excluding local static objects).

Pointless access wrappers? I'd hardly call the singleton pattern pointless but okay.

Also, by 'name conflict hell' you're referring to the deprecated feature I outlined in which static global objects are local to a translation unit. Function-local static objects on the other hand have nothing to do with said "name conflict hell".

Its far from just a naming convention though and the way in which the keyword affects how objects are accessed, constructed, and destructed is quite important.

P.S. How do you say 'execution thread' in french?

[shomoiog]

Comparing singletons with access wrappers is comparing apples with kiwis. I was talking about the difference between static members and old C style static, not usage of the static concept. What connection do YOU see between "access wrappers" and the "singleton pattern"?

Name conflicting hell is the linker inability to distinct between two items with the same (nondecorated) name (ie: non-member functions GetInstance() in file class1.cpp and the GetInstance in class2.cpp). The "static local" construct limits the visibility to the current cimpiler unit (file) as you pointed out, same effect as a nameless namespace, but that's a special case, and has no connection with static objects/functions. Again, I wasn't talking about this.

The local static objects are a different issue. Check the last few words in my previous post, I do exclude them from the discussion as a special case.

There are a lot of libraries out there written based on ancient c++ standards and practices, either because they need to preserve an old existing style (mfc for instance) or because the compiler targeted is based on a 20 years old c++ standard (microcontolers compilers). The modern c++ standard and implicit the coding style is a lot different from the c++ 20 years ago. There are people stuck in the stoneage of c++. There are c++ compilers out there that don't even provide the std library, not to mention namespaces support. In that c++ stone age appeared the concept that's ugly to use c style static definitions and it's not to use static members. There are people stuck in that stone age (think about a guy using what he calls "c++" to write microcontroler code for your dvd player).

I was just trying to explain why he used the term "ugly" for c style statics, how on earth you managed to get the "singleton concept", "how objects are accessed, constructed and destructed" into this is beyond me. To go with the your style I could say too "but to drink plenty of beer is extremely important".

[Cypher]

The fact you're confused probably stems the fact you don't actually understand all the uses of the 'static' keyword and their implications/consequences.

The singleton pattern requires the use of static member functions and a static instance of the object in order to work. The singleton pattern is designed to restrict the usage of a class to a single instance, hence the term "singleton". ie Single.

This is how it is typically implemented:

class MyClass
{
protected:
MyClass();
~MyClass();
MyClass(const MyClass&);
MyClass& operator= (const MyClass&);
private:
static MyClass* m_pMyClass;
public:
static MyClass* Get()
{
if (!m_pMyClass)
m_pMyClass = new MyClass();
return m_pMyClass;
}
}

MyClass* MyClass::m_pMyClass = 0;

Now. For this example I've used a pointer. The reason I've done this is because of the aforementioned implications of the static keyword. Class members marked as 'static' are constructed upon the program's execution. That means if I had created the object 'statically' (for lack of a better phrase -- i mean as opposed to 'dynamically', ie using 'new' as I have in the example) that even if the class was never used then the library users would suffer from the cost of a construction. By using a pointer I'm only effectively forcing the users to initialize a long/int at runtime, a much smaller cost.

But, the static keyword has more implications. For example in the following code the situation is totally different:

MyClass& MySub()
{
static MyClass m_MyClass;
return MyClass;
}

What's interesting about this is that despite the object being created 'statically' (again, as opposed to using 'new') the cost of initialization is only paid if someone actually calls the function. This is totally different to static class members.

But wait, there are MORE surprises. The static keyword has another intricacy.

#include "MyClass.h"

static MyClass gMyClass;

In this example, despite being global, 'gMyClass' is only visible in the translation unit in which it's declared. I could if I want reuse that name for a totally different object in a different translation unit. Please note, the use of this 'feature' is highly discouraged and marked as deprecated in the C++ Standard. It is allowed only to maintain backwards compatibility with C. And oh, naturally this object is created upon execution of the program like static class members (but unlike local static objects).

As you can see there are a lot of details you seem to not be aware of. The singleton pattern and when and how objects are created is quite relevant when you really get into the intricacies of the keyword.

If you're looking for more information I suggest 'The C++ Programming Language' by Stroustrup, or the 'Effective C++' books by Meyers. Both delve into differing amounts of detail on different implications of the keyword.

Obviously most developers need not be aware of the details, let alone care about them. This is the type of stuff compiler writers, library creators, etc are interested in. But me? I just find stuff like this fascinating.

[shomoiog]

[COLOR=Lime]The fact you're confused probably stems the fact you don't actually understand all the uses of the 'static' keyword and their implications/consequences.

I am not confused, not by far. I am fully aware of what static keyword is used for. This thread start on one simple issue:

ClassX instance; // c style global

and

ClassX ClassX::m_Instance; // c++ static member

The first was called "ugly" compared to the second. I clearly ruled out the rest of the static keyword usage in my first post, and referred to this one specific situation which the topic was about, if you actually take the time to read it, you will notice.

Adding the rest of the static keyword implications into the topic for the sake of arguing or showing off your knowledge of the static keyword has the same relevance as throwing into the discussion the concept "static ip address". I could write up two pages two blabbering about the difference between static ip address and dhcp allocated one, and call you "ignorant" and "confused". But would be pointless. That's exactly what you did listing up the static keyword usage options.

By the way, static keyword usage for scope control is C, not C++, that's why is considered "deprecated" in C++. Looks like you're the one that's confused. To sum up all your examples, is very simple, and maybe this will actually help you too and others to understand: all static variables have memory reserved on data segment (as opposed to heap/stack). This includes global static and local static. Global variables (are also static by definition) are initialized before main is executed (this implies constructors calls if we're talking about objects) and destructed after main ends. Local static are different in terms that are initialized the first time are encountered in code execution (using local static instead of globals doesn't do anything else but delay initialization until first time actually used, and of course, limit the visibility due to block visibility rules in both c and c++). But the memory is STILL reserved at link time. Oh ye, you also seem very confused about the difference between compiler and linker. No space allocation/reservation happens at compile time EVER in any c/c++ compiler, but is done during link time for static variables. By the way, obviously you had no clue that you can actually define static variables in libraries too? WHat's even more cooler, in dll's initialization (again, including constructor calls) happen before even dll main is called for gobals!

Frankly globals/local static init time, as well as the new word you learned this week, "singleton" is one of the very basic issues in the c++ language (and any other oop language for that mater), I don't get why would you fill up pages to show off basic knowledge, or why do you consider it "top skillz" that no one else but you can have it. Even the french guy knows what he's talking about, and fully understand the keyword "static" in all his usage scenarios, he just pointed out that c globals are "ugly", but doesnt know enough english to go into flaming fun tho :P

See? Isn't this annoying? I just repeated what you said, in a different format, or added new things that were never brought up, added a few "you're confused", "I am so cool, you're such a clueless idiot" , "of course you didn't knew *that*", here and there between the lines, and voila, click submit! I will be away for a few days, so unfortunately you win this little friendly flaming war by forfeit, was fun tho

[SKU]

I was just about to grab popcorn, damn you!

[Cypher]

I am not confused, not by far. I am fully aware of what static keyword is used for. This thread start on one simple issue:

ClassX instance; // c style global

and

ClassX ClassX::m_Instance; // c++ static member

The first was called "ugly" compared to the second. I clearly ruled out the rest of the static keyword usage in my first post, and referred to this one specific situation which the topic was about, if you actually take the time to read it, you will notice.

Adding the rest of the static keyword implications into the topic for the sake of arguing or showing off your knowledge of the static keyword has the same relevance as throwing into the discussion the concept "static ip address". I could write up two pages two blabbering about the difference between static ip address and dhcp allocated one, and call you "ignorant" and "confused". But would be pointless. That's exactly what you did listing up the static keyword usage options.

By the way, static keyword usage for scope control is C, not C++, that's why is considered "deprecated" in C++. Looks like you're the one that's confused. To sum up all your examples, is very simple, and maybe this will actually help you too and others to understand: all static variables have memory reserved on data segment (as opposed to heap/stack). This includes global static and local static. Global variables (are also static by definition) are initialized before main is executed (this implies constructors calls if we're talking about objects) and destructed after main ends. Local static are different in terms that are initialized the first time are encountered in code execution (using local static instead of globals doesn't do anything else but delay initialization until first time actually used, and of course, limit the visibility due to block visibility rules in both c and c++). But the memory is STILL reserved at link time. Oh ye, you also seem very confused about the difference between compiler and linker. No space allocation/reservation happens at compile time EVER in any c/c++ compiler, but is done during link time for static variables. By the way, obviously you had no clue that you can actually define static variables in libraries too? WHat's even more cooler, in dll's initialization (again, including constructor calls) happen before even dll main is called for gobals!

Frankly globals/local static init time, as well as the new word you learned this week, "singleton" is one of the very basic issues in the c++ language (and any other oop language for that mater), I don't get why would you fill up pages to show off basic knowledge, or why do you consider it "top skillz" that no one else but you can have it. Even the french guy knows what he's talking about, and fully understand the keyword "static" in all his usage scenarios, he just pointed out that c globals are "ugly", but doesnt know enough english to go into flaming fun tho :P

See? Isn't this annoying? I just repeated what you said, in a different format, or added new things that were never brought up, added a few "you're confused", "I am so cool, you're such a clueless idiot" , "of course you didn't knew *that*", here and there between the lines, and voila, click submit! I will be away for a few days, so unfortunately you win this little friendly flaming war by forfeit, was fun tho

Do you need help reading? Because it seems you're still having trouble parsing basic English sentences.

1. The entire friggin discussion was about the use of static objects and the french guy saying local static objects were 'ugly'. I suggest you backtrack a bit and have a reread. I'm sorry if you decided to insert yourself in the middle and ninja-topic-change but that's your own stupid fault.
2. You do realize there's a difference between reserving memory and constructing an object right? I never said memory was never reserved, I said you potentially save the cost of a construction.
3. I added the usage of the keyword because you kept going off on crazy tangents, talking about crap that wasn't relevant to what we were talking about to begin with (Whether local static objects are considered 'ugly'). I was simply trying to pull things back and point out that although some static objects are 'ugly' there are good uses for it, something our french friend wasn't clear on.
4. I didn't fill up pages, nor call it 'top skillz'. Nor did I say "I'm so cool, you're a clueless idiot". You STILL seem to be having trouble reading. I don't know if its because you're still confused (you obviously are) or if you're just purposefully jumping around to dodge the fact you've totally derailed the conversation by attempting to insert yourself in and change the topic (the french guy and I were talking about local-static objects then you pop in and start talking about something different entirely. Not only do you use ambiguous terminology then turn around and snap at me for misunderstanding what you're saying (we were talking about static objects and legitimate uses, you use the term "pointless access wrapper" -- because encapsulation is stupid, amirite?).
5. Then you continue to derail the topic by saying you weren't using "pointless access wrappers" to refer to singletons. (Then what WERE you referring to?) And also talking about "naming hell" in a context that is totally irrelevant to the discussion, you even point out yourself it has nothing to do with static objects (then why did you even post?? its confusing to insert something ambiguous into a discussion then just talk about the totally irrelevant interpretation).
YOU were the one who derailed the thread by talking about totally irrelevant stuff. What was the point of inserting yourself into the conversation?
6. Still having trouble with English? I never said space for objects is reserved at compile-time, and if I did then it would probably be fairly obvious (given the fact I was talking about the .data segment etc) that I was using "compile-time" to refer to the more general case where the binary is produced. Noone says "I'm going to go compile, link, and create a file on disk for my application", they just say, "I'm going to go compile my application". Its basic English skills, and probably where some of your confusion stems.
7. Either you're a terrible troll or a huge idiot so I'm just gonna leave you be. It's obvious that in any case you're extremely confused. I suggest in future you reread the post you're replying to at LEAST 5 times, because any less than that and you just make zero sense in terms of the relevance of your replies.

[schlumpf]

ok let me put it this way:

Stand up, spread your arms in front of you. That's facing.
Lay down, spread your arms in front of you. That's pitch.

See the resemblance?

i like you. Can we be friends?

. . .

[Cypher]

. . .

[shomoiog]

1. the french guy refered to c style globals as "ugly" not all static. He even added a static member as example of the "right way" of doing things. scroll up. Let me know if you need help understanding the difference.

2. I assume you are a high school kid that never had a job in the field and who's only reference is his programming class where "advanced knowledge" is bubble sort. I seriously advise you to go to an interview and start explaining how knowing the programming language keywords, variables scope and life time represents "extreme advanced knowledge that only people that write compilers" and you know, and everyone else is "confused" or "doesn't have a clue" about such "advanced" topics. I would love to see the examiner reaction.

You really have to get out the assumption that everyone you encounter fits into the "omgz I know html, I wanna write a bot" type. Congratulation for the level of knowledge you achieved, I assume most if not all of it is self thought. It is impressive. However, it seems that's an amalgam between what's basic and what's not. You also seem unable to differentiate between theoretical concepts and particular implementations of those theoretical concepts.

I might be a troll, but again, so are you. At least I don't delude myself into thinking that I am posting only relevant info.

[sebdoingbot]

Hi guys,
I'll never post again

Or maybe i'll do.. was quite .. fun ..err...intersting to read

Cypher, i think you forgot one fundamental fact, i'm french, this mean my english sucks, and i may write/read thing wrong because i didn't read/write english correctly, instead of my bad coding knowledge

sincere regards,

Seb