Nested namespaces, correct static library design issues

Question

Hello all,

I'm currently in the process of developing a fairly large static library which will be used by some tools when it's finished. Now since this project is somewhat larger than anything i've been involved in so far, I realized its time to think of a good structure for the project. Using namespaces is one of those logical steps.

My current approach is to divide the library into parts (which are not standalone, but their purpose calls for such a separation). I have a 'core' part which now just holds some very common typedefs and constants (used by many different parts of the library). Other parts are for example some 'utils' (hash etc.), file i/o and so on. Each of these parts has its own namespace. I have nearly finished the 'utils' part and realized that my approach probably is not the best. The problem (if we want to call it so) is that in the 'utils' namespace i need something from the 'core' namespace which results in including the core header files and many using directives.

So i began to think that this probably is not a good thing and should be changed somehow. My first idea is to use nested namespaces as to have something like core::utils. Since this will require some heavy refactoring i want to ask here first. What do you think? How would you handle this? Or more generally: How to correctly design a static library in terms of namespaces and code organization? If there are some guidelines or articles about it, please mentoin them too. Thanks.

Note: i'm quite sure that there are more good approaches than just one. Feel free to post your ideas, suggestions etc. Since i'm designing this library i want it to be really good. The goal is to make it as clean and FAST as possible. The only problem is that i will have to integrate a LOT of existing code and refactor it, which will really be a painful process (sigh) - thats why good structure is so important)

Answer 1

Well, I would think that in the core.h header, you would have stuff like

#include <string>
#include <iostream>
namespace core
{
    typedef std::string mystring;
    #define mycout std::cout
}

And not one using directive, to prevent contaminating the global namespace. In a utils.h header, you would use stuff like:

#include "core.h"
namespace utils
{
    core::mystring stringfunction(core::mystring &stuff)
    {
        core::mystring result;
        // do stuff
        return result;
    }
}

Hence, there is no mystring anywhere, except in core::. It involves a bit more typing, but that's what namespaces are for, letting yourself know where you're getting the type/function/class from.

UPDATE

The other side of the story is something like this:

core.h header declaring stuff in core namespace like above.

utils.h header declaring stuff in core::utils namespace, and after that a namespace utils = core::utils statement. This makes the two approaches identical to the user, and allows you to write stuff like mystring instead of core::mystring in the utils*.h headers and *.cpp files.

Something like this for a utils.h:

#include "core.h"
namespace core
{
    namespace utils
    {
        mystring stringfunction(mystring &stuff)
        {
            mystring result;
            // do stuff
            return result;
        }
    }
}
namespace utils = core::utils; // allow user to type utils::stringfunction

This cleans up user- and library code a bit.

Answer 2

My own approach is to use one single namespace per library. I don't think nested namespaces bring anything to the party, unless you like typing (on the keyboard). This has worked for me with zero problems.