Il linguaggio sicuro è obsoleto in C ++ 11?


179

Questa risposta di @R. Martinho Fernandes mostra che il linguaggio del bool di sicurezza è apparentemente deprecato in C ++ 11, in quanto può essere sostituito da un semplice

explicit operator bool() const;

secondo la citazione standard nella risposta §4 [conv] p3:

Un'espressione e può essere implicitamente convertita in un tipo Tse e solo se la dichiarazione T t=e;è ben formata, per alcune variabili temporanee inventate t(§8.5). Alcuni costrutti del linguaggio richiedono che un'espressione sia convertita in un valore booleano. Si edice che un'espressione che appare in un tale contesto sia convertita contestualmente in booled è ben formata se e solo se la dichiarazione bool t(e);è ben formata , per alcune variabili temporanee inventate t (§8.5).

La parte evidenziata mostra chiaramente il "cast esplicito implicito" (chiamato "conversione contestuale" nello standard) come @R. Martinho l'ha detto.

I "certi costrutti di linguaggio" che richiedono che "cast esplicito implicito" sembrano essere i seguenti:

  • if, while, for( §6.4 [stmt.select] p4)
  • operatori logici binari &&e ||( §5.14 [expr.log.and/or] p1per entrambi)
  • l'operatore di negazione logica !( §5.3.1 [expr.unary.op] p9)
  • operatore condizionale ?:( §5.14 [expr.cond] p1)
  • static_assert( §7 [dcl.dcl] p4)
  • noexcept( §15.4 [except.spec] p2)

La nostra assunzione nel titolo è corretta? Spero di non aver trascurato alcun potenziale svantaggio.


30
+1: Adoro questo tipo di domanda che mi insegna nuove cose sullo standard imminente.
Björn Pollex,

1
Sai quale cast esplicito implicito manca nello standard ... restituendo qualcosa da un altro operator bool. Ad esempio, se ho un shared_ptrmembro chiamato p e ho questo metodo operator bool() const { return p; }:, non riesce a compilare. È stupido IMO.
David

Cosa intendi con cast "implicito esplicito", @David?
Sz.

Risposte:


128

Sì. Questo è l' esempio dei problemi con solo conversioni implicite definite dall'utente e operatori di conversione espliciti definiti dall'utente sono stati praticamente inventati a causa di questo problema e per sostituire tutte le cose sicure con qualcosa di molto più pulito e logico.


-5

Non lo definirei "obsoleto". Non tutti stanno facendo il salto in C ++ 11 (nemmeno 1 anno di età) al momento. E anche se ci fosse una buona quantità di programmatori, la capacità di mantenere il codice retrocompatibile sarebbe un must, considerando questo tipo di linguaggio sembra più sensato per le biblioteche che per i programmi propri.


34
Stavo semplicemente parlando in presenza di C ++ 11. Questa domanda non tocca il vecchio codice, la retrocompatibilità o la riluttanza a passare a compilatori consapevoli di C ++ 11. Si noti inoltre che C ++ 11 di per sé non è completamente compatibile con le versioni precedenti, ma ha introdotto modifiche sostanziali.
Xeo,

4
Non avrei potuto saperlo, scusa. Non ho considerato solo la risposta collegata all'inizio, ma anche il fatto che la domanda sia taggata [c ++] e [c ++ - faq], ciò mi ha portato a pensare che la valutazione di entrambe le fasi del linguaggio fosse pertinente.
Luis Machuca,

1
Hai certamente ragione però, non l'ho esplicitamente indicato nella domanda. Lo modificherò, grazie per l'heads up.
Xeo,

1
Questa risposta potrebbe davvero utilizzare l'aggiornamento, ora che ha quasi due anni.
Cucciolo

1
Dovrò votare in basso a causa del disaccordo, anche se ti comprerei una birra di persona e direi "ehi senza sentimenti duri". Ma molti paradigmi in C ++ 11 stavano sperimentando il dispiegamento poiché --std=c++0xmolto prima che il chiodo finale fosse introdotto nella bara degli standard e decisero di apporre il nome sulla specifica ISO. A meno che tu non sia un drogato di metaprogrammazione del modello molto profondo, i dettagli della specifica C ++ 11 rispetto a ciò che le persone stavano usando non hanno probabilmente alcuna conseguenza per te ... il che significa che era più vecchio del 2011 per quasi tutti gli scopi pratici anche allora. E ora, per il mio orologio, è quasi il 2015.
HostileFork dice che non fidarti di SE il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.