Wie soll man std :: optional verwenden?

Ich lese die Dokumentation von std::experimental::optionalund habe eine gute Vorstellung davon, was es tut, aber ich verstehe nicht, wann ich es verwenden soll oder wie ich es verwenden soll. Die Seite enthält noch keine Beispiele, was es mir schwerer macht, das wahre Konzept dieses Objekts zu verstehen. Wann ist std::optionaleine gute Wahl und wie wird das kompensiert, was im vorherigen Standard (C ++ 11) nicht gefunden wurde?

Das einfachste Beispiel, das ich mir vorstellen kann:

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

Dasselbe kann stattdessen mit einem Referenzargument erreicht werden (wie in der folgenden Signatur), aber die Verwendung std::optionalmacht die Signatur und Verwendung angenehmer.

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

Eine andere Möglichkeit, dies zu tun, ist besonders schlecht :

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

Dies erfordert eine dynamische Speicherzuweisung, Bedenken hinsichtlich des Eigentums usw. - bevorzugen Sie immer eine der beiden anderen oben genannten Signaturen.

Ein anderes Beispiel:

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

Dies ist extrem vorzuziehen, anstatt std::unique_ptr<std::string>für jede Telefonnummer so etwas wie eine zu haben!std::optionalbietet Ihnen Datenlokalität, was sich positiv auf die Leistung auswirkt.

Ein anderes Beispiel:

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

Wenn die Suche keinen bestimmten Schlüssel enthält, können wir einfach "kein Wert" zurückgeben.

Ich kann es so benutzen:

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

Ein anderes Beispiel:

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

Dies ist viel sinnvoller als beispielsweise vier Funktionsüberladungen, die jede mögliche Kombination von max_count(oder nicht) und min_match_score(oder nicht) erfordern!

Es beseitigt auch den verfluchten "Pass -1für, max_countwenn Sie kein Limit wollen" oder "Pass std::numeric_limits<double>::min()für, min_match_scorewenn Sie keine Mindestpunktzahl wollen"!

Ein anderes Beispiel:

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

Wenn die Abfragezeichenfolge nicht vorhanden ist s, möchte ich "Nein int" - nicht den speziellen Wert, den jemand für diesen Zweck verwendet hat (-1?).

Weitere Beispiele finden Sie in der boost::optional Dokumentation . boost::optionalund std::optionalwird grundsätzlich in Bezug auf Verhalten und Nutzung identisch sein.

Ein Beispiel wird aus dem neu angenommenen Papier zitiert : 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
         }
     }
}

aber ich verstehe nicht, wann ich es benutzen soll oder wie ich es benutzen soll.

Überlegen Sie, wann Sie eine API schreiben und ausdrücken möchten, dass der Wert "Keine Rückgabe" kein Fehler ist. Sie müssen beispielsweise Daten aus einem Socket lesen. Wenn ein Datenblock vollständig ist, analysieren Sie ihn und geben ihn zurück:

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

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

Wenn die angehängten Daten einen analysierbaren Block abgeschlossen haben, können Sie ihn verarbeiten. Andernfalls lesen Sie die Daten weiter und hängen Sie sie an:

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

Bearbeiten: in Bezug auf den Rest Ihrer Fragen:

Wann ist std :: optional eine gute Wahl

• Wenn Sie einen Wert berechnen und ihn zurückgeben müssen, ist es besser, die Semantik nach Wert zurückzugeben, als auf einen Ausgabewert zu verweisen (der möglicherweise nicht generiert wird).

• Wenn Sie diesen Client - Code sicherstellen wollen , hat den Ausgangswert zu überprüfen (wer auch immer den Client - Code schreibt für Fehler kann nicht überprüfen - wenn Sie einen nicht initialisierten Zeiger Sie einen Core Dump erhalten versuchen , zu verwenden; wenn Sie eine unbe verwenden versuchen , initialisiert std :: optional, Sie erhalten eine abfangbare Ausnahme).

[...] und wie kompensiert es das, was im vorherigen Standard (C ++ 11) nicht gefunden wurde.

Vor C ++ 11 mussten Sie eine andere Schnittstelle für "Funktionen, die möglicherweise keinen Wert zurückgeben" verwenden - entweder per Zeiger zurückgeben und auf NULL prüfen oder einen Ausgabeparameter akzeptieren und einen Fehler- / Ergebniscode für "nicht verfügbar" zurückgeben ".

Beide erfordern vom Client-Implementierer zusätzlichen Aufwand und Aufmerksamkeit, um es richtig zu machen, und beide sorgen für Verwirrung (der erste veranlasst den Client-Implementierer, eine Operation als Zuweisung zu betrachten, und erfordert, dass der Client-Code die Zeigerbehandlungslogik implementiert, und der zweite erlaubt Client-Code, um mit ungültigen / nicht initialisierten Werten davonzukommen).

std::optional kümmert sich gut um die Probleme, die bei früheren Lösungen auftreten.

Ich verwende häufig Optionals, um optionale Daten darzustellen, die aus Konfigurationsdateien abgerufen wurden, dh wo diese Daten (z. B. mit einem erwarteten, aber nicht erforderlichen Element in einem XML-Dokument) optional bereitgestellt werden, damit ich explizit und klar zeigen kann, ob Die Daten waren tatsächlich im XML-Dokument vorhanden. Insbesondere wenn die Daten einen "nicht gesetzten" Zustand gegenüber einem "leeren" und einem "gesetzten" Zustand haben können (Fuzzy-Logik). Mit einem optionalen, gesetzt und nicht gesetzt ist klar, wäre auch leer mit dem Wert 0 oder null klar.

Dies kann zeigen, dass der Wert von "nicht gesetzt" nicht gleich "leer" ist. Im Konzept kann ein Zeiger auf ein int (int * p) dies zeigen, wenn keine Null (p == 0) gesetzt ist, ein Wert von 0 (* p == 0) gesetzt und leer ist und jeder andere Wert (* p <> 0) wird auf einen Wert gesetzt.

Als praktisches Beispiel habe ich ein Stück Geometrie aus einem XML-Dokument gezogen, das einen Wert namens Renderflags hatte, wobei die Geometrie entweder die Renderflags überschreiben (setzen), die Renderflags deaktivieren (auf 0 setzen) oder einfach nicht kann Auswirkungen auf die Render-Flags (nicht gesetzt), wäre eine Option eine klare Möglichkeit, dies darzustellen.

Natürlich kann ein Zeiger auf ein int in diesem Beispiel das Ziel erreichen, oder besser ein Freigabezeiger, da er eine sauberere Implementierung bieten kann. Ich würde jedoch argumentieren, dass es in diesem Fall um Codeklarheit geht. Ist eine Null immer ein "nicht gesetzt"? Mit einem Zeiger ist dies nicht klar, da null wörtlich bedeutet, dass es nicht zugewiesen oder erstellt wurde, obwohl dies möglich , aber möglicherweise nicht unbedingt erforderlich ist mean „nicht festgelegt“. Es ist darauf hinzuweisen, dass ein Zeiger freigegeben und in der guten Praxis auf 0 gesetzt werden muss. Wie bei einem gemeinsam genutzten Zeiger erfordert ein optionales Element jedoch keine explizite Bereinigung, sodass keine Bedenken bestehen, die Bereinigung mit zu verwechseln das optionale wurde nicht eingestellt.

Ich glaube, es geht um Code-Klarheit. Klarheit reduziert die Kosten für die Wartung und Entwicklung von Code. Ein klares Verständnis der Code-Absicht ist unglaublich wertvoll.

Die Verwendung eines Zeigers, um dies darzustellen, würde das Überladen des Konzepts des Zeigers erfordern. Um "null" als "nicht gesetzt" darzustellen, werden normalerweise ein oder mehrere Kommentare durch Code angezeigt, um diese Absicht zu erklären. Das ist keine schlechte Lösung anstelle einer optionalen. Ich entscheide mich jedoch immer für eine implizite Implementierung und nicht für explizite Kommentare, da Kommentare nicht durchsetzbar sind (z. B. durch Kompilierung). Beispiele für diese impliziten Elemente für die Entwicklung (jene Artikel in der Entwicklung, die nur zur Durchsetzung von Absichten bereitgestellt werden) sind die verschiedenen C ++ - Casts "const" (insbesondere für Elementfunktionen) und der Typ "bool", um nur einige zu nennen. Wahrscheinlich brauchen Sie diese Codefunktionen nicht wirklich, solange jeder Absichten oder Kommentaren gehorcht.