Static

[nabz32]

If you are doing object oriented coding in C++ globals are the devil,
they can easily be avoided.

When you declare a static each instance of your object ( or function ) will use
the same memory address for this static.

I would only recommend using statics inside types,
In types it can be very usefull to keep track of how many instances you have generated from this type,
increase it in the constructor, decrease it in the deconstructor.

If you really want to eliminate all GLOBALs in your code, you need strict discipline and a good sketch of your types before.

@Hemlos:
In C++ a memory space is generated for a STATIC, when you create the first instance of the object class or declare it the first time.
It is possible to declare it before you even have created an instance of the object.
Like in GLBasic each instance of a class shares the same memory area for the static variable.
PRIVATE means you can´t access the data directly when working with an instance of the class.

iE. instead of using today.day = x ; today.month = x ; today.year = x ( or today->day etc. )
it is far better to make those variables PRIVATE and declare an overloaded constructor ( today = new Date(10,8,2000) ) for the class.
So that you can build a check inside the constructor that keeps the date from beeing set to some invalid values.

It is all a thing of enabling users to work better as a team ( failproof shairing of libraries )

@kanonet
Yes you can read out everything in the RAM with the right tools,
there is no doubt about it.

[Hemlos]

If you really want to eliminate all GLOBALs in your code, you need strict discipline and a good sketch of your types before.

Indeed!

@Hemlos:
In C++ a memory space is generated for a STATIC, when you create the first instance of the object class or declare it the first time.
It is possible to declare it before you even have created an instance of the object.
Like in GLBasic each instance of a class shares the same memory area for the static variable.
PRIVATE means you can´t access the data directly when working with an instance of the class.

what he said.
But i read on the internet somewhere, that c++ static is not readable extern_ , i havent tested it.
TBH, i cant explain to you how it even is logically possible to not be able to read them with the extern tools.
Its an internal rules in c++ for security reasons?
But how else can it be hidden? (i think we are in disagreement here, but im always willing to learn.)
Have you even tested the fact of reading a static global externally?
From a different OS maybe?

It is all a thing of enabling users to work better as a team ( failproof shairing of libraries )

It sure it a standard around here, and thanks for some input!

[kanonet]

I think you simply missunderstood that text. When it did say extern it did not mean extern of of its program, but extern of its scope. In C++ static has several meanings:

• static inside a function = same as in GLBasic, variable will be kept between function calls, but can not be access from outside of the function.
• static inside class declaration = create a static member or function that can be used from outside of the class (using the scope operator :: ) even when there is no instance of that class. It is the same for all instances of that class
• static outside of any function/class = if you write a variable outside of any function or class it will be global (C++ has no keyword global), it can be accessed anywhere in your program, even in other compilation unites (when using the keyword extern). But if you declare such a variable static, then it will be a "global" only in this file/compilation unit, it can be access inside any function in that unit, but not in other ones (even not with the keyword extern).

Remember, that in GLBasic only the 1st meaning of static exist, but not the other two.

Again all variable are for intern use of the program only and can only be accessed with special tools that use some kind of hacky way to break out of its own memory and read other programs memory. But that has nothing todo with the way variable scopes are designed. So I think you just got your text wrong.