Czy istnieje powód, dla którego unique_ptr::reset
nie ma przeciążeń, które mają const deleter&
i deleter&&
, aby dopasować konstruktory, które przyjmują je jako drugi argument?Dlaczego wyjątki unique_ptr :: reset nie mają przeciążenia, które powodują deleter?
Zapisany deleter w kodzie unique_ptr
zostanie przypisany do kopii lub przeniesiony z argumentem z reset
. Jeśli usuwacz jest niemożliwy do skopiowania lub nieusuwalny, wywołanie odpowiedniego przeciążenia z reset
nie zostanie skompilowane. Wydaje się, że byłoby to zgodne zachowanie z konstruktorami.
+1 za jedyną _authoritative_ odpowiedź na pytanie "dlaczego". – ildjarn
Czy nie byłoby czystsze i bardziej zgodne z shared_ptr, gdyby była funkcja resetowania? Dla mnie jest to szczególnie czyste, gdy masz niestandardową funkcję deletera. Na przykład: 'ptr = unique_ptr (new_raw_ptr, deleter_function);' vs 'ptr.reset (new_raw_ptr, deleter_function);'. Lub jeszcze lepiej, gdybyśmy mogli zachować tę samą funkcję deletera, więc byłoby to jak: 'ptr.reset (new_raw_ptr);'. –
felipou
@felipou: Ten ostatni działa.Dla tych pierwszych, oto jak * ty * możesz to zrobić: http://cplusplus.github.io/LWG/lwg-active.html#submit_issue –