La strong garanzia di sicurezza delle eccezioni con un argomento pass-by-value che può comportare la distruzione?

8

Supponiamo di avere un tipo con un distruttore di lancio e una funzione che lo riceve in base al valore.
Questa operazione può mai fornire qualcosa di meglio della garanzia di base?
O formulato diversamente, si può ignorare la distruzione dell'argomento passato per valore nel determinare se un'operazione ha una semantica commmit-and-rollback?

#include <cstdlib>

struct X {
    ~X() noexcept(0) {
        if(rand()%6 == 0) throw 0;
    }
    // some state
};

void update(database db, X arg) noexcept;

X x;
update(db, x);

Personalmente, basato su la definizione da wikipedia

  1. Strong exception safety, also known as commit or rollback semantics: Operations can fail, but failed operations are guaranteed to have no side effects, so all data retain their original values

Non penso sia utile descrivere update come strongmente sicuro per le eccezioni, anche se la funzione stessa non può nemmeno lanciare.

Gradirei che qualcuno mi mostrasse la follia della mia attuale comprensione, o che fornisse una discussione migliore.

    
posta Deduplicator 24.11.2015 - 16:47
fonte

2 risposte

7

Non sono molto sicuro a posteriori, ma se update era generico o se X era astratto (es: clonato e distrutto) - cioè, se update non poteva sapere nulla di concreto su X quindi, a tutti gli effetti pratici, lo descriverei come se avesse una strong garanzia di sicurezza. Per lo meno è una garanzia di sicurezza eccezionalmente strong che ti consente di entrare in un contesto astratto senza eseguire il controllo radiografico di un tipo di dati.

Tuttavia, X è concreto, quindi questo rende la domanda molto più sfocata. Sono ancora tentato di dire che update "ha una strong garanzia di eccezione per le eccezioni" dal momento che sta facendo tutto il possibile per farlo rispettare. Suona come un matto? Lo fa per me, ma non posso davvero metterlo molto meglio.

Specialmente nel contesto di un ambiente di squadra in cui un autore implementa update e l'altro implementa X , nulla potrebbe mai fornire una garanzia di sicurezza eccezionale in quanto X potrebbe essere modificata in modo da infrangere la garanzia in modi completamente al di fuori del controllo di update . Per motivi pratici, penso che se update fa tutto il possibile e dovrebbe ripristinare i propri effetti collaterali in percorsi eccezionali, fornisce praticamente una garanzia di sicurezza eccezionale.

In caso contrario, la strong garanzia di sicurezza delle eccezioni diventa qualcosa di poco pratico da offrire in così tanti scenari. Le cose potrebbero cambiare al di fuori del controllo della funzione. Le cose potrebbero essere astratte in modi diversi dalla conoscenza della funzione. L'intera garanzia sarebbe quasi impossibile da fornire ovunque. In tal caso, potremmo dire che la strong garanzia di eccezione di update genera una responsabilità a X da rispettare, oppure è update che è necessario sapere come X sarà implementato in ogni momento? Non lo so. Questo è tutto molto poco pratico in entrambi i casi, e non mi piacciono le impraticabilità.

Quindi andrò con il grezzo, sì, " update è sicuro per l'eccezione, ma X è andato fubar e ha incasinato tutto. Non è almeno update's errore. citare l'autore dell'aggiornamento! Sue l'autore di X ! ". Mi piacerebbe descrivere X come semplicemente essere fubar qui, e update come possibilmente fornendo una garanzia di sicurezza eccezionalmente strong che viene avvitata dal fatto che X è fubar. Cioè, a meno che non ci sia una comprensione a livello di interfaccia molto difficile che X's destructor è progettato per lanciare, nel qual caso non ho idea di come descriverlo se non come un "grosso problema". Penso che abbiamo bisogno di alcune belle stampe e dichiarazioni di non responsabilità per venire con queste garanzie. L'aggiornamento fornisce una strong garanzia di sicurezza eccezionale a condizione che [...]. Nessun rimborso se questo non è il caso!

Per me è una domanda filosofica, interessante a cui pensare ma forse senza una risposta perfetta. E quali sono le garanzie comunque? Possiamo garantire qualcosa? Potrei garantire che bere birra mi renderebbe ubriaco e potrebbe sembrare vero tutto il tempo, ma cosa succederebbe se un extraterrestre intervenisse e utilizzasse una qualche specie di tecnologia aliena che mi rendesse sobrio, non importa quanto bevo? Non posso garantire che ciò non accada. Posso solo dire che questo è altamente improbabile e che se questo evento dovesse accadere, sarei impotente nei suoi confronti. Ho fatto la mia parte. Ho bevuto la mia birra. Dovrei ubriacarmi. Lo garantisco strongmente. Ma non è sicuro. C'è sempre qualche probabilità, per quanto astronomicamente remota, che la garanzia potrebbe non essere vera. Che ne dici di sicurezza del filo? Bene, cosa succede se arriva l'astronave aliena e zappa il nostro hardware e riorganizza le istruzioni in memoria in modo tale che una funzione di sicurezza thread-thread non sia più protetta da thread in fase di runtime? Non posso garantire che ciò non accada. Ma garantirò la sicurezza del filo, senza nemmeno addentrarmi in una stampa così sottile sulle astronavi aliene, perché fa sentire le persone belle e rassicurate, e quello che sto dicendo è che sto facendo tutto ciò che è in mio potere e conoscenza per far rispettare questo garanzia.

Una volta Cartesio disse: "Penso, quindi, lo sono". Come lo sa? E se lui non lo fosse? Potrebbe essere un "non sono" ma forse "non" può "pensare". Non so nemmeno se esisto. Che cosa significa pensare in ogni caso? È come una parola usata dalla gente per descrivere un processo che sembra andare avanti in modo introspettivo e sembra come se noi, che potremmo anche non esistere, prendiamo decisioni.

E se fossimo tutti solo bit e byte su qualche macchina? Come quella bionda o bruna in Matrix. A proposito, come può una bionda o soprattutto una bruna essere immagazzinata in un così piccolo flusso di personaggi? Sono come UTF2048? Era una specie di flusso alieno di personaggi, ma non sembravano esserci troppi personaggi unici. Forse è una specie di chiamata di funzione. Ad ogni modo, non sono sicuro di poter garantire nulla. È tutto relativo a ciò che crediamo sia vero.

    
risposta data 12.12.2015 - 19:35
fonte
-1

Tecnicamente parlando, può forse fornire la strong garanzia di eccezione. Significativamente, può solo fornire la strong garanzia di eccezione nel caso banale in cui non fa nulla.

Herb Sutter parla di un caso simile (e più intuitivo) in cui una funzione accetta un argomento in base al valore con un costruttore di copie di lancio. È possibile etichettare tale funzione noexcept. Tecnicamente, l'eccezione si verifica nella "colla" tra il codice chiamante e la funzione chiamata, non all'interno della funzione stessa. Anche qui è così. Dal momento che l'eccezione non è tecnicamente generata all'interno dell'aggiornamento, potresti (forse) sostenere che l'aggiornamento stesso non genera l'errore e quindi può offrire la strong garanzia di eccezione.

In pratica, se l'aggiornamento fa qualcosa, allora chiamarlo (e non fare nient'altro) può far cambiare lo stato del mondo e lanciare un'eccezione, rompendo la strong garanzia di eccezione.

    
risposta data 20.12.2015 - 17:14
fonte

Leggi altre domande sui tag