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.
