39

I already read a lot of posts and articles all over the net, but I couldn't find a definite answer about this.

I have some functions with similar purposes that I want to have out of the global scope. Some of them need to be public, others should be private (because they are only helper functions for the "public" ones). Additionally, I don't have only functions, but also variables. They are only needed by the "private" helper functions and should be private, too.

Now there are the three ways:

  • making a class with everything being static (contra: potential "Cannot call member function without object" - not everything needs to be static)
  • making a singleton class (contra: I WILL need the object)
  • making a namespace (no private keyword - why should I put it in a namespace at all, then?)

What would be the way to take for me? Possible way of combining some of these ways?

I thought of something like:

  1. making a singleton, the static functions use the helper function of the singleton object (is this possible? I'm still within the class, but accessing an object of it's type)
  2. constructor called at programm start, initializes everything (-> making sure the statics can access the functions from the singleton object)
  3. access the public functions only through MyClass::PublicStaticFunction()

Thanks.

HelloGoodbye
  • 3,624
  • 8
  • 42
  • 57
blubberbernd
  • 3,641
  • 8
  • 35
  • 46
  • 5
    Don't use singletons unless you really need to (ie. almost never). A good discussion is http://www.ibm.com/developerworks/webservices/library/co-single/index.html – Alexandre C. Apr 26 '11 at 16:32
  • The URL pointed to by @AlexandreC. is dead. The original article can now be found at https://blog.thecodewhisperer.com/assets/use-your-singletons-wisely-original.pdf, and there is some further discussion at https://blog.thecodewhisperer.com/permalink/use-your-singletons-wisely-ten-years-later. – SWB Mar 16 '23 at 05:01

6 Answers6

42

As noted, using global variables is generally bad engineering practice, unless absolutely needed of course (mapping hardware for example, but that doesn't happen THAT often).

Stashing everything in a class is something you would do in a Java-like language, but in C++ you don't have to, and in fact using namespaces here is a superior alternative, if only:

  • because people won't suddenly build instances of your objects: to what end ?
  • because no introspection information (RTTI) is generated for namespaces

Here is a typical implementation:

// foo.h
#ifndef MYPROJECT_FOO_H_INCLUDED
#define MYPROJECT_FOO_H_INCLUDED

namespace myproject {
  void foo();
  void foomore();
}

#endif // MYPROJECT_FOO_H_INCLUDED

// foo.cpp
#include "myproject/foo.h"

namespace myproject {

namespace {
  typedef XXXX MyHelperType;

  void bar(MyHelperType& helper);
} // anonymous

void foo() {
  MyHelperType helper = /**/;
  bar(helper);
}

void foomore() {
  MyHelperType helper = /**/;
  bar(helper);
  bar(helper);
}
} // myproject

The anonymous namespace neatly tucked in a source file is an enhanced private section: not only the client cannot use what's inside, but he does not even see it at all (since it's in the source file) and thus do not depend on it (which has definite ABI and compile-time advantages!)

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
  • 3
    Thanks. I decided this as the best solution for my problem. I'm coming from C# (where everything is a class), that's why these (unnamed) namespace solutions are new to me. – blubberbernd Apr 26 '11 at 19:18
  • @blubberbernd: in this case I can only recommend a good C++ book. C++ is both rich and full of (bad) surprises, and a good tutorial can only help. There is a list on SO: http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list – Matthieu M. Apr 27 '11 at 06:18
  • Nice answer. I am doing some embedded programming in C++ and was confronted with the problem that some peripherals just can be used (should be initialized) once. It was a natural thing to implement in C but I felt I HAD TO go for an object oriented approach using C++. But using a singleton was of limited use because I also had to implement related interrupt service routines as "free functions". – Rev Aug 05 '16 at 07:09
  • One question about the anonymous namespace: If the "private" functions aren't declared in the header, wouldn't that be enough to prevent client code from using them? Am I missing something? – Rev Aug 05 '16 at 07:15
  • @Rev1.0: Anonymous namespaces and `static` are there for linkage, primarily: the symbol is then not visible outside the translation unit in which it is defined, which avoids collisions. It also hints to the compiler that it need not emit the function code at all and might want to consider more strongly inlining it. Incidentally, it also prevents someone who has peeked into the source code from declaring the function so as to use it too: to use it they need to somehow inspect the binary to find its address... if it exists at all (ie, was not inlined). – Matthieu M. Aug 05 '16 at 07:22
  • Thanks for the feedback. So its effectively just a C++ alternative to the "static" you would use in C to restrict linkage to the module? Isn't using the "static" keyword a cleaner approach since it better conveys the intent? – Rev Aug 05 '16 at 07:48
  • I think I found the answer regarding static vs namespace myself: http://stackoverflow.com/a/4726710/1790864 – Rev Aug 05 '16 at 12:36
  • @Rev1.0: the main advantage of unnamed namespace is that you can declare all kinds of things in there (such as new structs, etc...), in this case their auto-generated methods (constructors, ...) also get private linkage. Once you get used to using unnamed namespaces for "local" struct/class you also naturally use them for what could be `static`. There are further subtleties (wrt. specialization/name look-up) as well... – Matthieu M. Aug 05 '16 at 13:28
  • I wonder if this instead of a lazy initialized singleton will require the developer to manually handle lazy initialization using some flags like checking `isInitialized` or `nullptr`? If lazy init is required, is [singleton](https://stackoverflow.com/a/1008289/5366367) a more suitable design? – Escape0707 May 01 '21 at 03:48
  • Edit: never mind, just [wrap the init in a referencing function](https://stackoverflow.com/a/1005709/5366367). – Escape0707 May 01 '21 at 04:05
  • there is a caveat tho: the private function cannot access public functions – Created Nov 24 '22 at 20:46
  • @Created: I have no idea what you are talking about, since there's neither private nor public function here. Do you mind clarifying? – Matthieu M. Nov 25 '22 at 07:53
  • @MatthieuM: Everything inside the anonymous namespace -> private, everything outside -> public. – Created Nov 26 '22 at 10:56
  • @Created: Then you are wrong. An anonymous namespace, in this regard, behaves like any other namespace and thus items within an anonymous namespace can use items outside of it. It's pretty common to use `std::string` inside an anonymous namespace, for example. – Matthieu M. Nov 26 '22 at 11:56
11

Don't make it a singleton

For public helper functions that don't directly depend on these variables, make them non-member functions. There's nothing gained by putting them in a class.

For the rest, put it in a class as normal non-static members. If you need a single globally accessible instance of the class, then create one (but don't make it a singleton, just a global).

Otherwise, instantiate it when needed.

g19fanatic
  • 10,567
  • 6
  • 33
  • 63
jalf
  • 243,077
  • 51
  • 345
  • 550
  • Yay, anonymous downvotes. Anyone care to explain *why* this is a bad answer? – jalf Apr 26 '11 at 16:54
  • 1
    I'm not the downvoter, but I'm guessing some might take issue with your "globally accessible instance" paragraph. Global objects suffer the same disadvantages as singletons (as singletons are merely global objects in disguise). – Emile Cormier Apr 26 '11 at 17:13
  • 2
    Another point of contention might be "There's nothing gained by putting them in a class." There is one thing gained, albeit trivial: the class that holds the static member functions serves as a namespace. I realize that the same effect can be accomplished by `namespace`, but perhaps people coming from a Java background don't. – Emile Cormier Apr 26 '11 at 17:19
  • @Emile: no they don't. Read the blog post I linked to. Singletons combine *two* different problems. A plain old global has only one of them. That's still enough to make it a bad solution most of the time, but I'd say a global has a few legitimate uses. A singleton has *none*. – jalf Apr 26 '11 at 17:25
  • On your second point, as you say, a namespace is better for that purpose. – jalf Apr 26 '11 at 17:25
  • @jalf: Just read your article. Very well written -- I like your prose. When I said "the same disadvantages as singletons", I guess I meant the global state disadvantage. The problems with singletons weren't so neatly categorized in my head. – Emile Cormier Apr 26 '11 at 17:39
2

The classic C way of doing this, which seems to be what you want, is to put the public function declarations in a header file, and all the implementation in source file, making the variables and non-public functions static. Otherwise just implement it as a class - I think you are making a bit of a mountain out of a molehill here.

  • 2
    Note that the use of `static` this way is deprecated in C++ in favor of anonymous namespaces. So `namespace { int i; }` rather than `static int i;` Otherwise, yes. – Dennis Zickefoose Apr 26 '11 at 19:00
  • @Dennis Stroustrup was talking about undeprecating it some time ago, which I think is the right thing to do. Don't know if anything ever came of it. I find the nameless namespace thing, well ... silly. –  Apr 26 '11 at 19:02
  • 1
    Personally, I find `static` having three completely unrelated meanings silly. But looking through the C++0x draft, they seem to have removed that bit. So nevermind :-) – Dennis Zickefoose Apr 26 '11 at 19:19
  • @Dennis And see http://stackoverflow.com/questions/4726570/deprecation-of-the-static-keyword-no-more –  Apr 26 '11 at 19:40
1

What about using a keyword static at global scope (making stuff local to the file) as a privacy substitute?

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
1

From your description it looks like you have methods and data that interact with each other here, in other words it sounds to me like you actually want a non-singleton class to maintain the state and offer operations upon that state. Expose your public functions as the interface and keep everything else private.

Then you can create instance(s) as needed, you don't have to worry about init order or threading issues (if you have one per thread), and only clients that need access will have an object to operate upon. If you really need just one of these for the entire program you could get away say a global pointer that's set in main or possibly an instance method, but those come with their own sets of problems.

Mark B
  • 95,107
  • 10
  • 109
  • 188
0

Remember that the singleton instance of a singleton class is a valid instance, so it is perfectly able to be the recipient of nonstatic member functions. If you expose your singleton factory as a static function then have all of your public functionality as public nonstatic member functions and your private functionality as private nonstatic member functions, anyone that can get at the class can access the public functionality by simply invoking the singleton factory function.

You don't describe whether all of the functionality you're trying to wrap up is as related as to justify being in the same class, but if it is, this approach might work.

If you take a "C-like" approach and just use top-level functions, you can make them private by declaring them in the .cpp file rather than the publicly-included .h file. You should also make them static (or use an anonymous namespace) if you take that approach.

NVade
  • 278
  • 1
  • 1