I typically use one of the two ways.
- First way is to
typedef at the place-of-first-declaration.
- Second way is to
typedef at each place-of-use, and make it only visible to that place-of-use (by putting it inside the class or method that uses it).
(1) Put the typedef close to the type that is being wrapped.
/* MyAttrType.h */
#include <Optional.h>
// README : See Optional<MyAttrType> at the end of this header
struct MyAttrType
{
// ....
};
// (put the typedef here)
typedef Optional<MyAttrType> OptionalMyAttrType;
/* ---------------------------- */
/* Every other C++ source files */
#include "MyAttrType.h"
// .... Any code can use OptionalMyAttrType there.
(2) Make the typedef visible only to each class that uses it.
/* MyAttrType.h */
namespace my_pod_types
{
struct MyAttrType { /* ... */ };
}
// (nothing else outside.)
/* ---------------------------- */
/* Every other C++ source files */
#include "MyAttrType.h"
#include "Optional.h"
class MyClassX
{
private:
typedef Optional<my_pod_types::MyAttrType> OptionalMyAttrType;
public:
// ...
private:
OptionalMyAttrType m_optAttr;
};
Most of the time, the template relevant to me is either std::unique_ptr and std::shared_ptr. Furthermore, I will just decide that a class will either use one way or the other, and then typedef that smart pointer wrapper as "MyClassOnePtr". Draconian, but a library's main author is supposed to know what is the best for the library most of the time.
If it is not obvious which one of the two smart pointers should be preferred, then I will not put the typedef in the first header (so, I won't use option #1 unless the choice is obvious.)
Most of the time, you will realize that option #2 does not always shield the use of Optional<T> from the end-user. That is, the application logic may require users of MyClassX to deal with Optional<T> when interacting with it. When that happens, you can't hide it anymore. It is not an implementation detail; it is part of the visible surface.
Finally, you should be aware of the C++ limitation to forward-declare things. Namely, there are times where C++ needs to know up-front:
- Size of the type being wrapped;
- Existence of a default constructor and destructor;
- And so on.
See this question on Stackoverflow (about unique::ptr) for examples of such limitations.
Another unrelated thing I would like to share, after reading ixrec's answer.
I started following a "nothing in the default namespace" policy after finding that you can't get Doxygen (a widely used C++ documentation to HTML generator) to generate well-organized documentation unless you categorize your classes by using namespaces. It seems it doesn't matter how you name those namespaces; as long as Doxygen sees them as distinct, and human users don't complain about it, any namespacing approach will be fine.
