This is the mail archive of the
mailing list for the GCC project.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
2012/3/19 Jonathan Wakely <email@example.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
>>> 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.