[Bug c++/78011] New: Compiler error when initializing a member of template type where the second template argument is a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78011
Bug ID: 78011
Summary: Compiler error when initializing a member of template
type where the second template argument is a typedef
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.stanimirov at abv dot bg
Target Milestone: ---
Repro:
typedef int int32;
struct foo
{
std::map bar = std::map{};
};
If the initialization is removed, or if it's in a function and not in a class,
it compiles fine.
Live demo: http://ideone.com/8hWLnn
[Bug libstdc++/98473] New: std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473
Bug ID: 98473
Summary: std::vector::insert(pos, first, last) doesn't
compile for T which has a deleted assignment operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.stanimirov at abv dot bg
Target Milestone: ---
Create a class `X` which is copy-constructible but not copy-assignable
```
struct X {
X();
X(const X&);
X& operator=(const X&) = delete; // !!
X(X&&) noexcept;
X& operator=(X&&) noexcept;
int data = 54;
};
```
Have vectors of X `a` and `b`. Try to add all elements of b at the front of a:
```
void add_to_front(std::vector& a, const std::vector& b) {
a.insert(a.begin(), b.begin(), b.end());
}
```
Live demo: https://godbolt.org/z/K1WT8n
It doesn't compile. My guess is that code which will never get invoked, still
needs to compile (or, worse yet, copy assignment does get invoked?!)
The only way to achieve the desired behavior efficiently is to use a custom
vector implementation. There is a stackoverflow question which has some
workarounds *with worse performance*:
https://stackoverflow.com/questions/65489039/how-to-efficiently-insert-multiple-copy-constructible-but-not-copy-assignable-el
This does compile and work on msvc, so a compile-time check for the
copy-assignment code is possible.
As pointed out in the stackoverflow thread, copy-assignability is not listed
here: https://en.cppreference.com/w/cpp/container/vector/insert#Parameters
This looks like a bug in libstdc++ (as opposed to a omission by the standard)
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473 --- Comment #2 from Borislav Stanimirov --- (In reply to Jonathan Wakely from comment #1) > To meet the requirements of the standard we would need to insert them at the > end and then use std::rotate to reposition them. Or, to save move assignments, first "make a hole" and then copy-construct b's in place (some destructors of moved-out objects) will have to be called. > > I see that libc++ has the same behaviour as libstdc++, which does make me > think the standard is wrong to require this (since it doesn't reflect > reality). I'll have to check the history of the standard. > I reported the same issue there too: https://bugs.llvm.org/show_bug.cgi?id=48619 > > This does compile and work on msvc, so a compile-time check for the > > copy-assignment code is possible. > > No, you can't check that at compile time. It's a dynamic condition. > Presumably MSVC uses std::rotate instead so no check is needed. You definitely can check whether the class has a copy assignment operator and then, based on that, choose either the current implementation or one which doesn't invoke it (rotate or other)
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473 --- Comment #3 from Borislav Stanimirov --- By the way, this is not just some esoteric synthetic example. A type which is copy-constructible but not copy-assignable is very useful to model immutable objects.
[Bug libstdc++/108714] New: Algorithms in require predicates to be copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108714
Bug ID: 108714
Summary: Algorithms in require predicates to be
copyable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.stanimirov at abv dot bg
Target Milestone: ---
Simple repro:
```
#include
#include
struct noncopyable {
noncopyable();
noncopyable(const noncopyable&) = delete;
noncopyable(noncopyable&&) noexcept = default;
template
bool operator()(const T&);
};
bool all_of_vec(const std::vector& vec) {
return std::all_of(vec.begin(), vec.end(), noncopyable{});
}
```
This does not compile, because the predicate to `all_of` is not copyable. The
same error appears for all other algorithms which allow a predicate.
It does compile and work and expected with Microsoft STL and with libc++
Live demo showing compilation errors with libstdc++ and successful compilation
with libc++ and Microsoft STL: https://godbolt.org/z/xaa35G35e
[Bug libstdc++/108118] New: std::weak_ptr lacks a self-usurp check on move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108118 Bug ID: 108118 Summary: std::weak_ptr lacks a self-usurp check on move Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: b.stanimirov at abv dot bg Target Milestone: --- If one somehow move-assigns a weak pointer to itself, it gets destroyed. Demo: https://godbolt.org/z/eWdhYMhYe
