2016-04-04 7 views
1

n3527 schlägt vor, std::optional<T> zu C++ hinzuzufügen. Als Teil definiert es nullopt_t Typ-Tag.C++ optional_t ​​type tag (n3527)

gcc (4.9) libstdC++ definiert optional_t wie folgt:

struct nullopt_t 
{ 
    enum class _Construct { _Token }; 
    explicit constexpr nullopt_t(_Construct) { } 
}; 
constexpr nullopt_t nullopt { nullopt_t::_Construct::_Token }; 

Klirren der (3.6) libC++ definiert sie als:

struct nullopt_t 
{ 
    explicit constexpr nullopt_t(int) noexcept {} 
}; 
constexpr nullopt_t nullopt{0}; 

Meine Frage ist: Warum ist es so gemacht, das ist (scheinbar) zu kompliziert?

Dies ist, wie zum Beispiel std::defer_lock_t und andere in der Standardbibliothek
struct nullopt_t { }; 
constexpr nullopt_t nullopt { }; 

definiert sind:

Mit anderen Worten, warum kann es wie folgt definiert werden.

+2

Es bedeutet, dass es keine legale Möglichkeit gibt, eigene 'nullopt_t' zu konstruieren? So ähnlich wie 'nullptr_t'? – Yakk

+3

Möglicherweise verwandt: [experimental :: optional nullopt_t Konstruktor] (http://stackoverflow.com/questions/28332078/) – kakkoko

+0

@kakkoko, Sie setzen mich auf den richtigen Weg! Es hat mit der 'op = {}' Syntax zu tun. Es macht im Grunde 'nullopt_t' nicht-' DefaultConstructible', um Mehrdeutigkeiten zu vermeiden. –

Antwort

1

Ich selbst hier antworten, aber Kredit geht an Kakkoko für mich auf den richtigen Weg zu bringen.

Die zugehörige Frage verweist auf eine neuere Version n3793, die auf die zusätzliche Komplexität von nullopt_t in The op = {} syntax Absatz verweist.

Kurz gesagt, die nullopt_t ist so erklärt, dass es nicht DefaultConstructible zu machen, um Mehrdeutigkeit der op = {} Syntax zu vermeiden. Sie können den vorher verlinkten Absatz für weitere Details lesen.