Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net