LINUX.ORG.RU

C++ invalid conversion

 , , недосып


0

2

При попытке собрать ругается:

$ g++ *.cpp -o test
text.cpp: In member function ‘void TEXT::AddInt(unsigned int)’:
text.cpp:64:19: error: invalid conversion from ‘int’ to ‘char*’ [-fpermissive]
   64 |   AddText(snprintf(buf, 7, "%i", i));
      |           ~~~~~~~~^~~~~~~~~~~~~~~~~
      |                   |
      |                   int
Не пойму что не правильно и где он увидел int?
Вот код:
#include <cstring>
#include <cstdlib>
#include <cstdio>
#include "text.h"
...
void TEXT::AddInt(unsigned int i)
{
  char buf[7];
  //AddText(itoa(i,buf,10));
  AddText(snprintf(buf, 7, "%i", i));
}

★★★★☆

Последнее исправление: superuser (всего исправлений: 2)
Ответ на: комментарий от anonymous

Все тебе надо разжевывать, чучело. Вот твой код


    static const int arrs[10]{}; // вот твой инт
    constexpr const int* y = arrs + 11; // от того что ты тут поменяешь на auto ничего не изменится
    //constexpr int x = *y;

anonymous
()
Ответ на: комментарий от anonymous

Где пруф на твой вскукарек

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

??? Побежал доказывать. Подмена const int* на auto тебе не помогла.

anonymous
()
Ответ на: комментарий от anonymous

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

Я сразу фбсу сказал что эта убогая херота не спасает в 100% случаев и вообще что с++ говнина. Ты лишь доказал этот факт, но обосрался в понимании того, как реализован constexpr и что он может, а чего нет.

anonymous
()
Ответ на: комментарий от anonymous

И что ты хочешь мне доказать, тут ты уже того же самого не получишь. Одна реализация трактует это поведение так, вторая эдак. Вот и все. Ты снова обосрался щенок. Кстати к вопросу об существовании УБ, вот яркий пример что УБ не существует и что УБ == зависит от реализации.

$ g++ prog.cc -Wall -Wextra -I/opt/wandbox/boost-1.73.0/gcc-10.1.0/include -std=gnu++2a

Start prog.cc: In function ‘int main()’: prog.cc:5:23: warning: unused variable ‘y’ [-Wunused-variable] 5 | constexpr const int* y = arrs + 11; | ^ 0 Finish

anonymous
()
Ответ на: комментарий от anonymous

И что ты хочешь мне доказать, тут ты уже того же самого не получишь. Одна реализация трактует это поведение так, вторая эдак.

Если я не вижу твоих признаков — так это потому, что ты на них не надеешься.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Просто в проекте шланга видимо такие же фантазеры как и ты код пишут и принимают

Думаешь, за подсасывание твои хозяева из GNU покинут тебе мозоль штульмана на пропитание?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

И большинство кода написано из того поведения которое дает gcc.

Побежала, собака, доказывать.

anonymous
()
Ответ на: комментарий от anonymous

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

И? Можно получить UB при разыменовании, а можно получить UB и без разыменования.

anonymous
()
Ответ на: комментарий от anonymous

И большинство кода написано из того поведения которое дает gcc.

Так идиотов большинство. Одни пишут компиляторы GCC, другие — код, который работает только под ними.

anonymous
()
Ответ на: комментарий от anonymous

Стоит спросить с тебя пруфы — ты мгновенно сливаешься.

anonymous
()
Ответ на: комментарий от anonymous

Можно получить UB при разыменовании, а можно получить UB и без разыменования.

Повторю еще раз, указатель на элемент сразу за концом массива - не UB.

anonymous
()
Ответ на: комментарий от anonymous

Повторю еще раз, указатель на элемент сразу за концом массива - не UB.

И? А дальше, чем сразу за концом — UB.

anonymous
()
Ответ на: комментарий от anonymous

И? А дальше, чем сразу за концом — UB.

Я просто хотел разбавить ваш спор, что UB - это только разыменование, а получение любого адреса - это хорошо.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Это тоже зависит от реализации на самом деле. Реализация может быть какой угодно лишь бы она не противоречила стандарту.

anonymous
()
Ответ на: комментарий от anonymous

«И без» ты можешь получить только конкретным компилятором в котором этот функционал даже в релиз еще не попал

Идиот, clang умеет ловить подобное UB с 3-й версии. А твои хозяева из GNU просто не осилили ни создание ОС, ни компиляторов.

Сколько мозолей ты получаешь за каждый комент в их защиту?

anonymous
()
Ответ на: комментарий от anonymous

Это тоже зависит от реализации на самом деле.

Это записано в стандарте - нельзя получать любой адрес, используя адресную арифметику.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

А при чем тут любой адрес, разговор не о любом адресе, а о том как реализован массив.

anonymous
()
Ответ на: комментарий от anonymous

Так какого хрена ты тогда это показываешь на последней

Чтобы твою сраку разворотило

Если он умеет подобное ловить в 3 версии это все равно еще расхождение с другой реализацией

Это у другой реализации расхождение с эталонной.

anonymous
()
Ответ на: комментарий от anonymous

Чтобы твою сраку разворотило

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

Это у другой реализации расхождение с эталонной.

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

anonymous
()
Ответ на: комментарий от anonymous

Не идиотам очевидно лишь то, что ломать совместимость со старым кодом и старым поведением это благо. А тут Васяны вроде тебя решили отличится своим особым «пониманием» работы constexpr и нагородили херни из под себя, подобно тебе. И закладываться на такое, значит закладываться на реализацию. Так что очевидно, что идиоты только те кто закладываются, а не пишут кросскомпиляторный код.

anonymous
()
Ответ на: комментарий от anonymous

Не идиотам очевидно лишь то, что ломать совместимость со старым кодом и старым поведением это благо.

Ты правда настолько дебил или придуриваешсья? constexpr появился в C++11 и правильно реализован Clang-ом практически сразу. Никакого старого кода с constexpr, ожидающего какого-то другого поведения, нет.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

он реализован не правильно

Пруф, быстра.

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

Не говорит.

И ни один нормальный разработчик на твой дношланг в свой проект тащить не спешил

100% пиздёж.

anonymous
()
Ответ на: комментарий от fsb4000

Аноним, нести пургу я тоже могу.

Это у тебя получается лучше всего.

А я пожалуй забью на эту тему.

Правильное решение. Стандарт C++ — это не твоё. Вернись к PHP. Кто трусы ребятам шьёт? Ну конечно не пилот. На PHP тоже кто-то писать должен.

anonymous
()
Ответ на: комментарий от anonymous

Кстати, проверил твой пример в VS 2019, получил: https://imgur.com/a/6sHmpmV

https://docs.microsoft.com/ru-ru/cpp/error-messages/compiler-errors-1/compiler-error-c2131?view=vs-2019

Про i=i++ + i создал баг репорт на сайте Microsoft. Посмотрим что ответят.

Все остальные примеры и так давали ошибки компиляции.

UB в constexpr запрещён, просто разные компиляторы по разному считают что такое UB. Создавай баг репорты в gcc, если 100% считаешь, что должны быть ошибки компиляции.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 2)
Ответ на: комментарий от fsb4000

UB в constexpr запрещён, просто разные компиляторы по разному считают что такое UB

Нет, просто GCC писан рукожопами и они не умеют ловить каждое UB в constexpr.

Создавай баг репорты в gcc, если 100% считаешь, что должны быть ошибки компиляции.

Багов про constexpr в GCC и так мириады, почти на 100% уверен есть и про код типа моего.

anonymous
()
Ответ на: комментарий от fsb4000

UB в constexpr запрещён

Нет. В constexpr запрещен некоторый ограниченный набор ситуаций, который может привести к UB.

Чтобы однозначно запретить любой UB, придется написать непротиворечивый подязык для constexpr. Например, свести всю логику к арифметике Пеано, а это - прощай Тьюринг-полнота constexpr-выражений.

anonymous
()
Ответ на: комментарий от fsb4000

Да не должно там быть ничего, да и смысла особого нет, все это решается препроцессорными вставками, хотя проще вообще исходить из поведения которое в gcc чтобы не замусоривать код этими препроцессорными вставками. Просто пацаны из llvm решили что у них будет более «интеллектуальный» constexpr который может раскрутить выражение дальше и предположить что далее указатель будет разыменован, хотя это бред он не должен так работать и они просто залезли таким поведением за край области интересов constexpr.

Мальчик этот, который тут бухтит, может конечно сказать что - «почему это он не должен?!», а не должен он потому, что не его собачье дело для чего мне нужен такой указатель за пределы массива и буду ли я его разыменовывать, важно лишь то, что в конкретно том присваивании значение справа от знака присваивания вычислимо и однозначно.

anonymous
()
Ответ на: комментарий от anonymous

Нет, просто GCC писан рукожопами и они не умеют ловить каждое UB в constexpr.

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

anonymous
()
Ответ на: комментарий от anonymous

В conxtexpr и так нет Тьюринг-полноты

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

anonymous
()
Ответ на: комментарий от anonymous

Ты решил придраться сам не зная к чему?

Зная к чему.

У любой программы на реально существующей вычислительной системе, созданной человеком, нет Тьюринг-полноты.

Тем более у constexpr-эвалуатора, у которого руки выкручены по самое не хочу. То нельзя, это нельзя…

anonymous
()
Ответ на: комментарий от anonymous

Тем более у constexpr-эвалуатора, у которого руки выкручены по самое не хочу. То нельзя, это нельзя…

И как, получается выкручиванием рук получить непротиворечивую систему? Или лучше действовать наоброт - взять непротиворечивую систему и строить на нем что-то гарантированно рабочее, а не математическим тыком выкручивать случайно попавшиеся руки?

anonymous
()
Ответ на: комментарий от anonymous

Или лучше действовать наоброт - взять непротиворечивую систему и строить на нем что-то гарантированно рабочее

Пока что так получились только борщехлёбские язычки.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.