Доступен корректирующий релиз набора компиляторов GCC 9.3, в котором проведена работа по исправлению ошибок, регрессивных изменений и проблем с совместимостью. По сравнению с версией GCC 9.2 в GCC 9.3 отмечено 157 исправлений, в основном связанных с устранением регрессивных изменений.Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52533
Корутины гоните
> Корутины гонитеА что, в gccgo разве нету? Или на си хотелось? Ну тогда lwan.ws посмотри, как раз сразу и повебмакачить можно, даже с вебсокетами чего доброго.
для крестов гонят, в 10 будет
в стабильные ветки новые фишки нормальные люди не завозят, ваш кэп
> для крестов гонят, в 10 будетага, вот я их и жду. потестить охота :)
gcc к нормальным не относится.
Нет - ты.
Корутины гоните вон!P.S.
Дописывать надо.
Ну есть же термин сопрограммы, зачем эта калька?
Может потому, что это немного отличающееся понятие?
Чем конкретно?
Я так понимаю, безопасный код они пока не реализуют?
Пиши безопасно и будет тебе безопасный код.
Он видимо хочет формально верифицированный компилятор без багов. Если так, то ответ "никогда", во всяком случае до тех пор, пока разработкой ПО не начнёт заниматься полноценный ИИ.
А кто будет верифицировать "полноценный ИИ"?
Пусть сам себя верифицирует. Это ему понадобится, чтобы избавиться от комплекса неполноценности.
> Пусть сам себя верифицирует.Он успешно верифицирует себя по ошибке, потому что в нём будут ошибки.
> пока разработкой ПО не начнёт заниматься полноценный ИИв этом случае багодром невиданного маштаба -- обеспечен!
Товарищи! Подскажите пожалуйста, начал изучать С++, и интересует такой вопрос, вот допустим я использую компилятор GCC 9.3 (он новый же), и хочу чтобы моя конечная программа запустилась на старой ОС (будь то Linux 6-ти летней давности, или будь то Windows XP, не суть), можно ли такое провернуть? Или новые компиляторы позволяют писать только под относительно новые ОС?И второй вопрос по поводу стандартов, если пишешь программу под старую ОС, надо ли использовать более старый стандарт (С++11 или С++03), или всё же можно новый?
Спасибо!
Да. Нет. Нет (да, можно новый).
Я тоже.
Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.
> Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.Хозяйке на заметку: вот этот матюкливый организм сейчас со своей логореей набегал в соседнюю тему про альтовые стартеркиты.
Михаил, может хватит изгаляться?
> Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.Лучше не начинать. Си там вообще никакой, даже C99 нет. Да и плюсы не намного лучше.
>> Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.
> Лучше не начинать. Си там вообще никакой, даже C99 нет. Да и плюсы не намного лучше.Да ладно пугать байками - из этой версии выковыривали ML.EXE (Macro Assemler), RC.EXE (Resource Compiler), LINK.EXE для MASM32. И можно было использовать тамошний графический редактор гуя (генерирующий RC файлы), так что вполне годный продукт был.
Пользователей доисторических ОС (в случае виндоус это всё старее 8, по линуксу можно ориентироваться на убунту 4 летней давности) на сегодня 0.0000000001% от общего числа, нагружать себя разработкой и тестированием под старые ОС (у которых не будет половины функций и нужно городить костыли) нецелесообразно. Особенно нецелесообразно для нативных программ, у которых нет готового совместимого окружения, которое можно выбрать таргетом.
Ууууух посмешил, расскажи это нашим инженерам которые деплоят уж 3 год центуось 6.9 и 7.3, и еще будут депломть лет 10
Если софт сам-в-себе, то ещё можно попробовать, а так вряд ли. Если это не узкоспециализированный промышленный софт, смысла оглядываться на легаси нет совершенно никакого.
> И второй вопрос по поводу стандартов, если пишешь программу под старую ОС, надо ли использовать более старый стандарт (С++11 или С++03), или всё же можно новый?Посмотри какой версии там компилятор и выбирай стандарт максимальной версии, которую тот поддреживает.
Бинарник с большой вероятностью не запустится под старой осью, так как собирая приложение под другой осью вы прилинкуете ее динамические библиотеки в зависимостях + не помню уже, стандартная библиотека glibc распространяется в виде .so или нет? stdc++ по больше части на шаблоннах, поэтому наверное все статиком в бинарник войдет, а с glibc могут быть проблемы
Что-то у меня не компилируется:>note: 'LONG_MIN' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
Тебе же компилятор все написал.
> Тебе же компилятор все написал.Ну и что мне с этим делать? У меня же qtwayland не может найти файл /usr/include/qt5/QtXkbCommonSupport/5.14.1/QtXkbCommonSupport/private/qxkbcommon_p.h и когда я его добавляю в инклюды он не может слинковаться из-за зависимостей. Когда я линкую его с зависимостями, он не может найти свои статические зависимости. Ну и почему я должен править исходники?
Пс. ошибку выдаёт на
>checking whether x86_64-pc-linux-gnu-gcc supports -Wwrite-strings... /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libiberty/fibheap.c: In function 'fibheap_replace_key_data':
Самое забавное, что dev-qt/qtwayland-5.14.1 без r1 успешно собрался 2 недели назад. Спасибо хоть добавили ревизию, а не запороли ебилд (как это обычно делают). Я склоняюсь к сборке из 9999, но мне слишком лень тратить время на эксперименты.Вообще, неплохо бы пересобираемые автоматически (по зависимостям) пакеты пересобирать из ебилда установленного пакета, а не ебилда версии из дерева. Это бы избавило от возникающих из ниоткуда ошибок при пересборке.
Да, я почитал логи ещё. В общем, проблема была не там, с _FORTIFY_SOURCE=2 не собирается. А почему? Видимо потому что glibc отказался собираться с _FORTIFY_SOURCE и был собран без него.
А как оно вообще работало с таким количеством регрессий?
Так же как любая другая программа соответствующего размера. То-есть да, в полнолуние нечетного месяца четного четверга високосного года, если вы подберете хитрое сочетание опций - вам таки прилетит. И вот так прилетело стольким-то неудачникам. Однако чтобы оказаться в числе этих чудаков, вам придется откаблучить что-то относительно нестандартное.
Вот бы ещё научился FreeBSD 12-STABLE компилировать. И тогда можно было бы выкинуть системный LLVM. В предыдущих версиях как-то удавалось, а сейчас затык на интегрированной в libc iconv.