Na realizację std :: swapa pod względem przypisania ruchu i poruszać konstruktora

Question

Tu jest możliwe określenie std::swap:

template<class T> 
void swap(T& a, T& b) { 
    T tmp(std::move(a)); 
    a = std::move(b); 
    b = std::move(tmp); 
} 

wierzę, że

1. std::swap(v,v) gwarantuje nie mają skutków i
2. std::swap można zaimplementować jak wyżej.

Poniższy cytat wydaje mi się sugerować, że te przekonania są sprzeczne.

17.6.4.9 Argumenty funkcji [res.on.arguments]

1 Każdy z poniższych odnosi się do wszystkich argumentów do funkcji zdefiniowanych w C++ biblioteki standardowej, o ile wyraźnie nie zaznaczono inaczej.

...

• Jeśli argumentem funkcji wiąże się z parametrem odniesienia rvalue, implementacja może zakładać, że parametr ten jest unikalnym odniesienie do ten argument. [Uwaga: Jeśli parametr jest parametrem generycznym postaci T & & i l wartość typu A jest powiązany, argument jest powiązany z wartością odniesienia o wartości l (14.8.2.1) i dlatego nie jest objęty poprzednim zdaniem . - nota końcowa] [Uwaga: Jeśli program rzuci wartość l do wartości o wartości , przekazując tę ​​lwartośc do funkcji bibliotecznej (np. Przez wywołanie funkcji z argumentem move (x)), program jest skutecznie prosząc tę ​​funkcję do traktuj tę lwartość jako tymczasową. Implementacja jest bezpłatna, aby zoptymalizować kontrole aliasingu z zewnątrz, które mogą być potrzebne, jeśli argument był l-wartości. -endnote]

(dzięki Howard Hinnant dla providing the quote)

Niech v być przedmiotem pewnego rodzaju ruchomego pobranej od Standard Template Library i rozważyć połączenie std::swap(v, v). W powyższej linii a = std::move(b); jest to przypadek wewnątrz T::operator=(T&& t), który jest , więc parametr to , a nie unikalne odniesienie. Jest to naruszenie powyższego wymogu, więc linia a = std::move(b) wywołuje niezdefiniowane zachowanie po wywołaniu z std::swap(v, v).

Jakie jest wyjaśnienie tutaj?

Answer 1

Uważam, że nie jest ważne, ponieważ definicja std::swapstd::swap definiuje wziąć lwartości referencje, a nie referencje rvalue (20.2.2 [utility.swap])

Answer 2

Następnie wyrażenie a = std::move(b); zostanie wykonany, celem jest już puste, w stanie, w którym tylko zniszczenie jest dobrze zdefiniowane. To będzie skutecznie no-op, ponieważ obiekt po lewej i prawej stronie jest już pusty.Stan obiektu po ruchu jest nadal nieznany, ale możliwy do zniszczenia. Następna instrukcja przenosi zawartość z powrotem z tmp i przywraca obiekt do znanego stanu.

Answer 3

[res.on.arguments] to oświadczenie o tym, jak klient powinien używać std :: lib. Kiedy klient wysyła xvalue do funkcji std :: lib, klient musi chcieć udawać, że xvalue jest naprawdę wartością pryncypalną i oczekiwać, że std :: lib to wykorzysta.

Jednak, gdy klient wywołuje std :: swap (x, x), klient nie wysyła wartości x do funkcji std :: lib. Jest to implementacja, która robi to zamiast tego. W związku z tym obowiązkiem jest wykonanie operacji std :: swap (x, x).

W związku z powyższym, std daje podmiotowi wdrażającemu gwarancję: X musi spełnić MoveAssignable. Nawet jeśli w stanie przeniesionym, klient musi upewnić się, że X jest MoveAssignable. Co więcej, implementacja std::swap nie obchodzi, co robi samo-ruch-przydział, o ile nie jest niezdefiniowanym zachowaniem dla X. o ile nie ulega awarii.

a = std::move(b); 

Gdy & a == & b, zarówno źródło i cel tego zadania ma wartość nieokreśloną przemieszczające (z). Może to być operacja "no-op" lub inna czynność. Dopóki nie ulega awarii, std :: swap będzie działał poprawnie. To dlatego, że w następnym wierszu:

b = std::move(tmp); 

Cokolwiek wartość wszedł a z poprzedniego linia zostanie podana nowa wartość z tmp. I tmp ma oryginalną wartość a. Więc oprócz nagrywania wielu cykli procesora, swap(a, a) jest bez op.

Aktualizacja

latest working draft, N4618 została zmodyfikowana tak, aby jednoznacznie stwierdzić, że w wymogami MoveAssignable wyrażenie:

t = rv 

(gdzie rv jest rvalue) t musi być tylko ekwiwalent wartości rv przed przypisaniem, jeśli t i rv nie odnoszą się do tego samego obiektu. I niezależnie, stan rv jest nieokreślony po przypisaniu. Istnieje dodatkowa uwaga do dalszego wyjaśnienia:

rv musi nadal spełniać wymagania składnika biblioteki, który używa go, czy nie t i rv odnoszą się do tego samego obiektu.

Answer 4

zgadzam się z analizą, aw rzeczywistości libstdC++ Debug Mode ma twierdzenie, że będzie ogień na siebie zamiany standardowych kontenerach:

#include <vector> 
#include <utility> 

struct S { 
    std::vector<int> v; 
}; 

int main() 
{ 
    S s; 
    std::swap(s, s); 
} 

typu wrapper S jest potrzebna, ponieważ zamiana wektor bezpośrednio używa specjalizacji, która wywołuje vector::swap() i dlatego nie używa generycznego std::swap, ale S użyje standardowego, a gdy skompiluje się jako C++ 11, który spowoduje automatyczne przypisanie elementu wektora, co spowoduje przerwanie :

/home/toor/gcc/4.8.2/include/c++/4.8.2/debug/vector:159:error: PST. 

Objects involved in the operation: 
sequence "this" @ 0x0x7fffe8fecc00 { 
    type = NSt7__debug6vectorIiSaIiEEE; 
} 
Aborted (core dumped) 

(Nie wiem, co ma znaczyć "PST"! Myślę, że coś jest nie tak z instalacją, z którą ją przetestowałem.)

Uważam, że zachowanie GCC jest zgodne, ponieważ standard mówi, że implementacja może zakładać, że samo-przenoszenie nigdy nie ma miejsca, dlatego twierdzenie nigdy nie zawiedzie w ważnym programie.

Jednak zgadzam się z Howardem, że to musi zadziałać (i można z niego pracować bez większych problemów - dla libstdC++ musimy tylko usunąć asercję trybu debugowania!), Więc musimy naprawić standard zrobić wyjątek dla samoprzeciągania się, a przynajmniej samodmiany. Od pewnego czasu obiecuję napisać artykuł na ten temat, ale jeszcze tego nie zrobiłem.

Sądzę, że od czasu napisania jego odpowiedzi, Howard zgadza się, że jest problem z obecnym brzmieniem normy, i musimy to naprawić, aby zabronić libstdC++ w tworzeniu tego twierdzenia, które zawodzi.