Муки выбора языка программирования

https://frama-c.com/2012/07/25/On-the-redundancy-of-C99-s-restrict.html

Не было бы у плюсов стандарта, не было бы и никакого UB, все дружно хрюкали, что плюсы без этой гадости.

И наоборот, есть ANSI Common Lisp, в котором нет никакого UB.

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

Это нужно только в msvc. Дефолтно он думает, что диапазоны перекрываются, гцц нет(если один из них не чар)

Ок, юб было бы меньше.

//все норм

А.. поспешил, не доглядел пример.. Сейчас подумаю.

пазор! не надо писать неоднозначные примеры. у вас cout - глобальный поток вывода, и не видно в каком состоянии и каком формате он находится. даже если он находится в десятичном, что неочевидно, то f() может поменять формат и выводить он вам будет не то, что вы ждете.

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

Вы так говорите, как будто это что-то хорошее) Будто это довод в пользу С++)

Поигрался с вашим примером.

Ну… Это конечно очень многоходовая комбинация по запутыванию компилятора. Там далеко не только если убрать «a: &i32» у very_bad перестаёт компилироваться..

Так заставить компилятор думать, что ссылка на локальную переменную живёт вечно, надо, конечно, уметь..

Исправят я думаю…

Исправят я думаю…

Этому примеру много лет.

Там же примеры как раз для гцц. Если два указателя на int, он считает их возможно перекрывающимися.

И даже наличие UB в виде (*p=*p) & (*q=*q) его не убеждает.

Это да. До появления стандарта считалось, что Си должен прямолинейно компилироваться в ассемблер. А вот потом появились оптимизирующие компиляторы, так как стандарт позволял делать с программой что угодно, до тех пор пока не менялся её результат.

В результате, сейчас компиляторы для Си и Си++ генерируют самый быстрый код.

Ну значит никому не надо. Был бы ещё код не подставной, можно было бы беспокоиться. Но ведь так случайно не напишешь…

Если убрать hClose h то все сработает нормально

Эффекты, эффекты помогут. С эффектами такое не скомпиляется (правда не уверен на 100% на счёт хаскеля, но вроде должно работать).

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

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

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

А тут даже простая конструкция .clone.as_str() не работает - новая ссылка умирает слишком рано, её надо сначала поместить в переменную, а потом уже делать что хочешь.

Одним словом – круть! Интересно какие впечатления будут дальше..

Всегда выбирайте JavaScript.

На D как-то слишком просто создавать копии чего угодно, выделение памяти происходит не заметно, чего быть как мне кажется не должно, потому что это дорогая операция.А тут даже простая конструкция .clone.as_str() не работает - новая ссылка умирает слишком рано, её надо сначала поместить в переменную, а потом уже делать что хочешь. Одним словом – круть! Интересно какие впечатления будут дальше..

начнёшь не к месту (например в магазине) вскрикивать про иммутабельность, доказывать потокобезопасность в ГАИ, сделаешь ещё более быстрый и универсальный пузырёк, поменяешь пол, полюбишь макдональдс..

мы тебя потеряем :-(

    - библиотека для загрузки/выгрузки изображений с поддержкой широкого круга форматов
    - биндинги для sdl2
    - работа с битовыми массивами размером больше чем 64 элемента (с поиском единиц)
    - перегрузка оператора индекса в том числе при присвоении
    - ассоциативные массивы с лаконичным доступом к элементам
    - документацией с поддержкой мобильного просмотра в 2023 году-то
    - поддержкой компиляции для мобильных архитектур
    - нормальный полиморфизм, а не как в Rust
    - востребованность на рынке труда

Так как про производительность ни слова, считаю питон идеальным выбором. Вписывается во все пункты

Пытаюсь выбрать язык программирования для личного проекта.

востребованность на рынке труда

Так тебе для личного или для комерческих целей?

Что я делаю не так здесь?

для начала хотя бы разбор аргументов командной строки

Есть же clap и десятки других.

считаю питон идеальным выбором

Тогда и Lua подходит.

А в питоне есть компиляция в нативный код?

Так тебе для личного или для комерческих целей?

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

У него пример разбит на два поста.

А, ну так не интересно, крайний случай, который никогда не встретишь в реале.

смотрел по диагонали, да, когда указатели на одинаковый тип, то restrict имеет место в ГЦЦ. А если условно f(int *, short *), то считает их неперекрывающимися в отличии от MSVC.

И даже наличие UB в виде (*p=*p) & (*q=*q) его не убеждает.

А где здесь UB? Не вижу, валидный код. Я даже посмотрел на асм тестов автора, все компили (шланг, ГЦЦ, ms) генерят одинаковый код с этим и без него. И вся суть этой статьи - компиляторы, поддерживайте, пожалуйста, вот этот костыль (*p=*p) & (*q=*q) вместо restrict.

И к чему этот пример? Я вам говорил о том, что в условно подобных конструкциях:

int i [10] = {};
short *s;
for (int j = 0;  j < 10;  ++j) {
    int val = i[j];
    s = &i[j];
    *s = 2;
    assert(val != i[j]);
}

Код будет работать ожидаемым образом не смотря на явное UB в стандарте.

А где здесь UB? Не вижу, валидный код.

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

примерно всё, вероятно для начала надо чужие посты научиться читать))

Есть же clap и десятки других.

Что-то даже в голову не пришло поискать библиотеку..

библиотеку

crate! :)

https://crates.io/keywords/cli - выбирай на вкус.

Нет и не планируется. Разрабы главного интепретатора питона даже JIT завозить не хотят

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

Но я уверен, что ты просто не понял как им пользоваться.

Так и было. Я читал книгу, дочитал до полиморфизма, ничего сходу не понял и закрыл на этом…

Я вам говорил о том, что в условно подобных конструкциях: … Код будет работать ожидаемым образом не смотря на явное UB в стандарте.

monk, оказывается не будет, ГЦЦ стал строже относиться к алиасингу, если в старых версих фокус проходил, то в новых нет. Да-да, я знаю что вы сейчас скажите. Я такие касты не делаю, только в char*, но мне всегда думалось, что такое должно прокатывать в наивном коде начинающих (раньше так и было).

Итак, сначала был «Электроника MK-52» (ох, в 1989 г., 115 рублей!), прекрасно себя чувствующий и сейчас. :)

Книги о программировании «МК» и статьи в журналах «Наука и жизнь», «Техника - молодёжи»…

СПТУ (оператор ЭВМ), практика на IBM-PC «с любой периферией».

Мультик на GW-BASIC, на тему пришельцев, с векторно-пиксельной графикой и звуками по нотам, для сдачи практики.

FoxPro/КАРАТ-М/Clipper/Clarion пропущу, различные неинтересные бухгалтерские программы в MS-DOS. :)

Turbo Pascal/Delphi - тоже ничего интересного, как продолжение бухгалтерской темы, но уже для Windows.

C++ - познакомился с Far Manager, захотелось улучшить. Пришлось изучать C++. Внесён в анналы истории Far. :)

D (когда dmd был написан ещё на C) - захотелось лучшего C++. Чего-то там контрибутил в Phobos, с самим Александреску в ревьюерах. Внесён в анналы истории Phobos. :)

Nim - захотелось лучшего D. :) Контрибутил и туда, и чуть не взяли на зарплату, но не сложилось, увы.

Zig - захотелось лучшего, чего-то нового. Но когда они «дооптимизировали» всё до того, что моих 8Gb стало не хватать для компиляции компилятора, мы распрощались.

C3 - захотелось лучшего C. Пока нравится, улучшаю, как могу.

Посматривал на Odin, но синтаксис отталкивает. Ещё жду, когда же Jai выйдет из вечной беты и будет доступен всем.

Ничего себе у вас богатая история!

А в питоне есть компиляция в нативный код?

Есть, но отдельными приблудами: cython, nuitka, pythran.

ГЦЦ стал строже относиться к алиасингу, если в старых версих фокус проходил, то в новых нет.

Вот эту мысль я и пытаюсь донести. Можно на Си(++) писать под конкретный компилятор, но тогда придётся фиксировать и аппаратную часть и ОС. К тому же, если компилятор не гарантирует какое-то конкретное поведение при UB, оно легко может начать проявляться от добавления кода в совсем другом месте программы.

И ради чего ходить по минам? Если производительность некритична и программа 99% времени ожидает реакции пользователя или получения данных, то лучше писать на языке, в котором семантика языка не ломается при любом коде.

Lua мне нравится больше, так что слежу за развитием Luau. Уже есть JIT и если они сделают создание выполняемых бинарников, то Lua вновь будет на коне. :)

Вы утрируете, лютых ЮБ можно пересчитать пальцами рук (может даже одной руки). К тому же из стандарта планомерно вычищается ЮБ.

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

Вообще надо просто писать нормально тесты, все ЮБ вылезет вместе с логическими ошибками.

Элементарные. Например, невозможность мутабельно борровить заведомо разные элементы одного и того же span’а.

Впрочем лучше читать ошибки БЧ, чем, начитавшись пропаганды, с удивлением натолкнуться на пример чуть выше.

Был бы ещё код не подставной

Вам все божья роса.

Когда monk пишет неподставной код с ручной индексацией массива – это ок, проблемы С++. Когда БЧ пропускает элементарные ошибки, при этом не пропускает настолько же элементарно проверяемый валидный код – это конечно же починят, да и код подставный оказался.

Вам все божья роса.

Вам – это объединение всех участников дискуссии? Я про C++ ничего не говорил. По мне так пример с бесконечным пустым циклом тоже надуманный. Зачем такое запускать, а тем более в релиз выпускать?

По мне так пример с бесконечным пустым циклом тоже надуманный. Зачем такое запускать, а тем более в релиз выпускать?

Я сейчас припоминаю, я такое даже юзал на МК. Наверное пустой цикл в мейне и обработчик прерываний на входах. Зря шланг так, да и в стандарте бы прописать поведение не мешало бы.

UB – это не отсутствие стандарта, а разрешение стандартом (или описанием языка) произвольного поведения в каких-то случаях.

такая формулировка это треш. навроде - «не трогайте меня, я психический».

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

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

При том, что код с UB может работать, а потом переставать это делать очень внезапно

А просто не допускать UB в своём коде не вариант? Личная аккуратность, понимание, что ты пишешь, ну и статические анализаторы в помощь, это не зазорно.

P.S. Прочитал твой ответ на второй странице. Не то, чтобы ты меня убедил, но приму к сведению.

Выбирай, который тебе по душе.

Так всегда было, и так будет (с)

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

можно делать так

  volatile int x = 1;
  while (x) ;

А в целом это позволяет выкидывать вычисления, результаты которых не используются, не проверяя, что эти вычисления закончатся.

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

Если потребовать неразрушающее поведение для записи по указателю, полученному из адресной арифметики, то это потребует проверки на доступность памяти, которая на несколько порядков дольше, чем сама запись (а ещё дополнительную память для хранения данных о доступности).

как можно в случае бесконечного цикла запустить недостижимый код?

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

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

Может. Но потеряет в скорости работы. А Си++ нужен только ради скорости.

Вообще надо просто писать нормально тесты, все ЮБ вылезет вместе с логическими ошибками.

Не всегда. Тесты всегда проверяют функциональность локально. А если ЮБ портит данные в произвольном месте, то тестами его не отловить.

Если потребовать неразрушающее поведение для записи по указателю, полученному из адресной арифметики, то это потребует проверки на доступность памяти, которая на несколько порядков дольше, чем сама запись (а ещё дополнительную память для хранения данных о доступности).

Всё это делают санитары.

Таков стандарт.

Не стандарт, а его интерпретация шланг боями. Вот как с питоном 2 быть? Получается, что он был сплошным юб раз его сломали?

Может. Но потеряет в скорости работы.

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

Си++ нужен только ради скорости.

Не только.

Не всегда. Тесты всегда проверяют функциональность локально. А если ЮБ портит данные в произвольном месте, то тестами его не отловить.

Если юб портит в произвольно месте, то это увидят санитары.

можно делать так

Я лучше помашу ручкой шлангу, если там не исправят это, значит там ребята с приветом.