|
Boost Users : |
Subject: Re: [Boost-users] conflicting intmax_t definitions - Boost 1.53 and gcc 4.8 incompatibility?
From: Nate Finch (nate.finch_at_[hidden])
Date: 2014-01-21 14:23:50
For what it's worth, I agree 100%. It's a problem in many languages have,
and it's constantly a battle to prevent people from taking the "easy" way
out that happens to also be really dangerous in practice.
For what it's worth, it's not my code originally, so I take no
responsibility for how it was written. At least it's a fairly easy thing
to clean up... just remove the using statement and see where the code falls
over during compilation, and insert an explicit namespace.
On Tue, Jan 21, 2014 at 10:20 AM, John M. Dlugosz
<ngnr63q02_at_[hidden]>wrote:
> On 1/20/2014 6:32 AM, Nate Finch wrote:
>
>> Yes, there are some using namespace boost statements, and some of them
>> are before some
>> includes... but why would that suddenly break when it was working before
>> I upgraded? Is
>> boost now defining its own intmax_t (and other such tings, like uint64_t)
>> where it wasn't
>> before?
>>
>
> Because that's what 'using directives' ("using namespace XXX;") are for:
> to break builds by surprise and cause strange compatibility problems.
>
> Any change to the XXX namespace will change the symbols seen by the
> importer, and that may cause ambiguities (if you're lucky -- they are
> caught by the compiler) or unintended bizarre calls of the wrong function
> you didn't even know about (esp. when templates are involved).
>
> 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).
>
>
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
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