Using namespaces in header files.

[Mats]

So I've been making a header file and put variables in their own namespace to avoid conflicts. My question is, do functions in the header file normally go in a namespace too, or should they just be named in a way which makes them unlikely to be accidentally copied?

[S G H]

Perhaps put the private variables in another inner namespace?
E.G.

Namespace A
->Namespace Internal
-->Variables
-->End of namespace Internal
->Functions
->End of namespace A

[Catfish666]

I would say that they should be put in a namespace as well, for consistency.
For example, pretty much everything in the C++ standard library is in the std:: namespace.

Of course it matters that you choose a sensible (i.e. reasonably short) name for your namespace, and not something like MatsLibraryForCpp.

[coder777]

You shouldn't have variables in the namespace. Functions: (few) yes. Constants: yes

[ne555]

> be named in a way which makes them unlikely to be accidentally copied?
that's what namespaces do.

> Of course it matters that you choose a sensible (i.e. reasonably short) name for your namespace,
> and not something like MatsLibraryForCpp.
¿rationale?
Remember that you can do namespace a = overly_long::and::nested;


@coder777: ¿why few functions?

[Mats]

@coder777: Why not variables?

[Disch]

Global variables are bad

[Mats]

I hear the globals are bad mantra a lot, but in this case, I have about 15 variables, used by almost every function in the header, all placed in a namespace. Placing them in a namespace avoids naming conflicts, having them global avoid passing 15 variables around functions. I can hardly see there being performance issues with having these variables global, since they are so few. So what is the reasoning here for me passing all these variables from function to function for the entire header file?

[ne555]

The problem is not performance, but maintenance.

[JLBorges]

> I have about 15 variables, used by almost every function in the header


Variables at namespace scope are not bad per se; it is tight coupling between components that we should strive to minimize.

1. For variables that do not form the logical interface of the component, but are required by many functions of the component:

a. Do not declare them in the header.
b. Define them with internal linkage in the implementation file.


2. For variables that form the logical interface of the component, but are deemed immutable in the iterface:

a. Declare const references to them in the header.
b. Define the actual mutable variables with internal linkage in the implementation file.
c. Define the const references with external linkage in the implementation file.


3. For variables that do form the logical interface of the component, do just you are doing; ie. what the standard library does with standard streams (std::cout and friends).


For cases 2. and 3., you would also need to ensure that these variables are initialized prior to their first use.

Similar considerations would apply to static member variables of classes; they are like variables at namespace scope.

[Disch]

I hear the globals are bad mantra a lot, but in this case, I have about 15 variables, used by almost every function in the header, all placed in a namespace. Placing them in a namespace avoids naming conflicts, having them global avoid passing 15 variables around functions.

It's difficult to say for sure without knowing what it is these variables and functions do... but it sounds like maybe this would be better written as a class.

If you don't mind, can you elaborate more on what these functions/variables are? This is mostly just for my own curiosity.

[Duthomhas]

Quick and easy way to understand headers and source files, and what you should/shouldn't do in each with respect to namespaces:
http://www.cplusplus.com/forum/general/13162/#msg63354

Global variables aren't as evil as everyone says -- but they need to have a good reason for being global.

The problem is that the larger your project, the more difficult it is to maintain modularity with global variables.

[coder777]

ne555 wrote:

¿why few functions?

because unorganized functions (outside struct or class) defys the thought of structured programming. Some minor helper function are allowed though

Mats wrote:

I have about 15 variables

That's a disaster. The more code you produce the more painful they will get.

Mats wrote:

having them global avoid passing 15 variables around functions

functions that requires 15 variables from outside is a major desing fault...

[ne555]

I wonder what you understand by `structured programming' http://en.wikipedia.org/wiki/Structured_programming

About why to prefer non-member non-friend functions
http://www.gotw.ca/gotw/084.htm
http://nova.polymtl.ca/~simark/Eff/Effective/0321334876/ch04lev1sec6.html

[Catfish666]

@ ne555: he probably meant OOP instead.

[Mats]

This was a very helpful thread. It's too far along to change (lazy me) how I did this particular header, but I think the next kind of thing like this I do, I now know what I'm doing and the entire design will be very different. Thanks! ^_^