2011-09-12 12 views
7

Dalla lettura della revisione N3242 del draft C++ 11, sembra che alcuni componenti delle interfacce della libreria standard (in particolare thread e locking) dipendano dalla gestione delle eccezioni.Esiste un elenco di interfacce di libreria standard C++ 11 che richiedono eccezioni abilitate?

Poiché lavoro molto con le eccezioni disabilitato, mi chiedo quali componenti/funzionalità della libreria saranno (praticamente o logicamente) inutilizzabili senza la gestione delle eccezioni abilitata?

+0

Praticamente, tutte le funzionalità sono utilizzabili, fino a quando non viene generata un'eccezione effettiva. Quindi il tuo programma si blocca. Se una funzione di libreria può lanciare, questo è specificato nello standard, quindi in un modo c'è una lista - lo standard stesso. –

+0

@ n.m. sembra che tu abbia letto il mio post usando la definizione sbagliata di "praticamente": http://dictionary.reference.com/browse/practically. in caso contrario, c'è una differenza nella complessità e nella localizzazione di cose come 'std :: vector.at (size_t)' rispetto al threading e al lock di un programma/ambiente. avendo implementato le librerie di threading e locking, posso dirvi che potete difendervi facilmente e in modo prevedibile. (segue) – justin

+0

(cont) difendersi da quest'ultimo è molto più complesso. quando le cose vanno male, un'eccezione non gestita non è una soluzione (per alcuni di noi). non posso semplicemente ignorare questi errori :) quindi, non posso fare affidamento sulle implementazioni di threading e locking della libreria perché l'unica difesa offerta dalla libreria sono le eccezioni. in conclusione, le interfacce di threading e locking non sono adatte ai programmi in cui le eccezioni sono disabilitate. Spero possa aiutare. – justin

risposta

1

Questa domanda ha più di un mese di vita e non ha risposta.

Sto fornendo una risposta che può essere considerata una wiki della comunità, aggiungerla se necessario.

  • std::threadSezione 30.2.2. Transitivo. Astrazione implementata utilizzando implementazioni native.

  • std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Sezione 30.4.1, Intransitivo se si fornisce il proprio blocco senza eccezioni (tramite BasicLockable, Lockable, TimedLockable). Astrazione implementata utilizzando implementazioni native.

  • std::condition_variableSezione 30.5. Transitivo. Astrazione implementata utilizzando implementazioni native.

nota: ci sarà di più.

4

Prima di tutto (solo come promemoria), la disattivazione di eccezioni e RTTI sono estensioni specifiche del compilatore per cui lo standard non ha considerazione.

Dal momento che la libreria standard è di solito legato al compilatore, si può essere che l'implementazione della libreria standard è stato appositamente progettato per far fronte a questo (e, in particolare, di far fronte a new ritornano puntatori nulli invece di aumentare std::bad_alloc).

Pertanto, ciò che chiedi non è sensoriale. Controlla la documentazione della tua libreria per un elenco completo.

Detto questo, lo standard fa garantisce che un numero di operazioni non verrà mai generato. Non so di alcuna operazione che ingoia le eccezioni, suppongo che la maggior parte di esse sia effettivamente sicura da usare così com'è.

Ad esempio, tutti gli algoritmi devono essere sicuri.

Ancora, ancora una volta, posso solo consigliare di leggere la documentazione di l'implementazione.

+0

ci sono comuni varianti 'new' allo scopo di evitare' bad_alloc'. 'nothrow_t' è il modulo incorporato fornito dalla libreria, altri (inclusi gli allocatori definiti dall'utente) possono essere definiti dall'utente tramite il posizionamento nuovo. per le raccolte, si può specificare un allocatore che non getta: 'std :: vector >' e quindi l'interfaccia del vettore è ampiamente utilizzabile purché si rispettino le regole. (segue) – justin

+0

(segue) ci sono programmi C++ di alta qualità complessi che non si basano su eccezioni. il tuo post ha dei meriti (+1), ma penso che alcune generalizzazioni * possano * essere fatte in questo caso - ancora una volta, i miei esempi di threading (non sicuro), locking (non sicuro) e now vector (l'interfaccia può essere usata tranquillamente se la vita di nessuno dipende da questo). – justin

+0

@Justin: Non dico che non è possibile, dico solo che non è standard. Ad esempio, anche se 'new (nothrow_t)' esiste, un 'vector' potrebbe non usarlo. Ora, so che alcune librerie compilano senza eccezioni, LLVM/Clang è uno di loro ad esempio. Tuttavia hanno ridefinito anche la maggior parte delle classi di utilità. –

Problemi correlati