Czy idiom Safe-Bool jest przestarzały w C ++ 11?

179

Ta odpowiedź @R. Martinho Fernandes pokazuje, że idiom bezpieczny jest przestarzały w C ++ 11, ponieważ można go zastąpić prostym

explicit operator bool() const;

zgodnie ze standardowym cytatem w odpowiedzi §4 [conv] p3:

Wyrażenie e można domyślnie przekonwertować na typ Twtedy i tylko wtedy, gdy deklaracja T t=e;jest poprawnie sformułowana, dla niektórych wynalezionych zmiennych tymczasowych t(§ 8.5). Niektóre konstrukcje językowe wymagają przekonwertowania wyrażenia na wartość logiczną. Wyrażenie ewystępujące w takim kontekście mówi się, że jest kontekstowo konwertowane na booli jest dobrze uformowane, jeśli i tylko jeśli deklaracja bool t(e);jest dobrze uformowana , dla niektórych wynalezionych zmiennych tymczasowych t (§ 8.5).

Podświetlona część wyraźnie pokazuje „domyślną jawną obsadę” (zwaną w standardzie „konwersją kontekstową”) jako @R. Martinho to ujął.

„Niektóre konstrukcje językowe”, które wymagają, aby „jawna obsada jawna” wyglądała następująco:

if, while, for( §6.4 [stmt.select] p4)
binarne operatory logiczne &&i ||( §5.14 [expr.log.and/or] p1dla obu)
operator logicznej negacji !( §5.3.1 [expr.unary.op] p9)
operator warunkowy ?:( §5.14 [expr.cond] p1)
static_assert( §7 [dcl.dcl] p4)
noexcept( §15.4 [except.spec] p2)

Czy nasze założenie w tytule jest prawidłowe? Mam nadzieję, że nie przeoczyliśmy żadnych potencjalnych wad.

— Xeo
źródło

+1: Uwielbiam tego rodzaju pytania, które uczą mnie nowych rzeczy na temat nadchodzącego standardu.

— Björn Pollex

Wiesz, czego domyślnie brakuje w obsadzie jawnej ... zwracanie czegoś od innego operator bool. Na przykład, jeśli mam shared_ptrczłonka o nazwie p i mam tę metodę: operator bool() const { return p; }kompilacja nie powiedzie się. To głupie IMO.

— David

Co rozumiesz przez „ukrytą jawną” obsadę, @David?

— Sz.

Odpowiedzi:

128

Tak. To przykładem problemów z konieczności tylko konwersje niejawne zdefiniowane przez użytkownika i jawne operatory konwersji zdefiniowanych przez użytkownika zostały praktycznie wynalazł powodu tego problemu i zastąpić wszystkie bezpieczne bool rzeczy z czymś dużo czystsze i bardziej logiczne.

— Szczeniak
źródło

-5

Nie nazwałbym tego „przestarzałym”. Nie wszyscy jeszcze skaczą do C ++ 11 (nawet 1- latek). I nawet jeśli spora liczba koderów byłaby, koniecznością jest utrzymanie kompatybilności kodu wstecznego, biorąc pod uwagę, że ten rodzaj idiomu wydaje się bardziej sensowny dla bibliotek niż dla odpowiednich programów.

— Luis Machuca
źródło

Mówiłem czysto w obecności C ++ 11. To pytanie nie dotyczy starego kodu, kompatybilności wstecznej ani niechęci do przejścia na kompilatory obsługujące C ++ 11. Zauważ też, że sam C ++ 11 nie jest w pełni kompatybilny wstecz, wprowadził przełomowe zmiany.

— Xeo,

Przepraszam, nie wiedziałbym o tym. Nie zastanawiałem się tylko nad odpowiedzią powiązaną na początku, ale także z faktem, że pytanie jest oznaczone [c ++] i [c ++ - faq], co doprowadziło mnie do wniosku, że ocena obu etapów języka była istotna.

— Luis Machuca,

Z pewnością masz rację, nie powiedziałem tego wprost w pytaniu. Zmienię to, dziękuję za zgłoszenie się.

— Xeo,

W tej odpowiedzi naprawdę warto skorzystać z aktualizacji, która ma już prawie dwa lata.

— Puppy

Będę musiał przegłosować z powodu braku porozumienia, choć osobiście kupiłbym ci piwo i powiedziałbym „hej, nie ma uczuć”. Ale wiele paradygmatów w C ++ 11 doświadczało wdrożenia, na --std=c++0xdługo zanim ostatni gwóźdź został wbity w trumnę ze standardami i postanowili umieścić nazwę na specyfikacji ISO. Jeśli nie jesteś naprawdę głębokim ćpunem do metaprogramowania szablonów, szczegóły specyfikacji C ++ 11 w porównaniu z tym, czego używali ludzie, prawdopodobnie nie będą miały dla ciebie żadnego znaczenia ... co oznacza, że była starsza niż 2011 r. Dla prawie wszystkich praktycznych celów nawet wtedy. A teraz, na mój zegar, jest już prawie 2015.

— HostileFork mówi: nie ufaj SE