How do you create a static class in C++?
Solution 1
If you're looking for a way of applying the "static" keyword to a class, like you can in C# for example, then you won't be able to without using Managed C++.
But the looks of your sample, you just need to create a public static method on your BitParser object. Like so:
BitParser.h
class BitParser
{
public:
static bool getBitAt(int buffer, int bitIndex);
// ...lots of great stuff
private:
// Disallow creating an instance of this object
BitParser() {}
};
BitParser.cpp
bool BitParser::getBitAt(int buffer, int bitIndex)
{
bool isBitSet = false;
// .. determine if bit is set
return isBitSet;
}
You can use this code to call the method in the same way as your example code.
Solution 2
Consider Matt Price's solution.
- In C++, a "static class" has no meaning. The nearest thing is a class with only static methods and members.
- Using static methods will only limit you.
What you want is, expressed in C++ semantics, to put your function (for it is a function) in a namespace.
Edit 2011-11-11
There is no "static class" in C++. The nearest concept would be a class with only static methods. For example:
// header
class MyClass
{
public :
static void myMethod() ;
} ;
// source
void MyClass::myMethod()
{
// etc.
}
But you must remember that "static classes" are hacks in the Java-like kind of languages (e.g. C#) that are unable to have non-member functions, so they have instead to move them inside classes as static methods.
In C++, what you really want is a non-member function that you'll declare in a namespace:
// header
namespace MyNamespace
{
void myMethod() ;
}
// source
namespace MyNamespace
{
void myMethod()
{
// etc.
}
}
Why is that?
In C++, the namespace is more powerful than classes for the "Java static method" pattern, because:
- static methods have access to the classes private symbols
- private static methods are still visible (if inaccessible) to everyone, which breaches somewhat the encapsulation
- static methods cannot be forward-declared
- static methods cannot be overloaded by the class user without modifying the library header
- there is nothing that can be done by a static method that can't be done better than a (possibly friend) non-member function in the same namespace
- namespaces have their own semantics (they can be combined, they can be anonymous, etc.)
- etc.
Conclusion: Do not copy/paste that Java/C#'s pattern in C++. In Java/C#, the pattern is mandatory. But in C++, it is bad style.
Edit 2010-06-10
There was an argument in favor to the static method because sometimes, one needs to use a static private member variable.
I disagree somewhat, as show below:
The "Static private member" solution
// HPP
class Foo
{
public :
void barA() ;
private :
void barB() ;
static std::string myGlobal ;
} ;
First, myGlobal is called myGlobal because it is still a global private variable. A look at the CPP source will clarify that:
// CPP
std::string Foo::myGlobal ; // You MUST declare it in a CPP
void Foo::barA()
{
// I can access Foo::myGlobal
}
void Foo::barB()
{
// I can access Foo::myGlobal, too
}
void barC()
{
// I CAN'T access Foo::myGlobal !!!
}
At first sight, the fact the free function barC can't access Foo::myGlobal seems a good thing from an encapsulation viewpoint... It's cool because someone looking at the HPP won't be able (unless resorting to sabotage) to access Foo::myGlobal.
But if you look at it closely, you'll find that it is a colossal mistake: Not only your private variable must still be declared in the HPP (and so, visible to all the world, despite being private), but you must declare in the same HPP all (as in ALL) functions that will be authorized to access it !!!
So using a private static member is like walking outside in the nude with the list of your lovers tattooed on your skin : No one is authorized to touch, but everyone is able to peek at. And the bonus: Everyone can have the names of those authorized to play with your privies.
private
indeed...
:-D
The "Anonymous namespaces" solution
Anonymous namespaces will have the advantage of making things private really private.
First, the HPP header
// HPP
namespace Foo
{
void barA() ;
}
Just to be sure you remarked: There is no useless declaration of barB nor myGlobal. Which means that no one reading the header knows what's hidden behind barA.
Then, the CPP:
// CPP
namespace Foo
{
namespace
{
std::string myGlobal ;
void Foo::barB()
{
// I can access Foo::myGlobal
}
}
void barA()
{
// I can access myGlobal, too
}
}
void barC()
{
// I STILL CAN'T access myGlobal !!!
}
As you can see, like the so-called "static class" declaration, fooA and fooB are still able to access myGlobal. But no one else can. And no one else outside this CPP knows fooB and myGlobal even exist!
Unlike the "static class" walking on the nude with her address book tattooed on her skin the "anonymous" namespace is fully clothed, which seems quite better encapsulated AFAIK.
Does it really matter?
Unless the users of your code are saboteurs (I'll let you, as an exercise, find how one can access to the private part of a public class using a dirty behaviour-undefined hack...), what's private
is private
, even if it is visible in the private
section of a class declared in a header.
Still, if you need to add another "private function" with access to the private member, you still must declare it to all the world by modifying the header, which is a paradox as far as I am concerned: If I change the implementation of my code (the CPP part), then the interface (the HPP part) should NOT change. Quoting Leonidas : "This is ENCAPSULATION!"
Edit 2014-09-20
When are classes static methods are actually better than namespaces with non-member functions?
When you need to group together functions and feed that group to a template:
namespace alpha
{
void foo() ;
void bar() ;
}
struct Beta
{
static void foo() ;
static void bar() ;
};
template <typename T>
struct Gamma
{
void foobar()
{
T::foo() ;
T::bar() ;
}
};
Gamma<alpha> ga ; // compilation error
Gamma<Beta> gb ; // ok
gb.foobar() ; // ok !!!
Because, if a class can be a template parameter, a namespaces cannot.
Solution 3
You can also create a free function in a namespace:
In BitParser.h
namespace BitParser
{
bool getBitAt(int buffer, int bitIndex);
}
In BitParser.cpp
namespace BitParser
{
bool getBitAt(int buffer, int bitIndex)
{
//get the bit :)
}
}
In general this would be the preferred way to write the code. When there's no need for an object don't use a class.
Solution 4
If you're looking for a way of applying the "static" keyword to a class, like you can in C# for example
static classes are just the compiler hand-holding you and stopping you from writing any instance methods/variables.
If you just write a normal class without any instance methods/variables, it's the same thing, and this is what you'd do in C++
Solution 5
Can I write something like static class
?
No, according to the C++11 N3337 standard draft Annex C 7.1.1:
Change: In C ++, the static or extern specifiers can only be applied to names of objects or functions. Using these specifiers with type declarations is illegal in C ++. In C, these specifiers are ignored when used on type declarations. Example:
static struct S { // valid C, invalid in C++ int i; };
Rationale: Storage class specifiers don’t have any meaning when associated with a type. In C ++, class members can be declared with the static storage class specifier. Allowing storage class specifiers on type declarations could render the code confusing for users.
And like struct
, class
is also a type declaration.
The same can be deduced by walking the syntax tree in Annex A.
It is interesting to note that static struct
was legal in C, but had no effect: Why and when to use static structures in C programming?
Related videos on Youtube
Comments
-
andrewrk almost 3 years
How do you create a static class in C++? I should be able to do something like:
cout << "bit 5 is " << BitParser::getBitAt(buffer, 5) << endl;
Assuming I created the
BitParser
class. What would theBitParser
class definition look like?-
Admin over 11 years@Vagrant a function inside a namespace is still a function. A function that belongs to a class is called a method. If it is a static method, you invoke it similarly as if it was a function inside a namespace.
-
bcrist over 10 years@superjoe30 As far as I know, there is one good use for a "static" class: specialization of an overloaded template function - see "Moral #2" here.
-
AarCee almost 6 yearsIMO container-like classes (having just static methods) are useful in certain cases.
-
anni over 4 yearsStatic class templates can be used to remove redundant type declarations across multiple class templates.
-
-
andrewrk over 15 yearsOJ, you have a syntax error. The static keyword should only be used in the class definition, and not in the method definition.
-
Saad almost 15 yearsIn some cases you may want to have data encapsulation even if the class is mostly "static". Static private class members will give you this. Namespace members are always public and cannot provide data encapsulation.
-
jmucchiello about 14 yearsIf the "member" var is only declared and accessed from the .cpp file, it is more private than a private var declared in the .h file. NOT that I recommend this technique.
-
paercebal almost 14 years@Torleif : You're wrong. namespaces are better for encapsulation than static private members. See my answer for demonstration.
-
Danvil almost 14 yearsTo make your intention clear in this approach you can additionally use a private constructor.
private: BitParser() {}
This will prevent anyone from creating instances. -
Tom over 13 yearsGCC supports -fno-access-control, which can be used in whitebox unit tests to access otherwise private class members. That's about the only reason I can think of to justify using a class member instead of an anonymous/static global in the implementation.
-
paercebal over 13 years@Tom: A cross-platform solution would be to add the following code
#define private public
in the headers... ^_^ ... -
paercebal over 13 years@Tom: anyway, IMHO, even considering unit testing, the cons of "showing too much stuff" outweights the pros. I guess an alternative solution would be to put the code to be tested in a function taking the needed parameters (and no more) in a
utilities
namespace. This way, this function can be unit-tested, and still have no special access to private members (as they are given as parameters at the function call)... -
Moataz Elmasry over 11 yearsyes but in namespace you have to keep the function order, in contrast to class with static members, for example void a(){b();} b(){} would yield an error in a namespace but not in a class with static members
-
OJ. over 11 years@MoatazElmasry thread safety is a problem when you share state. In the above implementation there is no state shared, so there can not be any issues with thread safety ... unless you're stupid enough to use statics inside those functions. So yes, the code above is thread safe, just keep persistent state out of your functions and you're good.
-
OJ. over 11 years@MoatazElmasry Incorrect. Two threads can't modify non-static local variables in a static function.
-
Guy L almost 11 yearsBut everyone cango to TheDataToBeHidden -> It's not a solution
-
3Dave over 10 yearsNot to complain (especially at you), but some compiler hand-holding to keep me from writing or cut/pasting the word
static
200 times would be a good thing. -
Mitkins over 10 yearsAgreed - but a static class in C# doesn't do this either. It just fails to compile when you forget to paste static in there :-)
-
3Dave over 10 yearsYeah - fair enough. My macros are showing. Honestly, if I declare the class as static, the compiler should only throw an error if I try to instantiate it. Rules that require me to repeat myself are obnoxious and should be the first against the wall when the revolution comes.
-
Zak over 9 years@paercebal I'm about to jump onboard your ship, but I have one final reservation. If someone jumps in your
namespace
will they not gain access to yourglobal
, albeit hidden, members? Obviously they would have to guess, but unless you are intentionally obfuscating your code, variable names are pretty easy to guess. -
paercebal over 9 years@Zak : Indeed, they could, but only by trying to do it in the CPP file where the myGlobal variable is declared. The point is more visibility than accessibility. In the static class, the myGlobal variable is private, but still visible. This is not as important as it seems, but still, in a DLL, showing a symbol that should be private to the DLL in an exported header could be awkward... In the namespace, the myGlobal exists only in the CPP file (you can even go farther and make it static). That variable doesn't appear in the public headers.
-
Zak over 9 years@paercebal So by putting them in the anonymous
namespace
you are sealing the variables? In your answer can you break from your analogy and explain the mechanism of thenamespace
in greater technical detail (as in constraints imposed)? -
Zak over 9 years
-
Tyler about 8 years@paercebal, and also
#define class struct
to catch members that default to private at the beginning of the class. But that seems like it might break some things? Do you see any way it could? -
Jämes almost 7 yearsIf your attempt is to have the similar behavior of the C# static classes, you should mark the class as sealed with the
final
keyword (from C++11) to prevent any other class to inherit from. -
ksinkar over 6 yearsWhat you are suggesting might create a singleton Class, but it is not the same as a static class.
-
phoenix almost 6 yearsIf C++11, I'd argue it's better to
BitParser() = delete;
to properly convey the intention of removing the constructor (not just hiding it asprivate
). -
Gavin Williams over 2 years"But you must remember that "static classes" are hacks .. in languages like C#." - That is just wrong, it's not a hack, it's an expression of intent, one that C++ simply lacks. You've made the mistake of thinking that static functions are always just a loose collection of related/unrelated functions. That's not true at all. A static class follows the class model, but it has the extra restrictions that it can't be instantiated, it's a single / static class, available where you need it. Typically I would make CoreGraphics a static class for example, because it is used across the namespace.
-
Gavin Williams over 2 yearsThe lack of memberless functions in C# is a separate issue to static classes. It's a missing feature in C# for sure and you can use static classes to mimic that intent (because it looks exactly the same). But thinking that static classes is just a hack to provide memberless functions is wrong.