Intel C++ compiler does not even allow global variables without prior "extern" declaration. That is very nasty.
What about you have a Singleton, someone has to create at least one instance?!
test.h:
class CTest : public mySingleton<CTest>
{
public:
CTest() {...}
void DoSomething(...)
}
test.cpp:
static CTest myTestInstance;
The problem here is, that without static it does not work. When I use a singleton in some kind of static library, i can not say: CTest::GetInstance()->DoSomething since no instance of CTest does exist. If I use Statitc the compiler does not complain anymore, but why does static set him allright?
Using all global variables?
Quote:Is using all global variables in my programs a bad practice?
That depends on the use. Generally, there are better ways, as described above. Some times, they are unavoidable because they are systematically used is many places and it impacts performance otherwise. An example is to set function pointers to OpenGL extension functions. Not sure how encapsulation, accessor methods or singletons could be of any help here.
the most used method is to keep variables as local as possible
and to use pointers on all large variables so that when you do a function call (example)
HBITMAP bmp; (large memory hogging structure)
somefunct(bmp); //the entire HBITMAP will be copied into the stack for somefunct, bad very bad
somefunct(&bmp); //only a 32 bit (or 64 bit) pointer will be copied instead of a multimegabyte HBITMAP
when it comes down to it using a structure of pointers for variables that must remain global works faster for large global variables, since the actual data will not be accessed until you actually use the data the pointer is pointing to, then there will be the slow process of getting that data from outside of the local functions stack
remeber kiddies..pointers are our friends..globals are bad
and to use pointers on all large variables so that when you do a function call (example)
HBITMAP bmp; (large memory hogging structure)
somefunct(bmp); //the entire HBITMAP will be copied into the stack for somefunct, bad very bad
somefunct(&bmp); //only a 32 bit (or 64 bit) pointer will be copied instead of a multimegabyte HBITMAP
when it comes down to it using a structure of pointers for variables that must remain global works faster for large global variables, since the actual data will not be accessed until you actually use the data the pointer is pointing to, then there will be the slow process of getting that data from outside of the local functions stack
remeber kiddies..pointers are our friends..globals are bad
Wow, didn't expect this sort of response, it looks like I'll have to research this , maybe try some of the other ways.
Quote:Original post by Samurai Jack
Intel C++ compiler does not even allow global variables without prior "extern" declaration. That is very nasty.
What about you have a Singleton, someone has to create at least one instance?!
...code snip...
That is not a singleton. Your constructor is public.
Quote:Original post by Samurai Jack
The problem here is, that without static it does not work. When I use a singleton in some kind of static library, i can not say: CTest::GetInstance()->DoSomething since no instance of CTest does exist. If I use Statitc the compiler does not complain anymore, but why does static set him allright?
For a correct Singleton, no one declares an instance except the class itself.
Quote:Original post by Fixxer
If you can be organized with your code, globals are better because they increase application speed.
Ummm, global variables are a result of disorganized code. If you can be organized with your code, you won't have any global variables.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement