Jak należy używać std :: optional?

Czytam dokumentację programu std::experimental::optionali mam dobre pojęcie o tym, co robi, ale nie rozumiem, kiedy powinienem go używać lub jak powinienem go używać. Strona nie zawiera jeszcze przykładów, co utrudnia mi zrozumienie prawdziwej koncepcji tego obiektu. Kiedy jest std::optionaldobrym wyborem do użycia i jak kompensuje to, czego nie znaleziono w poprzednim standardzie (C ++ 11).

Najprostszy przykład jaki przychodzi mi do głowy:

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

To samo można osiągnąć za pomocą argumentu referencyjnego (jak w poniższej sygnaturze), ale użycie std::optionalsprawia, że ​​podpis i użycie są przyjemniejsze.

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

Inny sposób, w jaki można to zrobić, jest szczególnie zły :

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

Wymaga to dynamicznej alokacji pamięci, martwienia się o własność itp. - zawsze preferuj jeden z dwóch pozostałych podpisów powyżej.

Inny przykład:

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

Jest to bardzo korzystne rozwiązanie zamiast mieć coś takiego jak „a” std::unique_ptr<std::string>dla każdego numeru telefonu! std::optionalzapewnia lokalizację danych, która jest świetna do wydajności.

Inny przykład:

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

Jeśli wyszukiwanie nie zawiera określonego klucza, możemy po prostu zwrócić „brak wartości”.

Mogę to wykorzystać w ten sposób:

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

Inny przykład:

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

Ma to o wiele więcej sensu niż, powiedzmy, cztery przeciążenia funkcji, które przyjmują każdą możliwą kombinację max_count(lub nie) i min_match_score(lub nie)!

To również eliminuje ten przeklęty „pass -1na max_countjeśli nie chcesz limit” lub „pass std::numeric_limits<double>::min()na min_match_scorejeśli nie chcesz wynik minimum”!

Inny przykład:

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

Jeśli ciągu zapytania nie ma s, chcę "nie int" - nie jakiejkolwiek specjalnej wartości, którą ktoś zdecydował się użyć w tym celu (-1?).

Dodatkowe przykłady można znaleźć w boost::optional dokumentacji . boost::optionali std::optionalbędą zasadniczo identyczne pod względem zachowania i użycia.

Przykład jest cytowany z nowego przyjętego artykułu: N3672, std :: optional :

 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
         }
     }
}

ale nie rozumiem, kiedy powinienem go używać lub jak powinienem go używać.

Zastanów się, kiedy piszesz API i chcesz wyrazić, że „brak wartości zwracanej” nie jest błędem. Na przykład musisz odczytać dane z gniazda, a gdy blok danych jest kompletny, analizujesz go i zwracasz:

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

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

Jeśli dołączone dane wypełniły blok parsowalny, możesz go przetworzyć; w przeciwnym razie czytaj i dołączaj dane:

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 ]
    }
}

Edycja: w odniesieniu do pozostałych pytań:

Kiedy jest std :: optional, jest to dobry wybór

• Kiedy obliczasz wartość i musisz ją zwrócić, lepsza semantyka zwraca wartość niż branie odniesienia do wartości wyjściowej (która może nie zostać wygenerowana).

• Jeśli chcesz mieć pewność, że kod klienta musi sprawdzić wartość wyjściową (ktokolwiek pisze kod klienta, może nie sprawdzić pod kątem błędów - jeśli spróbujesz użyć niezainicjowanego wskaźnika, otrzymasz zrzut rdzenia; jeśli spróbujesz użyć un- zainicjalizowany std :: optional, otrzymasz wyjątek, który można złapać).

[…] i jak kompensuje to, czego nie znaleziono w poprzednim standardzie (C ++ 11).

Przed C ++ 11 trzeba było używać innego interfejsu dla „funkcji, które mogą nie zwracać wartości” - albo zwracać wskaźnik i sprawdzać, czy nie ma wartości NULL, albo akceptować parametr wyjściowy i zwracać kod błędu / wyniku dla „niedostępne” ”.

Oba wymagają dodatkowego wysiłku i uwagi ze strony osoby wdrażającej klienta, aby zrobić to dobrze, i oba są źródłem zamieszania (pierwsze zmuszają osobę wdrażającą klienta do myślenia o operacji jako alokacji i wymagają od kodu klienta implementacji logiki obsługi wskaźników, a druga kod klienta, aby uniknąć używania nieprawidłowych / niezainicjowanych wartości).

std::optional ładnie rozwiązuje problemy wynikające z wcześniejszych rozwiązań.

Często używam opcji opcjonalnych do reprezentowania opcjonalnych danych pobranych z plików konfiguracyjnych, to znaczy, gdzie te dane (takie jak oczekiwany, ale niepotrzebny element w dokumencie XML) są opcjonalnie dostarczane, więc mogę wyraźnie i wyraźnie pokazać, czy dane faktycznie były obecne w dokumencie XML. Zwłaszcza, gdy dane mogą mieć stan „nieustawiony” w przeciwieństwie do stanu „pusty” i „ustawiony” (logika rozmyta). Z opcjonalnym ustawieniem i nieustawieniem jest jasne, również puste byłoby jasne z wartością 0 lub null.

Może to pokazać, że wartość „nie ustawiono” nie jest równoważna wartości „pusty”. W ujęciu koncepcyjnym wskaźnik do int (int * p) może to pokazać, gdy null (p == 0) nie jest ustawiony, wartość 0 (* p == 0) jest ustawiona i pusta, a każda inna wartość (* p <> 0) jest ustawione na wartość.

Dla praktycznego przykładu mam kawałek geometrii wyciągnięty z dokumentu XML, który miał wartość zwaną flagami renderowania, gdzie geometria może albo nadpisać flagi renderowania (ustawione), wyłączyć flagi renderowania (ustawione na 0), albo po prostu nie wpływają na flagi renderowania (nieustawione), opcjonalny byłby wyraźnym sposobem przedstawienia tego.

Oczywiście wskaźnik do int, w tym przykładzie, może osiągnąć cel lub, lepiej, wskaźnik udziału, ponieważ może zaoferować czystszą implementację, jednak twierdzę, że w tym przypadku chodzi o przejrzystość kodu. Czy wartość null zawsze oznacza „nieustawione”? W przypadku wskaźnika nie jest to jasne, ponieważ null dosłownie oznacza, że ​​nie został przydzielony lub utworzony, chociaż może , ale niekoniecznie musi oznaczać „nieustawiony”. Warto zwrócić uwagę, że wskaźnik musi zostać zwolniony i zgodnie z dobrą praktyką ustawiony na 0, jednak podobnie jak w przypadku wskaźnika współdzielonego opcja opcjonalna nie wymaga jawnego czyszczenia, więc nie ma obawy o mylenie czyszczenia z opcja nie została ustawiona.

Uważam, że chodzi o przejrzystość kodu. Clarity obniża koszty utrzymania i rozwoju kodu. Jasne zrozumienie intencji kodu jest niezwykle cenne.

Użycie wskaźnika do reprezentacji tego wymagałoby przeciążenia koncepcji wskaźnika. Aby przedstawić „null” jako „nieustawione”, zazwyczaj można zobaczyć w kodzie jeden lub więcej komentarzy wyjaśniających ten zamiar. To nie jest złe rozwiązanie zamiast opcjonalnego, jednak zawsze wybieram niejawną implementację zamiast jawnych komentarzy, ponieważ komentarze nie są egzekwowalne (na przykład przez kompilację). Przykłady tych niejawnych elementów do programowania (te artykuły w fazie rozwoju, które są dostarczane wyłącznie w celu wymuszenia intencji) obejmują różne rzutowania w stylu C ++, „const” (zwłaszcza w funkcjach składowych) i typ „bool”, żeby wymienić tylko kilka. Prawdopodobnie nie potrzebujesz tych funkcji kodu, o ile wszyscy przestrzegają intencji lub komentarzy.