Re: [boost] GCC 4.6.x + Boost.Signals == failure

Subject: Re: [boost] GCC 4.6.x + Boost.Signals == failure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-06 20:07:34

AMDG

On 2/6/2011 4:31 PM, Bryce Lelbach (wash) wrote:
> On Sat, 5 Feb 2011 01:20:39 -0800 (PST)
> Vicente Botet<vicente.botet_at_[hidden]>  wrote:
>
>> BTW, no errors for Boost.Signal in last report rev 68358.
>
> Right. No errors, because there is no tester for the broken environment :)
>
>> Which version of Boost.Signals fails?
>
> The last change on the broken file in question was about a year ago. So, I'd say
> any version from about a year ago till now compiled against recentish built
> GCC 4.6.x
>
> Find attached a patch for this bug. The problem: GNU stdlib failure or GNU
> stdlib failure compounded by GCC failure. Passing a parameter of type
> std::map<>::iterator to std::map<>::erase() is ambigious for silly reasons.
> Definitions for std::map<>::erase() in the GNU stdlib are provided for
> std::map<>::key_type const&  and std::map<>::const_iterator, if c++0x support is
> enabled (which apparently seems to be just the "default" state of GCC these
> days). If c++0x support is disabled, the working C++99 std::map<>::erase()
> which takes an std::map<>::iterator is enabled (in C++0x, erase()'s return type
> changes from void to iterator).
>

a) Please check defined(__GNUC__) first to avoid warnings
b) __GNUC__ >= 4 && __GNUC_MINOR__ >= 6 is a little
    silly, since it will be false for gcc 5.0.
c) Will the patch work when C++0x support is disabled?

In Christ,
Steven Watanabe