какая к дьяволу мафия с открытым инвайтом? ;)

я правильно понимаю, что constexpr выражения по сути вычисляются после генерации всех типов и шаблонных подстановок, поэтому в принципе не может быть способа перевода constexpr выражения в шаблонный параметр?

почему? constexpr size_t size = std::is_same<int, long>::value * 5 + 3; std::array<int, size> a;

хм...

вот аргумент constexpr функции не вытащить, ибо он может быть не constexpr

зачем так делать?

почему нет strict constexpr сигнатуры функции

вот аргумент constexpr функции не вытащить, ибо он может быть не constexpr

так?

вообще был пропозал сделать оператор constexpr(), который возвращал бы true, если текущий блок во время компиляции вычисляется

я бы сделал proposal что можно параметр constexpr функции помечать constexpr

if constexpr (constexpr()) { // а вот тут аргументы constexpr функции уже constexpr }

хорошая мысль кстати

ибо иногда часть аргументов может быть известна в compile-time

и разрешить перегрузку

о, спасибо, действительно так не надо делать

я вспомнил аргументы против :)

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

В случае указания параметров функции как constexpr компилятор может интерпретировать это как функцию, у которой параметры, помеченные constexpr, шаблонные

и соответствующие ограничения накладывать?

интерпретировать в точности как сахар для шаблонного параметра с подстановкой фактических значений

и что плохого?

а, это не работает, потому что шаблонный параметр не может быть значением user-defined type

*wall*

я бы сделал proposal что можно параметр constexpr функции помечать constexpr

Есть множество предложений на эту и похожие темы. В международном комитете их постоянно обсуждают, к единому мнению пока не пришли: нужно сделать приятный/читаемый синтаксис, не все компиляторы до сих пор умеют хорошо constexpr, есть непонятки как смешивать constexpr и не constexpr аргументы + надо сделать так, чтобы пользователь не писал две функции (одну с constexpr параметром, другую - без)

Есть множество предложений на эту и похожие темы. В международном комитете их постоянно обсуждают, к единому мнению пока не пришли: нужно сделать приятный/читаемый синтаксис, не все компиляторы до сих пор умеют хорошо constexpr, есть непонятки как смешивать constexpr и не constexpr аргументы + надо сделать так, чтобы пользователь не писал две функции (одну с constexpr параметром, другую - без)

Если вы в теме, еще вопрос: есть ли предложения сделать при вызове функции первой проверкой для constexpr типа integral type значение типа std::integral_constant<type, value>

т.е. разрешить фактически перегрузку функции по некоторым конкретным значениям переданных constexpr параметров

Есть что-то наподобие if (constexpr()) и при этом constexpr() - хитрая штука, которая возвращает не compile time констунту. Там много проблем возникает с ODR если делать иначе. В общем - пока рано обсуждать, разработчики компиляторов ещё не до конца определились как это должно выглядеть и как ничего не поломать таким кодом

..

Собственно, я могу описать задачу, с которой у меня это возникало using some_interface_uptr = std::unique_ptr<some_interface>; enum class align_h { none, left, center, right }; enum class align_v { none, top, middle, bottom }; //1 some_interface_uptr make_aligner_1(some_interface_uptr, align_h h, align_v v); //2 template <align_h h, align_v v> some_interface_uptr make_aligner_2(some_interface_uptr) {...} //redirect template <> some_interface_uptr make_aligner_2<align_h::none, align_v::none>(some_interface_uptr) {...} //you're doing it wrong, but I will let you и аналогичные конструкции в итоге встречаются достаточно часто, собственно. Вся функция в принципе не может быть constexpr. И хотя в этом случае компилятор еще кое-как можно сделать тупо произведение всех конфигураций, вроде оптимизация конструкций типа явное создание вектора с нулем элементов выглядит чрезвычайно целесообразной.

подскажите, есть ли какая-нибудь фича, чтобы среди дефолтных аргументов задавать аргумент, находящийся на конце, но при этом не перечислять все аргументы идущие до него? например void foo(int a=1, int b=2, int c=3, int d=4); можно ли как-нибудь сделать вызов, указав только d? то есть что-то вроде foo(d=10) ?

Boost named args есть в boost.parameter кажется

Давно хотел спросить. Есть ли реализация printf или подобного синтаксиса с полным type safety? грубо говоря, хочу L"width = %d, height = %d"_format(10, 20.0)

Fmt?

Fmt?

с тех пор прошло много времени, и у меня есть некоторая тонна инфы, в частности, что такой синтаксис по сути невозможен

Ок

Используй cout-style для тайпчекинга

Как таймер написать?

Хороший асинхронный (и снхронный) таймер - Boost.Asio

Как таймер написать?

Можешь у меня подглядеть

https://github.com/berkus/libuia/blob/master/include/uia/timer.h и timer_engine.h

Pointer Overflow Checking is in LLVM https://blog.regehr.org/archives/1518

почему нет strict constexpr сигнатуры функции

Я уже бомбил тут на эту тему

а, это не работает, потому что шаблонный параметр не может быть значением user-defined type

Ещё бомбил с того чтоб разрешить какие-нибудь поды

Литеральные типы*

Но мне сказали что это уже D какой-то получается

Во славу опенсорса - местный эвфемизм бесплатно? :)

Вообще у меня тоже есть потребность во славу опенсорса :) Хочу инвертер jpeg-искажений скриншотов

Я сам там ниасилил, какую метрику надо впихать для поиска деквантованных коэффициентов DCT

Кто нибудь знает как в MPIR передать значение числу в виде 10^1000? Если вообще такое возможно

Кто нибудь знает как в MPIR передать значение числу в виде 10^1000? Если вообще такое возможно

mpz_pow?

mpz_pow?

Такого в доках нет

Щас посмотрю в интернете

Щас посмотрю в интернете

Это же power видимо

То есть надо инициализировать ещё две переменные и посчитать результат

То есть надо инициализировать ещё две переменные и посчитать результат

ну степень это просто число

ну степень это просто число

Наверно так сделаю. Просто там есть способ строкой char ввести число я думал что может можно его просто ввести руками

Наверно так сделаю. Просто там есть способ строкой char ввести число я думал что может можно его просто ввести руками

а, можно ж в scientific format

1e1000

1e1000

Вот так и хочу. Я вообще там не заметил что нужно объявить перед инициализацией. Перед assignment.

всем привет в этом чате

Вот так и хочу. Я вообще там не заметил что нужно объявить перед инициализацией. Перед assignment.

ну scanf такой формат поддерживает вроде

ну scanf такой формат поддерживает вроде

Насколько я понял там все сложно. Аргумент для присваивания должен быть типа mpz_t или double или char. То есть просто записать не получится, double слишком маленький, а mpz_t я никак не могу присвоить значение если нет другой mpz_t

1е1000 это не точное число

1е1000 это не точное число

почему это?

почему это?

потому что как дабл не может быть представлен точно

Этот дабл вполне точно представляется как Infinity :)

потому что как дабл не может быть представлен точно

речь о mpir

Этот дабл вполне точно представляется как Infinity :)

в 80битном вроде 3172 ограничение порядка, нет?

Ну, я говорил про 64-битный.

в 64-битный не полезет, да

80-битный на всех платформах, которые я знаю, будет называться long double, если вообще там будет :)

80-битный на всех платформах, которые я знаю, будет называться long double, если вообще там будет :)

в мске я не уверен, что это не 64битный тип

при этом на практике компилятор может выполнять оптимизацию и все вычислить в 80битке, ничего не гарантируется

даже если операция с double

Мне тоже почему-то припоминается, что у MS вообще нет 80-битного типа. Ну а в gcc / clang он есть (по крайней мере на Интеловской архитектуре).

Мне тоже почему-то припоминается, что у MS вообще нет 80-битного типа. Ну а в gcc / clang он есть (по крайней мере на Интеловской архитектуре).

The major reason is that FP code generation has been switching to the use of SSE/SSE2/SSE3 instruction sets instead of the x87 FP stack since that is what both the AMD and Intel recent and future chip generations are focusing their performance efforts on. These instruction sets only support 32 and 64 bit FP formats.

типа причина

угу, найсыч причина. Помню, что у моего начальника был ноут без поддержки SSE2 году в 2010, примерно

угу, найсыч причина. Помню, что у моего начальника был ноут без поддержки SSE2 году в 2010, примерно

а сообщение 2006 :)

просто я до сих пор не уверен, что MS по дефолту вообще компилит с разрешенным SSE2

я ща скажу

ну если 17й есть, интересно даже