Le 21/01/14 23:31, Gavin Lambert a écrit :
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". Hi,
I think this is the way to go. Import them in your specific "app" namespace.
Also both of these ideas have interop problems, eg. trying to pass a boost::container::string to a third-party library that's expecting a std::string. Or worse, std::shared_ptr vs. boost::shared_ptr (as AFAIK there is no way to interop these without copying the underlying object, which breaks the semantics).
Well, importing them to the global namespace doesn't work better. If you must use a 3pp library that has a std::shared_ptr in the interface you must use a std::shared_ptr on your application at least for this interface and you must not try to hide this in your code. The use of a specific namespace is useful only to move from one implementation to the other internally in a transparent way. Best, Vicente