C++ invalid conversion

Определение AddText() в студию …

В нормальной IDE, которая подчеркнула проблему еще до момента компиляции, совсем никак писать код?

int snprintf ( char * s, size_t n, const char * format, … );

Теперь понятно?

Ладно помогу - snprintf() не строку возвращает

Владимир

упс... спасибо, запарился

ИМХО тред можно и удалить.

Владимир

Шел 2020й год, в коде на Си++, до сих пор продолжали использовать сишные ф-ии и заголовочные файлы... :(

Зачем тянуть строки если и без них можно обойтись в ардуине?

Ты не поверишь, но многие берут С++ только из за возможности иметь статический полиморфизм уровня перегрузки функций и наличия в С++ немспейсов, а дальше просто продолжают писать как на С, просто потому что все остальное в С++ эталонное «ненужно».

ИМХО тред можно и удалить

Ни в коем случае. Теперь эта тема станет главной по C++ на лоре.

а дальше просто продолжают писать как на С

Ну правильно, надо же расширять ассортимент UB.

UB естественно для любой реализации, нет никакой разницы в выборе языка и том как его использовать.

std::to_chars

std::to_string

Кто сказал, что unsigned int влезет в семь символов при сериализации? Используй STL

Ну правильно, надо же расширять ассортимент UB.

В C++ есть модификатор для 100% безопасного кода, то есть часть функций гарантированна корректна. То что днища не пользуются таким модификатором, это проблема днищ…

Возможно когда-нибудь подобное появится и в других языках…

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

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

Пока нет такого языка. В Rust вообще нет безопасного кода, и ничего живут. А в С++ есть.

Лучшее что есть в Rust это Miri: https://github.com/rust-lang/miri

Но miri тоже не проверяет всё:

However, be aware that Miri will not catch all cases of undefined behavior in your program

А обычный «safe» Rust код дыряв, и много этому уже примеров…

А вот compile-time функции в С++ на 100% избавлены от любых вариантов UB.

А вот compile-time функции в С++ на 100% избавлены от любых вариантов UB.

Пруфы будут?

UB он и в Африке compile-time - UB

Не пойму что не правильно и где он увидел int?

А сигнатуру snprintf посмотреть не? А подумать зачем же туда buf передаётся не?

Пруфы будут?

Стандарт конечно:

https://isocpp.org/files/papers/N4860.pdf

Параграф 7.7 Constant expressions:

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine (6.9.1), would evaluate one of the following:

…

an operation that would have undefined behavior as specified in Clause 4 through Clause 15 of this document

Да просто перегруз и надо было поспать

Ты так говоришь, как будто любое выражение можно пометить constexpr, ведь очевидно что нет. Давай оправдывайся за свои выкрики со дна. Чем там говоришь дно не пользуется, в чем там говоришь оно виновато?

Постеснялся бы тут бравировать этим убогим костылем, как и весь С++ в общем-то…

За ссылку на новый стандарт спасибо.

некоторые в 2020 ещё втирают, что c++ не c++, если ты не обмазался щаблонами…

Это про то, что можно считать «core constant expression».

А в общем случае выражение может быть с UB. И во что оно скомпилируется неизвестно - неопределено. Что-то похожее на ill-formed. Хорошо, если компилятор просто ругнется, а может некорректный код/константу вставить, или отформатировать жесткий диск во время компиляции (хотя там есть некая вирт.машина, которая возможно не умеет форматировать жесткий диск)

Ты так говоришь, как будто любое выражение можно пометить constexpr, ведь очевидно что нет.

Да, не любое.

Но тут любят говорить что в С++ весь код UB. А так будут часть функций constexpr, которые будут в юниттестах давать ошибку компиляции, если найдётся UB.

И это ещё одна причина стараться всё делать constexpr и consteval, кроме возможного ускорения в runtime.

Ты несешь какую то ДИЧЪ помеченное спецификатором выражение такого толка просто не будет компилироваться, фбс тебе рассказывает про костыль для идиотов, когда ты помечаешь какое-то выражение и если компилятор может его вычислить на этапе компиляции то хорошо, если нет, то он тебе скажет что не может и собственно приплыли. Вот и вся хваленная 100% защита, на деле банальная пропаганда в ушки крестосектантов.

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

Ты несешь какую то ДИЧЪ

$ cat constub.cpp
static const int arrs[10]{};

void foo() {
    constexpr const int* y = arrs + 11;
}
$ g++ -c constub.cpp
$ g++ --version
g++ (Gentoo 9.3.0 p2) 9.3.0

Ну ты и клоун дядь… И что этот мертвый код должен доказать? Что выражение не противоречит constexpr спецификатору и может быть вычислено на этапе компиляции? По классике, снова в школу!

Ты можешь делать любой указатель, UB будет когда произойдёт разыменование указателя.

Попробуй так:

static const int arrs[10]{};

void foo() {
    constexpr const int* y = arrs + 11;
    constexpr int x = *y;
}

main.cpp: In function 'void foo()':

main.cpp:5:23: error: array subscript value '11' is outside the bounds of array 'arrs' of type 'const int [10]'

    5 |     constexpr int x = *y;

      |                       ^~

main.cpp:1:18: note: declared here

    1 | static const int arrs[10]{};

      |                  ^~~~

Чуть изменил. Разыменование

$ cat constub.cpp
static const int arrs[10]{};

constexpr int foo() {
    return *(arrs + 11);
}

$ g++ -c constub.cpp

При этом сlang ругается, включая первый вариант без разыменования

Ну ок, gcc ругается: https://gcc.godbolt.org/z/3ZRMof

constexpr функции могут вызываться в runtime и compiletime. Чтобы были проверки нужно вызывать в compiletime.

Я и писал, что этим и полезно писать всё что можно как constexpr, даже если в работе все эти функции будут вызываться с рантайм параметрами, так как можно писать constexpr unit тесты…

Надо бы еще проверить проблему останова посредством бесконечного цикла и/или рекурсии. :)

Вот еще constexpr UB

constexpr int foo() {
    int i = 0;
    i = i++ + i;
    return i;
}
constexpr int i = foo();

А это больше не UB начиная с С++17

Посмотри тут слайды с 31 по 38: https://www.copperspice.com/pdf/Undefined-Behavior-CppCon-2018.pdf

Там и отсылки на стандарт, где читать, что поменялось и т.д.

Тут написано, что UB https://en.cppreference.com/w/cpp/language/eval_order#Undefined_behavior

В твоих слайдах, другой случай i=i++ + 1

Ok, понял.

Нужно писать баг разработчикам компиляторов, посмотрим что они ответят…

Дошколёнок, никакого УБ не существует - ты обгадился. Но ещё больше ты обгадился тогда, когда начал искать УБ в коде, который не исполняется. После подобной херни любые потуги дошколёнка тут же умножаются на ноль просто потому, что это бездарное трепло.

Тут написано

Дошколёнок, если ты кукарекаешь про стандарт для идиотов - ссылайся на стандарт. Какого хрена ты ссылаешься на какой-то левый букварь? Не осилил? В школу.

К тому же, это не является УБ. Никакого УБ в constexpr быть не может по определению, потому что в момент сборки всё поведение детерминировано, а вся логика изолирована.

Т.е. из УБ не следует ничего, что ты ему пытаешься, бездарная жертва пропаганды, приписать.

Для тех, кто не понял. Бездарный дошколёнок увидев какой-то фокус в интеренте прибежал и начал что-то кукарекать. Причём школопендра настолько тупая, что не смогла даже адекватный пример придумать и десять раз обгадилась.

То, что клоун показывает - это часть базовой семантики С++, где порядок вычисления аргументов функции не определён. И прикрути любой сайд-эффект - будет тоже самое.

Правда, из этого ничего не следует и всем на это насрать.

ссылайся на стандарт

В n4860.pdf, ссылка уже была. 6.9.1-10. В примерах даже приведен конкретно мой случай.

На красоту ++i + i++ меня не хватило.

в момент сборки всё поведение детерминировано, а вся логика изолирована

Отвечу твоими словами:

Дошколёнок, если ты кукарекаешь про стандарт для идиотов - ссылайся на стандарт.

Где написано, что всё детерминировано и логика изолирована?

Упустим суровые реалии в виде «строгость законов смягчается необязательностью их исполнения» компиляторописателями.

Где написано или доказано, что логика с++ непротиворечива?

PS. Царь, ты - птушник или где? Где у тебя знания про свойства формальных теорий, логик.

Идиот, читать умеешь?

… unless evaluation of E …

Пока твоя функция не вызывается, evaluation arrs + 11 не происходит.

в момент сборки всё поведение детерминировано

А в момент выполнения — нет?

начал искать УБ в коде, который не исполняется

В параграфе написано would evaluate, т.е. это гипотетическая ситуация. Сослагательное наклонение знаешь что такое?

Выражение E это константное выражение, только если вычисление E по правилам абстрактной машины цепепе, не вычисляло бы следующее: … операцию, помеченную бумажкой «UB» в разделах от X до Y этого документа …

В constexpr const int* y = arrs + 11;, вычисление arrs + 11 содержало бы неопределённое UB-поведение, значит это не константное выражение, значит оно не может быть инициализатором constexpr-переменной.

См. C++ invalid conversion (комментарий)

Ну ок, gcc ругается

Пук. Не ловят реализации всё возможное UB.

Пока твоя функция не вызывается, evaluation arrs + 11 не происходит.

Идиот, ты даже функцию вызвать не можешь? Вызови и посмотри.

Ну во-первых сослагательное наклонение предполагает субъективную возможность, а не объективную. Стандарт не может исходить с позиции субъективности, он обязан быть объективным. Твои танцы на цыпочках неуместны.

Во-вторых, ты путаешь возможность и реальность. Компилятор работает правильно, компилятор не должен заглядывать в будущее и «возможность» чего-либо (в конкретном случае что позже ты попытаешь разыменовывать такой адрес). В данном конкретном случае выражение можно вычислить. Так что перестань размазывать сопли и заниматься подлогом.

В constexpr const int* y = arrs + 11;, вычисление arrs + 11 содержало бы неопределённое UB-поведение, значит это не константное выражение, значит оно не может быть инициализатором constexpr-переменной.

Возьми да проверь, если и так не видишь что ты пишешь бред. В данном случае ты будешь получать один и тот же адрес постоянно равный смещению адреса arrs на 11. И это вполне вычисляемое на этапе компиляции значение.

В данном конкретном случае выражение можно вычислить.

Возьми да проверь, если и так не видишь что ты пишешь бред. В данном случае ты будешь получать один и тот же адрес постоянно равный смещению адреса arrs на 11. И это вполне вычисляемое на этапе компиляции значение.

Я проверил. Ты врёшь. Ты диванный кукаретик, а диванный кукаретик не может не обосраться

prog.cc:5:17: error: constexpr variable 'y' must be initialized by a constant expression
        constexpr auto y = arrs + 11;
                       ^   ~~~~~~~~~
prog.cc:5:26: note: cannot refer to element 11 of array of 10 elements in a constant expression
        constexpr auto y = arrs + 11;
                                ^

Там был int, а не auto, чучело.

Опять пытаешься подменой заниматься, думая что никто не заметит твоих подлогов. Не знаешь как auto работает - в школу.

Ты можешь делать любой указатель

Ты не можешь «делать любой указатель». Просвещайся.

Там был int, а не auto

Опять ты пытаешься подменой заниматься, думая что никто не заметит твоих подлогов? Там был const int*, а не int.