Dlaczego domyślnie nie są zdefiniowane w C++ 14 literały w globalnej przestrzeni nazw?

C++ 14 zawiera standardowe zdefiniowane literały, między innymi, std::string i różne czasy z nagłówka <chrono>.Dlaczego domyślnie nie są zdefiniowane w C++ 14 literały w globalnej przestrzeni nazw?

Aby z nich skorzystać, musisz powiedzieć using namespace std::literals; (lub pewną odmianę zależnie od tego, które dokładnie literały chcesz, ponieważ znajdują się w różnych wbudowanych przestrzeniach nazw).

Wszystko to jest dobre, ale jestem ciekawy, dlaczego wymagana jest deklaracja using. Listy UDL bez wiodącego podkreślenia są zarezerwowane dla implementacji, więc nie ma możliwości, aby "hello world"s mogło kiedykolwiek oznaczać coś innego w programie zgodnym z normami.

Dlaczego więc nie jest wystarczająca #include <string>, aby dosłowna funkcja konwersji znalazła się w zakresie? Dlaczego muszę wyraźnie uwzględnić literalną przestrzeń nazw?

EDIT:N3531 jest najnowsza wersja projektu udało mi się znaleźć - niestety nie dyskutować motywację do oddania rzeczy w przestrzeni nazw, ale tylko mówi:

Można podsumować wymagań [portlandzkiego] dyskusji w sposób następujący:

wykorzystanie przestrzeni nazw rolki dla (grupy pokrewne) operatora (ów) UDL

Źródło

2014-10-27 Tristan Brindle

Prawdopodobnie z tego samego powodu zdefiniowane przez użytkownika literały muszą zaczynać się od '_': [zgodność z przodu] (http://en.wikipedia.org/wiki/Forward_compatibility). Przewidują one dodanie większej ilości literałów w pewnym momencie w przyszłości i wyobrażam sobie, że umieszczają je w różnych przestrzeniach nazw w celu uniknięcia konfliktów nazw. – Cornstalks

@ Zamknij wyborcę: Wątpię, czy to jest oparte na opiniach. Komitet normalizacyjny podjął decyzję. Pyta * dlaczego * podjęli decyzję, którą podjęli. Które nie opiera się na opinii.Opiera się na historycznych dyskusjach i decyzjach w ramach komisji, które są faktem. – Cornstalks

"UDL bez wiodącego podkreślenia są zarezerwowane dla implementacji" Gdzie iw jakiej wersji? –

Istnieją już dwa bloki UDL o nazwie s: jeden dla łańcuchów i jeden dla seconds. Ze względu na zwięzłe nazwy sufiksów, chronicznie cierpią one na konflikty nazw, więc wylewanie ich wszystkich w jedną przestrzeń nazw nie może trwać długo. W związku z tym zdecydowano, że zostaną wstawione do wbudowanych przestrzeni nazw, które umożliwiają jednoznaczne (using namespace std::literals::chrono_literals) i proste dyrektywy using (using namespace std).

Źródło

2014-10-27 14:58:51 Columbo

W globalnym obszarze nazw nie może być nigdy innego sufiksu 's', ponieważ wszystkie niestandardowe UDL muszą rozpoczynać się od podkreślenia. –

@TristanBrindle ... Wyobraź sobie ze względu na ten argument, że standardowa komisja sama chciała wprowadzić drugi "operator" "s". – Columbo

@TristanBrindle: Istnieją trzy zainteresowane strony: standard, biblioteki platformy/implementacji/systemu i programista końcowy. Tylko ostatnie z nich nie mogą używać sufiksów UDL bez poprzedzającego podkreślenia. –

Spójrz na papier N2765. UDL są podłączone do zwykłego procesu wyszukiwania nazw. Ponieważ literały łańcuchowe mają typowe typy ciągów, istnieje duża szansa na kolizję, jeśli ignorujesz przestrzenie nazw.

Źródło

2014-10-27 14:57:55 MSalters

średnia biblioteka już definiuje różne wersje co s może oznaczać:

Może być stosowany do określenia ciąg dosłowne.
Można go użyć do zdefiniowania literału o numerze chrono::seconds.

Jedną z nich jest literał łańcuchowy, jeden oparty jest na liczbie całkowitej lub na literaturze double, oczywiście, tzn. Mogą one faktycznie współistnieć. Oczekuję jednak, że w przyszłości może być więcej zastosowań s. W związku z tym, konieczność wyboru, które przestrzenie nazw są importowane, a nie narzucane, wydaje się rozsądnym podejściem.

Źródło

2014-10-27 15:00:08

Dlaczego domyślnie nie są zdefiniowane w C++ 14 literały w globalnej przestrzeni nazw?

Odpowiedz

Powiązane problemy