Namespaces
Variants

no-throw-input-iterator , no-throw-forward-iterator , no-throw-sentinel-for , no-throw-input-range , no-throw-forward-range

From cppreference.net
C++
Memory management library
( exposition only* )
Allocators
Uninitialized memory algorithms
Constrained uninitialized memory algorithms
Memory resources
Uninitialized storage (until C++20)
( until C++20* )
( until C++20* )
( until C++20* )

Garbage collector support (until C++23)
(C++11) (until C++23)
(C++11) (until C++23)
(C++11) (until C++23)
(C++11) (until C++23)
(C++11) (until C++23)
(C++11) (until C++23)
(Anmerkung: Der bereitgestellte HTML-Code enthält keinen übersetzbaren Text, da alle Tags und Attribute gemäß den Anweisungen unverändert bleiben sollen und die Tabellenzellen leer sind.)
(1) ( Nur zur Darstellung* )
template < class I >

Konzept no - throw - forward - iterator =
no - throw - input - iterator < I > &&
std:: forward_iterator < I > &&

no - throw - sentinel - for < I, I > ;
(2) ( Nur zur Darstellung* )
template < class S, class I >
Konzept no - throw - sentinel - for = std:: sentinel_for < S, I > ;
(3) ( Nur zur Darstellung* )
template < class R >

Konzept no - throw - input - range =
ranges:: range < R > &&
no - throw - input - iterator < ranges:: iterator_t < R >> &&

no - throw - sentinel - for < ranges:: sentinel_t < R > , ranges:: iterator_t < R >> ;
(4) ( Nur zur Darstellung* )
template < class R >

Konzept no - throw - forward - range =
no - throw - input - range < R > &&

no - throw - forward - iterator < ranges:: iterator_t < R >> ;
(5) ( Nur zur Darstellung* )

Diese ausschließlich expository Konzepte spezifizieren, dass keine Ausnahmen von Operationen geworfen werden, die von Algorithmen auf Iteratoren, Sentinels und Ranges benötigt werden.

1) Das no-throw-input-iterator -Konzept erfordert, dass die Dereferenzierung des Iterators einen L-Wert liefert, wie bei contiguous_iterator und LegacyForwardIterator .

Semantische Anforderungen

Wie alle Standardkonzepte ist jedes hier aufgeführte Konzept nur dann modelliert, wenn alle von ihm subsumierten Konzepte modelliert sind.

1) Ein Typ I modelliert no-throw-input-iterator nur dann, wenn keine Ausnahmen aus Inkrementierung, Kopierkonstruktion, Verschiebekonstruktion, Kopierzuweisung, Verschiebezuweisung oder Dereferenzierung gültiger Iteratoren geworfen werden.
3) Typen S und I modellieren no-throw-sentinel-for nur dann, wenn keine Ausnahmen aus Kopierkonstruktion, Verschiebekonstruktion, Kopierzuweisung, Verschiebezuweisung oder Vergleichen zwischen gültigen Werten des Typs I und S geworfen werden.
4) Ein Typ R modelliert no-throw-input-range nur dann, wenn keine Ausnahmen von Aufrufen von ranges:: begin und ranges:: end auf ein Objekt vom Typ R geworfen werden.

Hinweise

Diese Konzepte erlauben es, dass einige Operationen auf Iteratoren und Sentinels Ausnahmen werfen können, z.B. Operationen auf ungültigen Werten.

Siehe auch

(C++20)
spezifiziert, dass ein Typ ein Eingabe-Iterator ist, d.h. seine referenzierten Werte können gelesen werden und er kann sowohl prä- als auch post-inkrementiert werden
(Konzept)
(C++20)
spezifiziert, dass ein input_iterator ein Vorwärts-Iterator ist, der Gleichheitsvergleiche und Mehrfachdurchläufe unterstützt
(Konzept)
(C++20)
spezifiziert, dass ein Typ ein Sentinel für einen input_or_output_iterator Typ ist
(Konzept)
(C++20)
spezifiziert einen Bereich, dessen Iteratortyp input_iterator erfüllt
(Konzept)
(C++20)
spezifiziert einen Bereich, dessen Iteratortyp forward_iterator erfüllt
(Konzept)