2012-05-01 22 views
10

Non riesco a trovare algoritmi standard che dimostrino il requisito per la costruzione di default di ForwardIterator.Perché sono necessari ForwardIterators per modellare DefaultConstructible?

Esiste un motivo valido o sono sicuro di ignorarlo?

+4

Non importa se esiste un motivo reale; è * obbligatorio *. Quindi ignorare il requisito a vostro rischio e pericolo. –

+1

Bene, se l'iteratore si basa logicamente su un argomento, l'alternativa è aggiungere i costruttori predefiniti che lasciano l'oggetto in uno stato non valido, il che sembra anche flirtare con pericoli. – Ayjay

+0

Un'alternativa * working * sarebbe quella di cambiare i tuoi iteratori in modo che non si basino su un argomento. Mettili in uno stato valido ma concettualmente vuoto. –

risposta

4

È lì per facilitare l'uso di questo tipo di iteratori, sia per gli algoritmi standard che per gli utenti client.

Per esempio (ricordiamo che RandomAccessIterator è un sottotipo di ForwardIterator):

template <class RandomAccessIterator> 
    void sort (RandomAccessIterator first, RandomAccessIterator last) 
{ 
    RandomAccessIterator pivot, i, j; 
    //do your sorting algorithm   
} 

Se essi non sono stati predefiniti costruibili si avrebbe bisogno di assegnarli a first o last solo per la sua compilazione.

Non è necessario che sia impostato su un valore predefinito. Qualsiasi utilizzo di questo iteratore non inizializzato non è definito. Non sarebbe saggio non aggiungere qualche controllo, in particolare nelle build di debug.

E no, non si dovrebbe gettare il costruttore predefinito. Sarebbe tecnicamente conforme, ma molti algoritmi falliranno in modo imprevisto.

+0

Questo è un argomento per 'RandomAccessIterator' per modellare' DefaultConstructible', non 'ForwardIterator', però. 'InputIterator' non è richiesto per modellare' DefaultConstructible', perché 'ForwardIterator'? – Ayjay

+1

Per non parlare, non so se consentire un'implementazione dubbiamente più semplice degli algoritmi standard valga il requisito non necessario che non consente l'uso di riferimenti e altri tipi non costruttivi predefiniti. Ha implicazioni di vasta portata in tutti i tipi di dati - all'improvviso, tutto ciò che l'iteratore utilizza deve ora consentire anche la costruzione predefinita e uno stato "costruito ma non valido". – Ayjay

+0

Bene, quel tipo di codice sarebbe contro le linee guida di codifica basate su RAII in cui l'inizializzazione è obbligatoria al punto di definizione. – dirkgently

3

Dalla mia copia della bozza:

24.2.5 Inoltra iteratori [forward.iterators]

una classe o di un tipo built-in X soddisfa le esigenze di un iteratore avanti se

[...]

- X soddisfa i requisiti DefaultConstructible (20.2.1),

e poi:

20.2.1 requisiti argomento di un template

In generale, un costruttore di default non è necessaria. Alcune firme delle funzioni dei membri della classe specificano il costruttore predefinito come argomento predefinito . T() deve essere un'espressione ben definita (8.5) se viene richiamato uno di tali firme utilizzando l'argomento predefinito (8.3.6).

Ci sono due cose da notare qui:

  • La prima linea ci dice che un ctor di default è raramente necessaria (che risponde quasi tua domanda)
  • Il requisito è probabilmente un suggerimento che iteratore la semantica dovrebbe essere compatibile con i puntatori, essendo quest'ultimo predefinito costruibile (leggi per non violare il codice esistente).
+0

Ciò sembra implicare che ForwardIterator debba essere DefaultConstructible se si chiama una di quelle "determinate firme di funzioni membro della classe contenitore" con esso. Lo standard specifica le volte in cui deve verificarsi? – Ayjay

+0

@Ayjay: lo standard dovrebbe fornire tali funzioni membro. Non posso nominarne uno a braccio, ma non sarei sorpreso se non ce ne fossero. Questo dovrebbe indicarmi che questo è stato un modo per tagliare un po 'di tempo i futuri scrittori di biblioteche. – dirkgently

Problemi correlati