Re: [Boost-users] conflicting intmax_t definitions - Boost 1.53 and gcc 4.8 incompatibility?

Subject: Re: [Boost-users] conflicting intmax_t definitions - Boost 1.53 and gcc 4.8 incompatibility?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-01-21 17:31:57

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".

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).