2012/3/19 Jonathan Wakely <jwakely....@gmail.com>: > 2012/3/19 Jonathan Wakely <jwakely....@gmail.com>: >> 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 gcc.gnu.org >>>> >>>> A second release candidate for GCC 4.7.0 is available from >>>> >>>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314 >>>> >>>> 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'? >>> (http://gcc.gnu.org/gcc-4.7/porting_to.html) >> >> 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 http://gcc.gnu.org/viewcvs?view=revision&revision=174464 >> >> 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.
