Come si dovrebbe usare std :: opzionale?

Sto leggendo la documentazione di std::experimental::optionale ho una buona idea di ciò che fa, ma non capisco quando dovrei usarlo o come dovrei usarlo. Il sito non contiene ancora alcun esempio che mi rende più difficile comprendere il vero concetto di questo oggetto. Quando è std::optionaluna buona scelta da usare e come compensa ciò che non è stato trovato nello standard precedente (C ++ 11).

L'esempio più semplice che mi viene in mente:

std::optional<int> try_parse_int(std::string s)
{
    //try to parse an int from the given string,
    //and return "nothing" if you fail
}

La stessa cosa potrebbe essere realizzata con un argomento di riferimento (come nella firma seguente), ma l'utilizzo std::optionalrende la firma e l'utilizzo più piacevoli.

bool try_parse_int(std::string s, int& i);

Un altro modo in cui ciò potrebbe essere fatto è particolarmente negativo :

int* try_parse_int(std::string s); //return nullptr if fail

Ciò richiede l'allocazione dinamica della memoria, la preoccupazione per la proprietà, ecc. - Preferisci sempre una delle altre due firme sopra.

Un altro esempio:

class Contact
{
    std::optional<std::string> home_phone;
    std::optional<std::string> work_phone;
    std::optional<std::string> mobile_phone;
};

Questo è estremamente preferibile invece di avere qualcosa di simile a un std::unique_ptr<std::string>per ogni numero di telefono! std::optionalti dà la localizzazione dei dati, il che è ottimo per le prestazioni.

Un altro esempio:

template<typename Key, typename Value>
class Lookup
{
    std::optional<Value> get(Key key);
};

Se la ricerca non contiene una determinata chiave, possiamo semplicemente restituire "nessun valore".

Posso usarlo in questo modo:

Lookup<std::string, std::string> location_lookup;
std::string location = location_lookup.get("waldo").value_or("unknown");

Un altro esempio:

std::vector<std::pair<std::string, double>> search(
    std::string query,
    std::optional<int> max_count,
    std::optional<double> min_match_score);

Questo ha molto più senso di, diciamo, avere quattro sovraccarichi di funzioni che prendono ogni possibile combinazione di max_count(o no) e min_match_score(o no)!

Ha inoltre elimina la maledetta "Passo -1per max_countse non si desidera un limite" o "Passo std::numeric_limits<double>::min()per min_match_scorese non si desidera un punteggio minimo"!

Un altro esempio:

std::optional<int> find_in_string(std::string s, std::string query);

Se la stringa di query non è presente s, desidero "no int", non quale valore speciale qualcuno abbia deciso di utilizzare per questo scopo (-1?).

Per ulteriori esempi, è possibile consultare la boost::optional documentazione . boost::optionale std::optionalsarà sostanzialmente identico in termini di comportamento e utilizzo.

Un esempio è citato dal nuovo documento adottato: N3672, std :: opzionale :

 optional<int> str2int(string);    // converts int to string if possible

int get_int_from_user()
{
     string s;

     for (;;) {
         cin >> s;
         optional<int> o = str2int(s); // 'o' may or may not contain an int
         if (o) {                      // does optional contain a value?
            return *o;                  // use the value
         }
     }
}

ma non capisco quando dovrei usarlo o come dovrei usarlo.

Considerare quando si scrive un'API e si desidera esprimere che il valore "non avere un ritorno" non è un errore. Ad esempio, è necessario leggere i dati da un socket e quando un blocco di dati è completo, analizzarlo e restituirlo:

class YourBlock { /* block header, format, whatever else */ };

std::optional<YourBlock> cache_and_get_block(
    some_socket_object& socket);

Se i dati allegati hanno completato un blocco analizzabile, è possibile elaborarlo; altrimenti, continua a leggere e ad aggiungere i dati:

void your_client_code(some_socket_object& socket)
{
    char raw_data[1024]; // max 1024 bytes of raw data (for example)
    while(socket.read(raw_data, 1024))
    {
        if(auto block = cache_and_get_block(raw_data))
        {
            // process *block here
            // then return or break
        }
        // else [ no error; just keep reading and appending ]
    }
}

Modifica: riguardo al resto delle tue domande:

Quando è std :: opzionale una buona scelta da usare

• Quando si calcola un valore e è necessario restituirlo, si ottiene una migliore semantica da restituire per valore piuttosto che prendere un riferimento a un valore di output (che potrebbe non essere generato).

• Quando si desidera assicurarsi che il codice client debba controllare il valore di output (chiunque scriva il codice client potrebbe non verificare errori - se si tenta di utilizzare un puntatore non inizializzato si ottiene un dump principale; se si tenta di utilizzare un non- inizializzato std :: opzionale, si ottiene un'eccezione intercettabile).

[...] e come compensa ciò che non è stato trovato nel precedente standard (C ++ 11).

Prima di C ++ 11, era necessario utilizzare un'interfaccia diversa per "funzioni che potrebbero non restituire un valore" - o restituire tramite puntatore e controllare NULL, oppure accettare un parametro di output e restituire un codice di errore / risultato per "non disponibile ".

Entrambi impongono uno sforzo e un'attenzione extra da parte dell'implementatore client per farlo bene ed entrambi sono fonte di confusione (il primo spinge l'implementatore client a pensare a un'operazione come un'allocazione e richiede il codice client per implementare la logica di gestione dei puntatori e il secondo codice client per cavarsela usando valori non validi / non inizializzati).

std::optional si prende cura dei problemi che sorgono con le soluzioni precedenti.

Uso spesso gli optionals per rappresentare i dati opzionali estratti dai file di configurazione, ovvero dove vengono forniti facoltativamente tali dati (come con un elemento previsto, ma non necessario, all'interno di un documento XML), in modo da poter mostrare esplicitamente e chiaramente se i dati erano effettivamente presenti nel documento XML. Soprattutto quando i dati possono avere uno stato "non impostato", rispetto a uno stato "vuoto" e uno "impostato" (logica fuzzy). Con un facoltativo, impostare e non impostare è chiaro, anche vuoto sarebbe chiaro con il valore 0 o null.

Questo può mostrare come il valore di "non impostato" non equivale a "vuoto". In teoria, un puntatore a un int (int * p) può mostrare questo, dove non è impostato un null (p == 0), un valore di 0 (* p == 0) è impostato e vuoto e qualsiasi altro valore (* p <> 0) è impostato su un valore.

Per un esempio pratico, ho un pezzo di geometria estratto da un documento XML che aveva un valore chiamato flag di rendering, in cui la geometria può sovrascrivere i flag di rendering (impostare), disabilitare i flag di rendering (impostare su 0) o semplicemente no influenzare i flag di rendering (non impostati), un optional sarebbe un modo chiaro per rappresentarlo.

Chiaramente un puntatore a un int, in questo esempio, può raggiungere l'obiettivo, o meglio, un puntatore di condivisione in quanto può offrire un'implementazione più pulita, tuttavia, direi che si tratta di chiarezza del codice in questo caso. Un null è sempre un "non impostato"? Con un puntatore, non è chiaro, poiché null significa letteralmente non allocato o creato, anche se potrebbe , ma potrebbe non necessariamente significare "non impostato". Vale la pena sottolineare che un puntatore deve essere rilasciato e, in buona pratica, impostato su 0, tuttavia, come con un puntatore condiviso, un facoltativo non richiede una pulizia esplicita, quindi non c'è alcun problema di confondere la pulizia con l'opzione non è stata impostata.

Credo che si tratti di chiarezza del codice. La chiarezza riduce i costi di manutenzione e sviluppo del codice. Una chiara comprensione dell'intenzione del codice è incredibilmente preziosa.

L'uso di un puntatore per rappresentarlo richiederebbe di sovraccaricare il concetto di puntatore. Per rappresentare "null" come "non impostato", in genere potresti visualizzare uno o più commenti tramite il codice per spiegare questa intenzione. Non è una cattiva soluzione invece di un facoltativo, tuttavia, ho sempre optato per l'implementazione implicita piuttosto che per i commenti espliciti, poiché i commenti non sono esecutivi (come per esempio la compilazione). Esempi di questi elementi impliciti per lo sviluppo (quegli articoli in sviluppo forniti esclusivamente per rafforzare l'intenzione) includono i vari cast in stile C ++, "const" (specialmente sulle funzioni membro) e il tipo "bool", solo per citarne alcuni. Probabilmente non hai davvero bisogno di queste funzionalità di codice, purché tutti obbediscano a intenzioni o commenti.