0

I have a .cpp source file with some functions that need to be publicly accessible and some support functions that are only used in this source file.

I have been putting the all of these functions declarations in the header file as I personally find it useful to see everything a class offers in one place. However I would like to indicate whether the functions are for internal use, similar to the private access modifier, but without using classes (they are standalone functions).

Some possible solutions are:

  • Put the private declarations in the source file.
  • Put the private declarations in a separate header.

Both of these solutions split the public and private functions into separate files which I would like to avoid.

Daniel
  • 1,239
  • 1
  • 13
  • 24

4 Answers4

6

If the functions are not intended for public use, the shouldn't be placed into the header. Put them into the source file they are used in.

To completely hide these functions from being used outside the source file one of the following is usually done:

  • Functions are declared as static.
  • Functions are put into an unnamed namespace.

The latter is considered preferable. Actually, the C++ Standard 7.3.1.1 states:

The use of the static keyword is deprecated when declaring objects in a namespace scope, the unnamed-namespace provides a superior alternative.

For more discussion about unnamed namespaces vs static refer to Unnamed/anonymous namespaces vs. static functions and to corresponding comp.lang.c++.moderated thread.

Community
  • 1
  • 1
Alex Bakulin
  • 1,668
  • 11
  • 17
  • 2
    I think the question is about free-standing functions: _"similar to the private access modifier, but without using classes"_. @Daniel, am I wrong? – Alex Bakulin May 22 '12 at 10:55
  • That's correct, the code I'm working with doesn't use classes. – Daniel May 22 '12 at 11:04
  • @Daniel: I re-read your question and the fact that it's about _functions_ (and not _methods_) isn't really clear. Perhaps you should state it explicitly. – Alex Bakulin May 22 '12 at 11:07
  • Would it be bad practice to put static/anonymous functions in the header if they are not used elsewhere? It seems beneficial to me to have all the declarations in the one place. – Daniel May 22 '12 at 11:09
  • @Daniel: It's a really bad practice. Every translation unit which includes your header file would get its own copy of these functions. – Alex Bakulin May 22 '12 at 11:12
  • Thanks for your help. I looked at [this question](http://stackoverflow.com/questions/154469/unnamed-anonymous-namespaces-vs-static-functions) for more information. Would `static` and unnamed namespaces make the function only usable in the header file it is declared in, not even the .cpp file that imports it? This would mean it is impossible to limit use of these functions without placing them in a separate file. – Daniel May 22 '12 at 11:25
  • 2
    No. An `#include` directive is just textually replaced with the contents of the included header file. So everything from the header file is accessable to the file it's included in. – Alex Bakulin May 22 '12 at 11:30
  • I thought in C++ the standard stated that *The use of the static keyword is deprecated when declaring objects in a namespace scope, the unnamed-namespace provides a superior alternative* ? – Component 10 May 23 '12 at 07:08
  • "If the functions are not intended for public use" Putting function into header does not mean that it is "for public use" header is not the same thing as, say "interface" section in pascal module. You can make private headers that will be invisible from "outside", if you want. It makes sense if there are many internal functions that are frequently used in multiple source files. – SigTerm May 23 '12 at 14:50
  • @SigTerm Sure, but the question states that _"some support functions that are only used in this source file"_. – Alex Bakulin May 23 '12 at 18:21
3

If the private functions are only used in a single source file, then you don't need any extra header file. Just mark the functions either static or use an anonymous namespace.

If the functions can be used from many source files, declare them in a separate header file in a special namespace. That's my advice.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
0

Where should support function declarations go?

They don't have to go anywhere. Make them static and keep them in source file. If they're only used in single source file, there's no need to put forward declarations into any header.

SigTerm
  • 26,089
  • 6
  • 66
  • 115
  • This is true. I find it handy to have all the declarations in the one place, but I guess modern IDEs provide class outlining features to quickly show what functions are available. – Daniel May 23 '12 at 03:20
0

You don't mention whether these 'functions' are members of a class but I'll assume that they are. If so, I would recommend that you look at the 'pimpl idiom'. Basically this means putting all or most of what you want to keep private into a seperate class and then only having a pointer to an instance of the class in your class declaration. For example:

class MyClass
{
    // ... some stuff
private:
    SecretObject obj_;
    int hiddenCall();
};

becomes

class MyClassImpl;

class MyClass
{
private:
    MyClassImpl* impl_;
};

The idea then is that all the declaration and definition of your implemntation class would go into your .cpp file which hides it from anything but the compilation unit. This approach has a number of important advantages:

  • Hides implementation so the publicly available header does not give too much of the implementation away.
  • Can increase compilation speed by removing dependecies in the header - v. important if the header is included a lot.
  • Can be useful for 'insulating` client code against libraries that they shouldn't need to build against such as database APIs etc.

There are a number of drawbacks:

  • Can make unit testing more tricky if code is hidden away in cpp files. Personally I find a better solution is to have a seperate, private header and implementation file so you can control what clients of your code get but a test harness can still test it adequately. You can simply include the MyClassImpl header in your cpp file, but don't include it in the MyClass header - this would defeat the object.
  • The indirection between MyClass and MyClassImpl can be tiresome to code / manage.

Generally though, it's probably the best way of acheiving what you want to get to. Look at articles by Herb Sutter for a more in depth explaination.

On the other hand, if you are talking about free functions, not directly related to the class, then I would put these within the unnamed namespace within your cpp file. For example:

namespace {

    // Your stuff goes here.

};

Again, you've got a unit test issue of how to access these functions if you take this approach, but it's possible to work around this if that's really an issue, perhaps by creating a specific namespace, conditional compilation etc. Not ideal, but possible.

Component 10
  • 10,247
  • 7
  • 47
  • 64