[Bug c++/85970] New: Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970
Bug ID: 85970
Summary: Cannot move a std::unique_ptr to insert into a map
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.dapena at lge dot com
Target Milestone: ---
Created attachment 44206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44206&action=edit
Test case
Trying to insert to an std::map with value type std::unique_ptr using a move to
the initializer list fails:
std::map> map;
std::string str = "a";
std::unique_ptr a = std::make_unique();
// This fails
map.insert({str, std::move(a)});
But, if instead of this we do:
map.insert(std::pair>(str, std::move(a)));
It works.
This is working in LLVM libc++.
The error we get is related to trying to use the copy contructor of std::pair
and std::unique_ptr:
/usr/include/c++/7/ext/new_allocator.h:136:4: error: use of deleted function
‘std::pair<_T1, _T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~
In file included from /usr/include/c++/7/bits/stl_algobase.h:64:0,
from /usr/include/c++/7/bits/stl_tree.h:63,
from /usr/include/c++/7/map:60,
from main.cc:1:
/usr/include/c++/7/bits/stl_pair.h:292:17: note: ‘std::pair<_T1,
_T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’ is implicitly
deleted because the default definition would be ill-formed:
constexpr pair(const pair&) = default;
^~~~
/usr/include/c++/7/bits/stl_pair.h:292:17: error: use of deleted function
‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with
_Tp = A; _Dp = std::default_delete]’
In file included from /usr/include/c++/7/memory:80:0,
from main.cc:2:
/usr/include/c++/7/bits/unique_ptr.h:388:7: note: declared here
unique_ptr(const unique_ptr&) = delete;
^~
[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970 Jose Dapena Paz changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Jose Dapena Paz --- Though I reported to gcc, it seems it is actually related to the libstdc++ library. GCC properly compiles this code using LLVM libc++.
[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970 Jose Dapena Paz changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Jose Dapena Paz --- Confirmed it is already fixed in 7.3.0. Also, the original bug report addresses the same problem. Thanks!
[Bug libstdc++/90857] New: stl::forward_list::erase_after crashes if __pos == __last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90857 Bug ID: 90857 Summary: stl::forward_list::erase_after crashes if __pos == __last Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jose.dapena at lge dot com Target Milestone: --- Created attachment 46483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46483&action=edit Test case In case we invoke erase_after with __pos == __last, then it will crash, as first thing erase_after implementation does is pointing to __pos next element, then it iterates comparing that element to __last. As at that point the current pointer will be already after __last, it will crash. As far as I know, the specification does not really say this is a valid case. But still it seams fair to at least check this case and make erase_after no-op in this case (just returning an iterator pointing to the same node __pos points too). This is the behavior in LLVM libc++.
[Bug c++/84709] New: Cannot define method with same name of previously using declared class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84709
Bug ID: 84709
Summary: Cannot define method with same name of previously
using declared class
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.dapena at lge dot com
Target Milestone: ---
This test case is failing with g++ 7.3.0:
namespace A {
class Foo {
...
};
}
using A::Foo
namespace B {
class Bar {
const Foo &Foo() const {
...
}
}
The declaration of B Foo accessor fails because it "changes meaning" of A::Foo.
But as far as I could check in C++14 standard, this should be covered by
basic.scope.hiding/2 right?
[Bug c++/84709] Cannot define method with same name of previously using declared class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84709 --- Comment #2 from Jose Dapena Paz --- OK, just for understanding all the edges of this... So the fact that in namespace B A::Foo the full A::Foo name is still accessible is not relevant right?
[Bug c++/84849] New: Ambiguous resolution of braze initializer list to a class with explicit copy/move constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
Bug ID: 84849
Summary: Ambiguous resolution of braze initializer list to a
class with explicit copy/move constructors
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.dapena at lge dot com
Target Milestone: ---
Created attachment 43644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43644&action=edit
Test case
For a template class with explicit copy and move constructors, passing a
std::vector of std::string using initializer list syntax fails because of geing
ambiguous.
Attached test example.
main.cc: In function ‘int main(int, char**)’:
main.cc:22:62: error: call of overloaded ‘Foo()’ is ambiguous
static Foo> vector({"a", "b", "c"});
^
main.cc:14:3: note: candidate: Foo::Foo(const Foo&) [with T =
std::vector >]
Foo(const Foo&) = delete;
^~~
main.cc:12:12: note: candidate: Foo::Foo(T&&) [with T =
std::vector >]
explicit Foo(T&& x) { }
^~~
main.cc:11:12: note: candidate: Foo::Foo(const T&) [with T =
std::vector >]
explicit Foo(const T& x) { }
This test case works properly on clang (it resolves to the move constructor.
