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: Leon Mlakar (leon_at_[hidden])
Date: 2014-01-21 18:44:33

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