Making all std::char_traits functions constexpr

Anton Bikineev
Anton Bikineev

Идея сделать только 4 функции константными выражениями выглядит как ад-хок решение для string_view быть константным выражением. Почему некоторые функции остались без внимания? Что, если они будут нужны потом? Что вы скажете своим детям? Вы или они будете писать дефект репорт и еще один пропозал?

Кто-то может оказаться лучшим Нострадамусом чем я и сказать, что констэкпрессность не понадобится для других функций. Тогда давайте поподробнее про дефект репорты. Рассмотрим пару из них, которые, насколько я понимаю, были заапрувлены на митинге:

  • DR2777:basic_string_view::copy should use char_traits::copy
  • DR2778:basic_string_view is missing constexpr

Первый репорт обязывает сделать basic_string_view::copy через char_traits::copy, а второй репорт, в частности, предлагает сделать basic_string_view::copy констэкспр. Но как вы сделаете the latter констэкспр без the former констэкспр?

Предлагается наиболее полно реализовать констэкспрессность промежуточного уровня, а именно, char_traits, переходя к констэкпрессности более высокого уровня, а именно string_view.

3
рейтинг
5 комментариев
Victor Dyachenko
Как char_traits::copy() и char_traits::length() сделать constexpr, если одна из эффективных реализаций - ассемблер? Компиляторную магию не предлагать - её и так уже слишком много в современном C++. Проблема общая для языка. Хочешь compile-time - можешь потерять производительность в run-time. Хочешь гарантированно эффективный run-time - не получишь compile-time вообще.
Victor Dyachenko
Anton Bikineev
Victor Dyachenko, length уже заапрувлена быть констэкпр. В libc++ сделана через констэкспрессный __builtin_strlen. copy может быть сделана через __builtin_strcpy или __builtin_memcpy.
Anton Bikineev
Victor Dyachenko
> __builtin_
Вот это я и имел в виду под компиляторной магией. Очень плохо, что сегодня разработчик стандартной библиотеки находится в более привилегированном положении, чем любой другой. В ANSI C такого не было, стандартная библиотека могла быть полностью реализована на стандартном C + asm. Обычному разработчику на каждый чих за новым __builtint_ к компиляторописателям не набегаешься...
Я не против, чтоб string_view мог инициализироваться во время компиляции, даже всеми руками за. Но вот способ, которым это пытаются решить... В очередной раз заметают более общую проблему под коврик, вместо того чтобы её решать. А ведь бумага с её изложением вышла сразу поле выхода C++11 (с ходу не найду, но на open-std.org она есть). С тех пор воз и ныне там :-(
Victor Dyachenko
Victor Dyachenko
Нашёл: open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3583.pdf
Тут описывается пример с вычислением квадратного корня. В run-time на x86 это делается одной машинной инструкцией "fsqrt", но это нельзя использовать в compile-time. Для compile-time написать можно, но в run-time будет сильно неэффективно. Тут такие же случаи.
А сompiler intrinsic не переносимы. И GCC с Clang'ом не единственные C++ компиляторы.
Victor Dyachenko
yndx-antoshkka
Сейчас один разработчик из международного комитета занимается как раз этой проблемой и хочет сделать constexpr char_traits::copy. Помочь ему мы наврядли сможем.
yndx-antoshkka
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).