Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Pavol Droba wrote:
If there would be just one boost::algorithm and everything inside it, than aliasing would work just fine. But imagine having
namespace algo=boost::algorithm; namespace sa=boost::algorithm::string; namespace ca=boost::algorithm::container;
It is easy to get lost in such a lot of namespace. One would have to look into the docs to see which algoritm lies in which namespace. It could realy be painful.
I think the subnamespaces are a bad idea. I suggest that
#include <boost/algorithm/string.hpp> - Includes all string algorithms, in namespace boost::algorithm
#include <boost/algorithm/container.hpp> - Includes all container algorithms, in namespace boost::algorithm
#include <boost/algorithm.hpp> - Includes all boost/algorithm/* and imports them all into namespace "boost" with using declarations.
I am concerned about the name of an algorithm in the generalized boost::algorithm namespace not reflecting the fact that the algorithm refers to strings or containers. Of course I am aware that overloading will allow different algorithms which have the same name to refer to different objects, but still a fairly generalized name may not create a specific enough mnemonic for me, as an end-user, to be comfortable enough with, to know that the algorithm refers to string(s) or container(s). OTOH having the algorithm in the boost::algorithm::string or boost::algorithm::container namespace tells me that the algorithm is string-centric or container-centric, and then the generalized name for the algorithm bothers me less because I will always be invoking it by specifying the full namespace ( or namespace alias ) name. This is purely an aesthetic reaction, and the fact that I like generalized names for free-standing functions ( and function templates ) which reflect the action but specific namespaces which tell me to what the action might refer, more than I like generalized names in the same namespace referring to very different objects and actions upon them.