Czy separatory C++ 14-cyfrowe są dozwolone w zdefiniowanych przez użytkownika literałach?

Question

Podczas dzyń kompiluje następujący wiersz, g ++ 6.1 narzeka separator cyfr (patrz live example on Coliru):

auto time = 01'23s; 

Który kompilator, jeżeli istnieje, jest poprawna według standardu C++ 14 (N3796)?

W przeciwnym razie, pozwala na to, że separatory cyfrowe (§2.14.2) są tylko szczegółami implementacji w zdefiniowanych przez użytkownika literałach (§ 2.14.8) biblioteki <chrono> (§20.12.5.8)? IMHO powinno nie być, ponieważ te literały są zdefiniowane na parametrach unsigned long long.

Pamiętam Howarda Hinnanta używającego 10'000s jako przykład podczas jego CppCon 2016 talk "A <chrono> tutorial" (około 42 minut w jego wykładzie).

---

(Należy pamiętać, że nie zamierzają kod "1 minutę i 23 sekund", który jest prawidłowe tylko przez przypadek, ponieważ ósemkowa dosłownewynosi 64 + 16 + 3 == 83. w tym celu należy napisać

auto time = 1min + 23s; 

ale możliwa interpretacja nie jest mylące część pytania).

Answer 1

Jeśli spojrzeć na gramatyce, zdefiniowany przez użytkownika liczbą całkowitą, dosłowne może byćósemkowy-dosłownym UD sufiksu i ósemkowy-dosłownym definiowany jest albo 0 lub ósemkowy-dosłownym” _opcjonalnie ósemkowej cyfr.

N4140 §2.14.8

użytkownika zdefiniowanej dosłownym:

• zdefiniowany przez użytkownika jest liczbą całkowitą, dosłownym
• [...]

zdefiniowany przez użytkownika-całkowita-literalna:

• ósemkowy-dosłownym UD sufiksu
• [...]

N4140 §2.14.2

ósemkowy-dosłowny:

• 0
• ósemkowy-dosłowny” _opt ósemkowy-cyfrowy

Więc 01'23s jest całkowicie poprawny dosłowne.

Answer 2

WLOG do literałach przecinku:

[lex.ext]:

zdefiniowany przez użytkownika jest liczbą całkowitą, dosłownym:
        dziesiętny dosłownym UD sufiksu

[lex.icon]:

dziesiętny-dosłowny:
        niezerowe cyfry
        dziesiętny-dosłowny   ’ _opt   cyfra

tj. tak, separatory cyfr są dozwolone w UDL.

Answer 3

To wydaje się być błędem w implementacji GCC biblioteki <chrono>, jak zasugerował @Aaron McDaid. Jest (obecnie niepotwierdzone) raport o błędzie: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905

libstdC++ GCC realizuje dwa podpisy std::chrono_literals:

constexpr chrono::duration<long double> 
operator""s(long double __secs) 
{ return chrono::duration<long double>{__secs}; } 

template <char... _Digits> 
    constexpr chrono::seconds 
    operator""s() 
    { return __check_overflow<chrono::seconds, _Digits...>(); } 

Wersja szablonu dając błędu nie jest wymagane przez normy. Dodając

constexpr chrono::seconds 
operator""s(unsigned long long __secs) 
{ return chrono::seconds{__secs}; } 

do nagłówka <chrono> (mojej instalacji lokalnej) na dissappears błędach.

jednak realizatorzy biblioteki GCC mogły pominąć tę wersję na celu, dzięki czemu mogą one zapobiec niepożądanym unsigned do podpisanego nawrócenia, ponieważ sekundy są zdefiniowane jako

typedef duration<int64_t> seconds; 

---

Edit:

Jak ostatnio zauważył Jonathan Wakely w komentarzach do raportu o błędzie, , implementacja została wybrana zgodnie z projektem w połączeniu z open Library Working Group issue, ale nie została wykorzystana separator cyfr s pod uwagę.