This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Second GCC 4.7.0 Release Candidate available from

2012/3/19 Jonathan Wakely <>:
> 2012/3/19 Jonathan Wakely <>:
>> 2012/3/19 PaweÅ Sikora:
>>> On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
>>>> GCC 4.7.0 Release Candidate available from
>>>> A second release candidate for GCC 4.7.0 is available from
>>>> Â
>>>> and shortly its mirrors. ÂIt has been generated from SVN revision 185376.
>>>> I have so far bootstrapped and tested the release candidate on
>>>> x86_64-linux. ÂPlease test it and report any issues to bugzilla.
>>> i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
>>> #include <boost/shared_ptr.hpp>
>>> #include <map>
>>> #include <string>
>>> typedef boost::shared_ptr<std::string> HString;
>>> typedef std::map<std::string,HString> StrAttribsT;
>>> StrAttribsT m_str_attribs;
>>> void foo(const char* attribName, const char* value)
>>> {
>>> Â Â Â Âm_str_attribs.insert(std::make_pair(attribName, new std::string(value)));
>>> }
>>> it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
>>> is it an effect of 'name lookup changes'? (
>> No, the change is in how std::pair is constructed, the code can be reduced to:
>> #include <boost/shared_ptr.hpp>
>> #include <string>
>> typedef boost::shared_ptr<std::string> HString;
>> void foo(const char* attribName)
>> {
>> Â Âconst std::pair<const std::string, HString> a
>> Â Â Â Â= std::make_pair(attribName, new std::string);
>> }
>> Probably caused by
>> I haven't looked in enough detail to see if the change in behaviour is
>> correct or a regression.
> My guess is that the new behaviour is correct, because the relevant
> constructor of boost::shared_ptr is 'explicit' but you're relying on
> an implicit conversion from pair<const char*, string*> to
> pair<std::string, shared_ptr<string>> which implicitly converts a raw
> pointer to a shared_ptr.

Indeed, in [pairs.pair] the standard says:

template<class U, class V> pair(const pair<U, V>& p);
-11-  This constructor shall not participate in overload resolution
unless const U& is implicitly convertible to first_type and const V&
is implicitly convertible to second_type.

So the new behaviour is required, your code is invalid.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]