Здравствуйте, Sinclair, Вы писали:
CC>>ICX это уже не интел, это Clang/LLVM S>Это отговорки. Во-первых
Они сдались и перешли со своего компилятора на clang.
S>Ну, вот он, ключ к успеху. Сначала нужно вообще узнать, что этот код неправильно работает.
Да как то я сразу так написал и оно сразу работало.
S>И всё равно, первый же залетевший дятел ломает всю цивилизацию: S>https://godbolt.org/z/8jz98GEaK
У меня в реальном коде как раз всё с переменными (BigNumber, все значения из памяти читаются) и работает.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
S>Если это происходит в той ветке, где был null pointer dereference, то это — легальное поведение компилятора.
Вот только "веткой" оно считало здоровенный кусок кода через несколько уровней вызовов функций.
S>Вот, скажем, у вас пока что не получилось починить функцию is_max, даже на вашем любимом компиляторе
Да я и не пытался особо.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kov_serg, Вы писали:
CC>>А теперь расскажи во сколько раз это замедлит выполнение всего кода. _>Тут не в скорости дело, а в гибкости.
Тогда и писать надо на гЫбких языках а не на плюсах.
Или трусы или крестик, по другому в реальности не получится. За всё надо платить.
_>Вы не поняли, можно сравнивать результаты выполнения одних и тех же функций для проверки разных гипотез, применяемых для оптимизации. _>Например для выявления явной фигни, которую генерит компилятор в случае UB, poison и т.п.
А VM то для этого зачем?
CC>>Это всё называется инструментация _>Нет инструментация, это на реальном железе. Тут можно на модели железа, делать разные модели out-of-order построителней графов исполнения и анализа их загруженности (утилизации).
Для этого берут эмулятор железа а не язык с VM.
_>Вот зачем вам godbolt
Абсолютно незачем. Я на результаты выхлопа компилятора смотрю в IDA и VTune. Никакой godbolt с этой парочкой и рядом не валялся.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Твой пример всё ещё компиляется ICC, который я выставил для демонстрации разницы.\
И ICC выдаёт oops. Напомню: задача — выдавать wow независимо от флагов оптимизации. Хотя бы в одном компиляторе, по вашему выбору
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
CC>У меня в реальном коде как раз всё с переменными (BigNumber, все значения из памяти читаются) и работает.
Ну, значит, у меня — нереальный код.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, so5team, Вы писали:
A>>Виртуальная машина тем и хороша, что позволяет всё приводить к единому знаменателю. S>Знаменатель, который получился у Java вам, вроде бы, не понравился. Хотя на Java таки можно было написать GUI приложение, которое работало бы и на X-ах, и на Windows.
Java это же не монолит. Как и автомобиль. Когда покупаешь автомобиль, всегда смотришь: у одного колёса большие и дорожный просвет. У другого двигатель мощный. У третьего салон большой. У четвёртого GUI хороший. А пятый ты можешь себе позволить
Здравствуйте, rFLY, Вы писали:
FLY>Это очевидно, но в чем профит для программиста от var, fn, ":" и стрелочек для объявления типа возвращаемого значения? Они только загромождают код, да и писать их каждый раз. Короче я такой эстетики не понимаю. FLY>Текущие же инструменты как-то справляются без всего этого.
Не справляются.
FLY> Их авторы все равно не станут с нуля разрабатывать парсер, а переделают имеющийся.
Какой имеющийся? То что для C++, неизбежно включающее в себя интерпретатор подмножества языка — в таком виде ни на что непригоден.
Здравствуйте, rFLY, Вы писали:
S>>Смысл-то в том, что сишный стиль декларации переменных, скажем политкорректно, изживает себя. FLY>По этому вернемся к Паскалевской декларации? Мы тут полвека промучались и поняли, что это тупик, давайте еще дальше откинемся.
"Паскалевская" декларация не тупик, это как раз единственный на сейчас беспроблемный стиль. Но чтобы понять это, надо было не просто создать C, а добиться, чтобы его стали использовать все.
S>>Тогда к чему вопросы. Вы хотите, чтобы кто-то убедил вас что ваш вкус -- он самый правильный? FLY>Вопрос у меня один — зачем оно если можно без него? Может я чего-то не догоняю, но не вижу приемуществ от этих двоеточий и маркеров объявлений, от которых только рябит в глазах.
Здравствуйте, pagid_, Вы писали:
Pzz>>К сишному ABI на данной платформе. В Go именно так и сделано. Иначе interop с С/C++ будет очень геморройным. _>И на каких платформах с int не в 32 разряда Go работает? На каких-то микроконтроллерах? На МS-DOS, на Win16 ?
Ты не в ту сторону думаешь
Сейчас раздаётся заметное количество голосов, чтобы на 64-битных платформах int был тоже 64-битным. Потому что сразу упрощается дофига аспектов.
А фиксация его на 32 битах создаёт легаси, которое не позволит это.
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, so5team, Вы писали:
S>>Чтобы можно было отличать переменные от констант. FLY>Есть const — значит константа, нет cons — значит переменная, без всяких там var вначале.
Сейчас умолчание лучше делать наоборот
Или разделять let и var.
(Но лучше не val и var, как в котлине. Автор этого решения обидел весь Китай)
Здравствуйте, Nuzhny, Вы писали:
A>>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу?
N>С/С++ это системные языки. Соответственно, дождны быть типы данных, размер которых равен размеру машинного слова. В С/С++ это int, size_t, intptr_t, ptrdiff_t etc. Если ты не понимаешь значимости таких типов, то язык просто не для тебя, работай с другим. Тут без шуток и всякого унижения, без этого в принципе НИКАК, введение таких типов — это попытка сделать безопаснее то, что небезопасно и от чего уходят в других языках.
Беда в том, что с приходом массовых 64-битных платформ вот это твоё
>> типы данных, размер которых равен размеру машинного слова
или стало неверным, или потеряло корректность. Машинное слово — или честные полные 64 бита (как на Alpha, RISC-V, много где), или один из двух поддерживаемых для основных операций вариантов (x86, ARM, MIPS, тоже много где).
И твой список это чётко показывает — на amd64 int будет 32 бита, а size_t, ptrdiff_t, intptr_t — 64 бита. Уже сломано.
Идеи про сделать int 64-битным витают давно и есть новые языки, где это сделано. И не только новые — Forth это имел с первых портов, потому что в нём one cell должен уметь включать указатель, а операции с целыми работают с полным cell.
Здравствуйте, Alekzander, Вы писали:
A>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу? Твою программу перенесли на другую платформу без изменения одной строчки кода, и у юзеров ВДРУГ появился доступ к расширенному диапазону? Так никто не пишет лет тридцать уже. Все типы должны иметь однозначно и строго заданный размер, точка A>Если у тебя все типы имеют размер, что делать в редких ситуациях, когда тебе нужно явно указать самый распространённый целый знаковый? Некоторые заставляют писать i32, некоторые дают алиас int. Последнее предпочтительнее, глаза цифрами не мозолить
Знаешь, в чём твоя ошибка? Ты путаешь _размер_ представления где-то в памяти и _множество значений_, а путаешь ты потому, что слишком заточился на метод мышления C, где они насильно (каламбур) отождествлены.
Если бы ты больше вспоминал языки чуть более высокого уровня (а не портабельный ассемблер, и неважно, с классами или нет), то ты бы вспоминал паскалевские (и потомков) определения типа "type temperature = new range -50...+80" и для этого было бы неважно, куда будет тебе это число помещать компилятор — в AL, AX, EAX или RAX, со смещением (перемасштабировав на 0...130) или нет, и так далее. Реально пофиг.
Должно было быть важно, как эти типы передаются вовне, как печатаются в I/O, влезают ли в конкретное гнездо в 8 бит, которое у тебя в структуре (явно помеченной как склад битовых полей! иначе неважно), и чтобы, если бы ты запросил (или по умолчанию) выход за границы вызывал бы исключение (ставил флаг ошибки, etc.), а иначе — работал бы тоже как-то иначе.
В call convention ABI этого много есть, например, в таком виде: "целочисленный параметр должен занимать целый регистр и знаково расширен до полной ширины даже если он беззнаковый" (пример для RISC-V). Это уже дело компилятора, линкера и прочих, а не твоё.
И только для согласования с конкретными тараканами нижнего уровня тебе реально нужен тип данных вроде "int_native". Но ты можешь описывать конкретный тип как "signed(10)" вместо "range -512...511", если ты думаешь в мышлении битовых полей. Нивапрос. Главное — следить за _использованием_ и _операциями_, а также требовать контроля множества значений, где важно.
А вот когда ты начинаешь думать вместо "range -50...+80" в понятиях типа int8_t, ты берёшь на себя лишнюю работу за компилятор и при этом мешаешь компилятору делать правильные выводы о твоих намерениях.
В 70-е подходы с правильной типизацией в стиле Pascal/Modula/Ada были преждевременными. Сейчас они, наоборот, безумно отсталые, смотреть надо вперёд. А не назад, как в C.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Alekzander, Вы писали:
A>>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу? Твою программу перенесли на другую платформу без изменения одной строчки кода, и у юзеров ВДРУГ появился доступ к расширенному диапазону? Так никто не пишет лет тридцать уже. Все типы должны иметь однозначно и строго заданный размер, точка A>>Если у тебя все типы имеют размер, что делать в редких ситуациях, когда тебе нужно явно указать самый распространённый целый знаковый? Некоторые заставляют писать i32, некоторые дают алиас int. Последнее предпочтительнее, глаза цифрами не мозолить
N>Знаешь, в чём твоя ошибка? Ты путаешь _размер_ представления где-то в памяти и _множество значений_, а путаешь ты потому, что слишком заточился на метод мышления C, где они насильно (каламбур) отождествлены.
N>Если бы ты больше вспоминал языки чуть более высокого уровня (а не портабельный ассемблер, и неважно, с классами или нет), то ты бы вспоминал паскалевские (и потомков) определения типа "type temperature = new range -50...+80" и для этого было бы неважно, куда будет тебе это число помещать компилятор — в AL, AX, EAX или RAX, со смещением (перемасштабировав на 0...130) или нет, и так далее. Реально пофиг. N>Должно было быть важно, как эти типы передаются вовне, как печатаются в I/O, влезают ли в конкретное гнездо в 8 бит, которое у тебя в структуре (явно помеченной как склад битовых полей! иначе неважно), и чтобы, если бы ты запросил (или по умолчанию) выход за границы вызывал бы исключение (ставил флаг ошибки, etc.), а иначе — работал бы тоже как-то иначе.
N>В call convention ABI этого много есть, например, в таком виде: "целочисленный параметр должен занимать целый регистр и знаково расширен до полной ширины даже если он беззнаковый" (пример для RISC-V). Это уже дело компилятора, линкера и прочих, а не твоё.
N>И только для согласования с конкретными тараканами нижнего уровня тебе реально нужен тип данных вроде "int_native". Но ты можешь описывать конкретный тип как "signed(10)" вместо "range -512...511", если ты думаешь в мышлении битовых полей. Нивапрос. Главное — следить за _использованием_ и _операциями_, а также требовать контроля множества значений, где важно.
N>А вот когда ты начинаешь думать вместо "range -50...+80" в понятиях типа int8_t, ты берёшь на себя лишнюю работу за компилятор и при этом мешаешь компилятору делать правильные выводы о твоих намерениях.
N>В 70-е подходы с правильной типизацией в стиле Pascal/Modula/Ada были преждевременными. Сейчас они, наоборот, безумно отсталые, смотреть надо вперёд. А не назад, как в C.
А мне зачем эти абстракции нужны? Чтобы они протекли? Чтобы поиметь лишний геморрой при сопряжении с каким-нибудь LPARAM, из которых (сопряжений) реальная работа разработчика и состоит чуть менее, чем полностью? (Ничего себе, "И только для согласования с конкретными тараканами нижнего уровня"!) Или чтобы нельзя было прикинуть размер файла с данными?
Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия? Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен. Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов. Тем и отличается практично мыслящий разраб от архитектурного космонавта. (Любезность за любезность ).
К счастью, это тот случай, когда вместе со мной ошибаются и путают все мейнстримные создатели новых языков.
Кстати. Я недавно решал проблему типов для конечных юзеров. Изначально тоже такой: все кругом дураки, инты-шминты, флоаты-шмоаты, даже на уровне юзеров, ну а я-то в юзабилити разбираюсь мала-мала, у меня будут "число", "текст" и так далее. Но когда начал прорабатывать конкретные сценарии использования и потенциальные проблемы, меня это быстро приземлило. Есть невидимые рельсы (к ним относится система стандартных типов), по которым катит весь софтварный мир, их лучше и придерживаться. Даже на уровне юзеров. А самые умные пусть едут на велосипеде с квадратными колёсами по бездорожью
Здравствуйте, netch80, Вы писали:
N>"Паскалевская" декларация не тупик, это как раз единственный на сейчас беспроблемный стиль. Но чтобы понять это, надо было не просто создать C, а добиться, чтобы его стали использовать все.
Я говорил, что спустя полвека все вдруг решили вернуться к паскалевской декларации. А не то что она тупиковая.
Здравствуйте, netch80, Вы писали:
N>Не справляются.
Это проблем только С, в C# за такое ты получишь ошибку
void f(double my_dbl) {
int i(int(my_dbl));
}
N>Какой имеющийся? То что для C++, неизбежно включающее в себя интерпретатор подмножества языка — в таком виде ни на что непригоден.
Причем здесь С и С++? Мы же говорим о новых языках, которыми мечтают их заменить. Зачем все, что нагородили и позволяется в C, тащить в новое, почему не сделать так, чтобы не возникало неоднозначностей и прочего?
Здравствуйте, netch80, Вы писали:
N>Сейчас раздаётся заметное количество голосов, чтобы на 64-битных платформах int был тоже 64-битным.
Зачем? N>Потому что сразу упрощается дофига аспектов.
Каких?
).
