G CC поддержка строковых литералов времени компиляции - PullRequest
Новая
       83

G CC поддержка строковых литералов времени компиляции

0 голосов
/ 11 июля 2020

C ++ 20 вводит типы классов в параметрах шаблона, не являющегося типом . Как упоминалось в предложении, одной из мотиваций были строки времени компиляции, и это позволяет делать это : 

template < size_t size >
struct Literal : std::array<char,size>
{
  constexpr Literal(char const (&str)[size+1]) { for (size_t ii = 0; ii < size; ++ii) (*this)[ii] = str[ii]; }
};
template < size_t size > Literal(char const (&str)[size]) -> Literal<size-1>;
template < Literal literal > constexpr auto operator "" _lit() { return literal; }

template < Literal > struct Use { };
Use<"foo"_lit> use;

В предложении также говорится:

Было несколько предложений [N3599] [P0424R0] по ослаблению запрета на строковые пользовательские литералы, которые принимают свою необработанную форму в качестве отдельных аргументов шаблона char, и пока все эти предложения не получили консенсуса.

Основная проблема, которая возникает в ответ на такие предложения, заключается в том, что обработка строк как пакетов аргументов шаблона char является чрезвычайно затратной с точки зрения использования ЦП компилятора и памяти, а разрешение таких UDL приведет к очень большим пакетам значений char. гораздо более распространены, чем сегодня. Это, в свою очередь, может привести к тому, что поставщики компиляторов заставят свои продукты хорошо работать при таких рабочих нагрузках обработки строк во время компиляции, что затруднительно из-за того, что строки представлены с использованием синтаксиса и механизма, которые никогда не предназначались для поддержки таких вариантов использования.

Таким образом, хотя это не упоминается напрямую, я предполагаю, что это предложение было разработано, чтобы избежать чрезвычайно дорогостоящего использования процессора и памяти компиляторами при работе со строками времени компиляции. Возможно, это станет возможным из-за подхода к искажению и использования оператора трехстороннего сравнения , упомянутого в первом разделе предложения. Верно ли это предположение?

gcc-9.3 не поддерживает оператор трехстороннего сравнения , но поддерживает типы классов в параметрах шаблона без типов . Однако наличие строк времени компиляции вышеупомянутым способом с gcc-9.3 на самом деле, кажется, приводит к чрезвычайно дорогостоящему использованию ЦП и памяти .

Есть ли подходящий флаг для gcc-9 или gcc-10, что будет настраивать компилятор под такой код?

...