Keeping types and functions in separate namespaces
in [C++]
|
Prev: Can I use overloading for optional parameters?
Next: ANNOUNCE: UPCRC Illinois Summer School on Multicore Programming
From: Alexander Lamaison on 30 Mar 2010 02:28 Something that has been troubling me for a while: The current wisdom is that types should be kept in a namespace that only contains functions meant to be part of their non-member interface (see C++ Coding Standards [Sutter, Alexandrescu] or here http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1893.pdf) to prevent ADL pulling in unrelated definitions. Does this imply that *all* classes must have a namespace of their own? If we assume that a class may be augmented in the future by the addition of non-member functions, then it can never be safe to put two types in the same namespace as either one of them may introuduce non-memeber functions that could interfere with the other. The reason I ask is that namespaces are becoming cumbersome for me. I'm writing a header-only library and I find myself using classes names such as project::component::class_name::class_name. Their implementations call helper functions but as these can't be in the same namespace they also have to be fully qualified! Any insight or advice is greatly appreciated. Alex Lamaison --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 31 Mar 2010 12:03 Alexander Lamaison wrote: > Something that has been troubling me for a while: > > The current wisdom is that types should be kept in a namespace that only > contains functions meant to be part of their non-member interface (see C++ > Coding Standards [Sutter, Alexandrescu] or here > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1893.pdf) to > prevent ADL pulling in unrelated definitions. > > Does this imply that *all* classes must have a namespace of their own? I'm just thinking loud now, I may be wrong since it's 2 am in the morning here. I guess that what they say is not that you must give the class and its non-member functions an own namespace, but rather that you should not place the class in a /separate/ namespace than the non-member functions. > If > we assume that a class may be augmented in the future by the addition of > non-member functions, then it can never be safe to put two types in the > same namespace as either one of them may introuduce non-memeber functions > that could interfere with the other. > But isn't it so that most often a non-member function takes the class it belongs to as a parameter, hence name clashes may be rare. > The reason I ask is that namespaces are becoming cumbersome for me. I'm > writing a header-only library and I find myself using classes names such as > project::component::class_name::class_name. Their implementations call > helper functions but as these can't be in the same namespace they also have > to be fully qualified! > > Any insight or advice is greatly appreciated. > > Alex Lamaison > > --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alexander Lamaison on 31 Mar 2010 23:17
On Wed, 31 Mar 2010 21:03:51 CST, DeMarcus wrote: > Alexander Lamaison wrote: >> Something that has been troubling me for a while: >> >> The current wisdom is that types should be kept in a namespace that only >> contains functions meant to be part of their non-member interface (see C++ >> Coding Standards [Sutter, Alexandrescu] or here >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1893.pdf) to >> prevent ADL pulling in unrelated definitions. >> >> Does this imply that *all* classes must have a namespace of their own? > > I'm just thinking loud now, I may be wrong since it's 2 am in the morning here. > > I guess that what they say is not that you must give the class and its > non-member functions an own namespace, but rather that you should not > place the class in a /separate/ namespace than the non-member functions. They do say that but they also make a whole seperate point about not keeping unrelated functions in the same namespace as a type. >> If >> we assume that a class may be augmented in the future by the addition of >> non-member functions, then it can never be safe to put two types in the >> same namespace as either one of them may introuduce non-memeber functions >> that could interfere with the other. >> > > But isn't it so that most often a non-member function takes the class it > belongs to as a parameter, hence name clashes may be rare. This is true but apparently that still screws up ADL. I think ADL can pull in a function with the same name as the one its looking for instead of the one it actually wants but fail to compile as the parameters are incompatible. Alex --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |