On 21/01/14 23:31, Gavin Lambert wrote:
On 22/01/2014 04:27, Quoth Leon Mlakar:
On 21/01/14 16:20, John M. Dlugosz wrote:
Don't dump somebody else's namespace into your work willy-nilly. If they are not maintained together, it's just wrong. Use using declarations for individual symbols, declaring just the ones you need (and are thus aware of).
Or alternatively avoid using "using" and use fully qualified names (e.g. boost::intmax_t) - there's nothing wrong with this, either.
I'm of two minds about this one, actually. This is the path I've usually taken thus far, but I've had a few cases where I've wanted to change my mind about which class was actually being used (eg. to move from boost::x to std::x or vice versa, or a redirector that eg. attaches a custom allocator to STL containers by default, or even a custom reimplementation of something).
So far swapping these over requires a Replace in Files. This is kinda good because everything is more explicit and it's more obvious when you're looking at code that is trying to pass a std::shared_ptr to something that accepts a boost::shared_ptr (for example), but such blanket replacements offend my "define things in one place" instincts.
I've been wondering if a better strategy might be to explicitly typedef or "using" the versions I want into the global namespace (or an "app" namespace) in a common header and then use those everywhere instead. Though this is fragile against a misplaced "using namespace".
For some time now I'm advocating against importing entire namespace via "using namespace" ... I've seen too many defects caused by misplaced directives. Rather I prefer importing specific symbols, or if that is of little benefit, using fully qualified name. Especially these days when, as you pointed out, ambiguities like boost::shared_ptr and std::shared_ptr can cause terrible mess if it's not obvious which one is used, and for these even importing symbols may not be a good idea. But your suggestion it the last paragraph is intriguing if combined with using type aliases and explicit namespace for symbols used in applications - something like mytypes::shared_ptr or appdef::string ... it is just a soft of half-baked idea at the moment, For now I'm still scratching at the surface of C++11, but we did use type aliases in past C# projects, and the C++ seem to have the advantage of allowing aliases for template classes. I'll give this some thought in the future. I really wonder what sorts of patterns will emerge from this. Leon