[cfe-dev] Issue with map and unordered_map: call to deleted constructor of 'std::pair<const int, int>'

[Matthieu Monrocq]

>
> > On further further investigation (& getting to what I think is the code
> > that's generating this - and, helpfully, quotes the standard that
> supports
> > it) I believe this is by design & libstdc++ has a bug.
> > The relevant portion of the standard is 12.8[class.copy] paragraph 7:
> >     ... If the class definition declares a move constructor or move
> > assignment operator, the implicitly declared copy constructor
> > is defined as deleted; otherwise, it is defined as defaulted. ...
> > libstdc++'s std::pair should be defining the move/copy ctors/assignment
> > operators (there's similar clauses for all these implicit definitions)
> > explicitly if it wants to define the move assignment operator explicitly.
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=174464 changed some
> things around here in May. Does it fix the bug you're looking at? It's
> not in the gcc-4.6.x release branch, but we may be able to convince
> them to include it in a future 4.6 release.
>
>
> [Miles: sorry about that, I'm checking your bug/repro now, but I'd hazard
> > it's the same thing & a bug in boost rather than clang. I'll update when
> > I've looked at it some more]
> >
>

Thanks David for investigating!

I had examined the constructors defined for pair but unfortunately skipped
the assignment operators deeming they would have no influence :/

I was wondering if it could be a bug in libstdc++ since gcc 4.5.2 is quite
old with regard to the FDIS and I recall things moved (!) a bit on this
side.

Thanks Jeffrey for digging in the bug report about gcc.

I'm going to try and check libc++, it's a no dependency projects so should
not be too complicated.

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110918/caba11ee/attachment.html>