| |
| 2.6, Аноним (6), 00:19, 13/03/2020 [^] [^^] [^^^] [ответить]
| –5 +/– | |
> Корутины гоните
А что, в gccgo разве нету? Или на си хотелось? Ну тогда lwan.ws посмотри, как раз сразу и повебмакачить можно, даже с вебсокетами чего доброго.
| | |
| 2.9, муу (?), 03:06, 13/03/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
для крестов гонят, в 10 будет
в стабильные ветки новые фишки нормальные люди не завозят, ваш кэп
| | |
| |
| 3.29, vitalif (ok), 12:18, 13/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > для крестов гонят, в 10 будет
ага, вот я их и жду. потестить охота :)
| | |
|
|
| |
| |
| 3.13, Аноним (13), 09:55, 13/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Он видимо хочет формально верифицированный компилятор без багов. Если так, то ответ "никогда", во всяком случае до тех пор, пока разработкой ПО не начнёт заниматься полноценный ИИ.
| | |
| |
| |
| 5.25, Аноним (13), 10:50, 13/03/2020 [^] [^^] [^^^] [ответить]
| +6 +/– |
Пусть сам себя верифицирует. Это ему понадобится, чтобы избавиться от комплекса неполноценности.
| | |
| |
| 6.34, Аноним (34), 17:04, 13/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Пусть сам себя верифицирует.
Он успешно верифицирует себя по ошибке, потому что в нём будут ошибки.
| | |
|
|
| 4.48, Xasd5 (?), 22:02, 15/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> пока разработкой ПО не начнёт заниматься полноценный ИИ
в этом случае багодром невиданного маштаба -- обеспечен!
| | |
|
|
|
| 1.14, ДмитрийСССР (?), 09:57, 13/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Товарищи! Подскажите пожалуйста, начал изучать С++, и интересует такой вопрос, вот допустим я использую компилятор GCC 9.3 (он новый же), и хочу чтобы моя конечная программа запустилась на старой ОС (будь то Linux 6-ти летней давности, или будь то Windows XP, не суть), можно ли такое провернуть? Или новые компиляторы позволяют писать только под относительно новые ОС?
И второй вопрос по поводу стандартов, если пишешь программу под старую ОС, надо ли использовать более старый стандарт (С++11 или С++03), или всё же можно новый?
Спасибо!
| | |
| |
| |
| 3.28, Michael Shigorin (ok), 11:09, 13/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.
Хозяйке на заметку: вот этот матюкливый организм сейчас со своей логореей набегал в соседнюю тему про альтовые стартеркиты.
| | |
| 3.39, Аноним (-), 20:17, 13/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.
Лучше не начинать. Си там вообще никакой, даже C99 нет. Да и плюсы не намного лучше.
| | |
| |
| 4.41, Аноним84701 (ok), 22:22, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
 >> Начинай с Visual C++ 6. Я с неё начинал и ничего, живой.
> Лучше не начинать. Си там вообще никакой, даже C99 нет. Да и плюсы не намного лучше.
Да ладно пугать байками - из этой версии выковыривали ML.EXE (Macro Assemler), RC.EXE (Resource Compiler), LINK.EXE для MASM32. И можно было использовать тамошний графический редактор гуя (генерирующий RC файлы), так что вполне годный продукт был.
| | |
|
|
| 2.31, Аноним (13), 13:03, 13/03/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Пользователей доисторических ОС (в случае виндоус это всё старее 8, по линуксу можно ориентироваться на убунту 4 летней давности) на сегодня 0.0000000001% от общего числа, нагружать себя разработкой и тестированием под старые ОС (у которых не будет половины функций и нужно городить костыли) нецелесообразно. Особенно нецелесообразно для нативных программ, у которых нет готового совместимого окружения, которое можно выбрать таргетом.
| | |
| |
| 3.42, mommy (?), 23:10, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ууууух посмешил, расскажи это нашим инженерам которые деплоят уж 3 год центуось 6.9 и 7.3, и еще будут депломть лет 10
| | |
| |
| 4.43, Аноним (13), 23:24, 13/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если софт сам-в-себе, то ещё можно попробовать, а так вряд ли. Если это не узкоспециализированный промышленный софт, смысла оглядываться на легаси нет совершенно никакого.
| | |
|
|
| 2.33, Аноним (33), 17:00, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> И второй вопрос по поводу стандартов, если пишешь программу под старую ОС, надо ли использовать более старый стандарт (С++11 или С++03), или всё же можно новый?
Посмотри какой версии там компилятор и выбирай стандарт максимальной версии, которую тот поддреживает.
| | |
| 2.47, Анонимиус (??), 20:00, 14/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Бинарник с большой вероятностью не запустится под старой осью, так как собирая приложение под другой осью вы прилинкуете ее динамические библиотеки в зависимостях + не помню уже, стандартная библиотека glibc распространяется в виде .so или нет? stdc++ по больше части на шаблоннах, поэтому наверное все статиком в бинарник войдет, а с glibc могут быть проблемы
| | |
|
| 1.16, Аноним (13), 10:20, 13/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
Что-то у меня не компилируется:
>note: 'LONG_MIN' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'? | | |
| |
| |
| 3.23, Аноним (13), 10:45, 13/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Тебе же компилятор все написал.
Ну и что мне с этим делать? У меня же 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': | | |
| |
| 4.32, Аноним (13), 14:54, 13/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Самое забавное, что dev-qt/qtwayland-5.14.1 без r1 успешно собрался 2 недели назад. Спасибо хоть добавили ревизию, а не запороли ебилд (как это обычно делают). Я склоняюсь к сборке из 9999, но мне слишком лень тратить время на эксперименты.
Вообще, неплохо бы пересобираемые автоматически (по зависимостям) пакеты пересобирать из ебилда установленного пакета, а не ебилда версии из дерева. Это бы избавило от возникающих из ниоткуда ошибок при пересборке.
| | |
|
| 3.26, Аноним (13), 10:56, 13/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, я почитал логи ещё. В общем, проблема была не там, с _FORTIFY_SOURCE=2 не собирается. А почему? Видимо потому что glibc отказался собираться с _FORTIFY_SOURCE и был собран без него.
| | |
|
|
| |
| 2.40, Аноним (-), 20:19, 13/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так же как любая другая программа соответствующего размера. То-есть да, в полнолуние нечетного месяца четного четверга високосного года, если вы подберете хитрое сочетание опций - вам таки прилетит. И вот так прилетело стольким-то неудачникам. Однако чтобы оказаться в числе этих чудаков, вам придется откаблучить что-то относительно нестандартное.
| | |
|
| 1.49, iZEN (ok), 12:41, 17/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Вот бы ещё научился FreeBSD 12-STABLE компилировать. И тогда можно было бы выкинуть системный LLVM. В предыдущих версиях как-то удавалось, а сейчас затык на интегрированной в libc iconv.
| | |
|
