Statc Vs. Dynamic Class

My program needs a Class. It only needs one instance so I can make all the members static (a static class). I also can make a dynamic class (not static) then create one instance and use it. I created an example program. Two classes acting exactly the same.
MyStaticClass.h

Code:

class MyStaticClass
{
      static int _i;
public:
      static void PrintMe();
};

Its .cpp

Code:

#include "MyStaticClass.h"
#include <iostream>      

int MyStaticClass::_i = 516;

void MyStaticClass::PrintMe()
{
      std::cout << _i << std::endl;
}

MyDynClass.h

Code:

class CMyDynClass
{
      int _i;
public:
      CMyDynClass();
      void PrintMe() const;
};

extern CMyDynClass MyDynClass;

Its .cpp

Code:

#include "MyDynClass.h"
#include <iostream>      

CMyDynClass MyDynClass;

CMyDynClass::CMyDynClass()
{
      _i = 516;
}

void CMyDynClass::PrintMe() const
{
      std::cout << _i << std::endl;
}

And main to test them

Code:

#include "MyDynClass.h"
#include "MyStaticClass.h"

int main()
{
      MyStaticClass::PrintMe();
      MyDynClass.PrintMe();

      return 0;
}

I want to know your idea about benefits and drawbacks of each method.

Thanks

I think they are incomparable: static members are members which can be used at times where there are no live objects; extern keyword is used when you want an identifier to work across translation units, while only declared once in the program. It's not dynamic per se.

I imagine extern is used the same as it is in C: structs are defined in c files, but are extern variables in headers, so that you can effectively hide the definition from people who just see the header and not the rest of the code.

Avoid using static unless you have a very valid reason to use it (and when you do, rethink your design, most likely you can do things differently so you don't need it).

Originally Posted by jwenting

Avoid using static unless you have a very valid reason to use it (and when you do, rethink your design, most likely you can do things differently so you don't need it).

That doesn't make much sense.
There's nothing wrong with static member functions. I think forcing someone to create an instance of a class just to use a member function that could've just as easily been static is wrong.
You might argue that static member functions should just be stand-alone functions, but if they do something related to a certain class or need access to a classes static member variables, then they should be a static member.

I should note that static functions have the benefit of avoiding "this" as a parameter.

I expected many more answers.

Originally Posted by whiteflag

I think they are incomparable: static members are members which can be used at times where there are no live objects; extern keyword is used when you want an identifier to work across translation units, while only declared once in the program. It's not dynamic per se.

I imagine extern is used the same as it is in C: structs are defined in c files, but are extern variables in headers, so that you can effectively hide the definition from people who just see the header and not the rest of the code.

Of course they are comparable because two different techniques are used to do the same job.

As I know there is no difference between C and C++ in this matter.

Of course they are comparable because two different techniques are used to do the same job.

And what job is that? How is extern "dynamic," and what do you mean by dynamic class? I think you misunderstand the keywords you want to use, and what they actually do are very different things like I said.

Well, now that I think of it, you probably mean to use the Singleton, because you said in your first post you would only need one object. For that, static is used, but whether the Singleton is a good answer or not depends. It has been criticized as a euphemism for a global variable before.

Originally Posted by whiteflags

It has been criticized as a euphemism for a global variable before.

A "public member" is also a euphemism for a global variable; if that makes it "wrong" then give up OOP.

The caveat against globals as I understand it is a clarity and "translation unit problems" issue -- classes do seem to mitigate that. Even if siavoshkc's idea were blatantly and explicitly just for the purpose of managing global vars (heck, call the class "MyGlobals"), why not?

Originally Posted by MK27

A "public member" is also a euphemism for a global variable; if that makes it "wrong" then give up OOP.

Your reasoning does not make sense to me. Rather, if that makes it "wrong" then give up the use of public member variables (and protected ones too).

Originally Posted by MK27

Even if siavoshkc's idea were blatantly and explicitly just for the purpose of managing global vars (heck, call the class "MyGlobals"), why not?

Notice that whiteflags stated that "it depends". There are situations where the use of global variables, public member variables, etc, might be justified.

Originally Posted by laserlight

Your reasoning does not make sense to me. Rather, if that makes it "wrong" then give up the use of public member variables (and protected ones too).

Pick, pick, pick Are you going to give up public methods too?* Otherwise sneaky types will just start replacing "myobj.value" with getters and setters.

In all seriousness: personally I don't have any intention of giving up globals, public members, or OOP. Not until the the kode kops drag me away kicking and screaming.


* I think the "100% opaque" class may prove difficult to use.

Originally Posted by MK27

Are you going to give up public methods too?

No, because they can form an interface to the class such that the implementation can be changed without requiring the client code to change (though a recompile may be needed unless the pimpl idiom is used).

Originally Posted by whiteflags

And what job is that? How is extern "dynamic," and what do you mean by dynamic class?

I called it dynamic in contrast with static. A class that should be instantiated to be usable. This is why I placed "not static" in parenthesis in the first post.

Originally Posted by whiteflags

Well, now that I think of it, you probably mean to use the Singleton, because you said in your first post you would only need one object. For that, static is used, but whether the Singleton is a good answer or not depends. It has been criticized as a euphemism for a global variable before.

Restricting instantiation was not important in the first place. But reading on wikipedia about Singleton there was an answer to my original question

Originally Posted by Wikipedia

Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton

There maybe other differences too. Will be happy to know them.

if you have a function, that doesn't affect the object, then I would pull it out of the object. If it is related to the object and you want that to be clear, then I would put them in the same name space.

I don't understand the use of static functions (though, ironically, the use of static data members I understand perfectly). A function that doesn't change the object or pull information from the object shouldn't be part of the object IMO.

Originally Posted by Cogman

if you have a function, that doesn't affect the object, then I would pull it out of the object. If it is related to the object and you want that to be clear, then I would put them in the same name space.

I don't understand the use of static functions (though, ironically, the use of static data members I understand perfectly). A function that doesn't change the object or pull information from the object shouldn't be part of the object IMO.
Cogman is offline

Static function has access to private static data members.

Static function has access to private static data members.

If you make those free functions accessing variables defined only in a source file, those global variables can be hidden much better than with "private". (They will not be visible to anyone except the function(s) that are supposed to use them, as you won't have to put them in a header.)

So instead of making a static class we put private members in a cpp in addition to functions. Like this:
Our header

Code:

void MyVirClass::PrintMe();

In cpp we will have

Code:

#include "MyStaticClass.h"
#include <iostream>      

namespace MyVirClass
{
      int _i = 516;
      
      void PrintMe()
      {
            std::cout << _i << std::endl;
      }
}

It can be another alternative!