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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-21 18:30:05

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