Comments 26
Nix кстати не такой уж и сложный. И работает как на Linux так и на Macos. Но вот если нужен Windows, тогда да, тогда больно.
Но вот git submodule это всегда больно.
А почему не освещены всякие дорогие статические анализаторы типа Fortify, SonarQube, Checkmarx, которые любят в больших корпорация?
Ну и кстати...
Разработка ПО должна быть устойчивым и самоподдерживающимся процессом
Нет, он поддерживается деньгами покупателей продукта, инвесторов или бюджетом самой фирмы)
из вашей компании ушёл сотрудник
судя по списку того как это работало под управлением этого безвременно ушедшего сотрудника:
...на сборку кода на его машине уходило три месяца...
...вылет приложения 253 раза...
Для устранения нескольких последних срочных багов потребовался труд множества людей и две недели для деплоя в продакшен......
сотрудника расстреляли, в связи с этим вопрос: что же так поздно расстреляли то? Вот о чем надо было в первую очередь рассказать!
Простите, не сдержался
По поводу vcpkg. При желании можно практически все third party на него перевести. Но стоит сразу следить за версиями зависимостей - лучше зафиксировать их (а в идеале - форкнуть) и прописать процесс обновления версий. Как раз для того чтобы избежать внезапных сюрпризов.
Забыто импортозамещение... там есть и big-endian, SPARC, VLIW , местами ограничение 98м стандартом, с другой стороны куча платформ для которых единственный компилятор - не-релиз версия шланга, криво поддерживающая Си++-20
Есть ли у нас вообще платформы big-endian? (Скорее всего, ответ будет
таким: нет, никогда не было и не будет; однако если они всё-таки есть,
то напишите мне письмо с подробностями, это звучит любопытно).
Процессор Power8 может работать в обоих режимах, в зависимости от версии ОС, мы писали с расчётом на little-endian, потому что big-endian, скорее всего, нет, никогда не было и не будет, как сказал эффективный менеджер. В один момент прибегает он же и говорит, что у нас коммерческой лицензии на little-endian RHEL, оказывается, нет, никогда не было и не будет, а есть только для big-endian - всё переустановить и переделать! Сносим с кластера little-endian RHEL, ставим вместо него big-endian RHEL, пересобираем библиотеки - некоторые под big-endian не собираются, а некоторые вроде и собираются, но глючат, потому что авторы, видимо, тоже решили, что big-endian, скорее всего, нет, никогда не было и не будет - это при том, что библиотеки про высокопроизводительную высокопроизводительность, с которой авторы заморочились конкретно под этот Power8: AltiVec, биты в кэшах аккуратно лежат, вот это вот всё - собственно, поэтому оно и не работает для big-endian. Чё-то как-то разрулили, начали своё добро переделывать - хорошо, хоть много написать не успели.
Читал как художественное произведение и наслаждался таким "булгаковским" слогом, хоть и перевод. Вкусно.
Имел в своей практике проект с 20-летней историей и чудовищными практиками кодирования внутри - никаких умных указателей, наследование ни к месту, ассемблерные вставки, и прочие радости. Проект был весьма объёмным, но так получилось, что большая часть функционала была уже давно неактуальна. В результате было принято решение написать новый продукт с нуля, который бы включал только актуальный функционал (что сегодня продаётся).
Думаю, такой подход имеет право на существование, как минимум в некоторых случаях.
Ужас-то какой , что дальше будет?!
Довелось как-то править один проект от 1996-го (последний апдейт был) года в 2016-м, 1500+ Си-шных файлов. Система монитторинга и сбора статистики одно из штатовских ОПСОС. Всё под OpenVMS/Alpha и VAX , разумеется.
Разобрался без всяких IDE-ёв и прочей новомодной шняги, и не потому что крут\гений (этим не наделён точно), а потому что всё было сделано по канонам DEC-овской инженерной школы: и форматирование по вайтсмиту и комменты - где надо быть комментам, и всё описано внутри кода как надо. И файлы разложены не триста файлов по 300 каталогам и именованы были без камел-кейса. И рутины с $ в именах, и константы аж большими буквами (ну вы понели).
Как я понимаю , если соблюдать оперделённые каконы - то "старая база на С++" не будет восприниматься как анекдот. :-)
а вот объясните в чем преимущество, когда все файлы лежат в одной директории(может даже в корне), перед разложенным по папкам в соответствии с ахитектурой?
Я последнее время замечаю много по, у которого все файлы лежат в корне. Обычно написано на Си. И само по вроде качественное, но я не пойму в чем преимущество этого, видимо художественного, беспорядка
Не занимался крупными проектами, но предположу что из-за корявой системы компиляции в которой не может быть два одинаковых .с/.срр файла, где бы они не находились. Потому можно смело спихивать всё в одну папку и не морочить голову что где-то не так названо.
ЗЫ фича актуальна досихпор, модули С++ не собираются с одинаковыми именами на msvc. Приходится принимать соглашения, аля - имя= полное имя модуля[партишн]
с именем модуля все ясно - оно ведь не отражает иерархии директорий, поэтому так и нельзя.
А вот с файлами непонятно. Ну думаю что bash+make не справляются с такой проблемой. Скорее это просто унаследованные практики
оно ведь не отражает иерархии директорий, поэтому так и нельзя
Нет, я имею ввиду имя файла. Я ожидал что модули будут собираться как отдельные подпрограммы с торчащими наружу символами, но нет, там все те же проблемы. Объявил партишны с одинаковыми именами в разных модулях и решил назвать файл именем партишна, лови ошибку.
module Foo : test; //file://src/foo/test.ixx
module Bar : test; //file://src/bar/test.ixx
//В итоге будет ошибка компиляции из-за одинаковых имён test.ixx
//Тоесть модули собираются не модульно б***ь"Беспорядка" ? ;-)
Как я понимаю всё зависит от контекста и устойчивых навыков, если пограмилла сидит в VT 220 - то у него и нет среды что бы скакать по сырцам, а надо выйти из редактора в ком. строку, сделать "cd" (или там ещё что-то), затем скормить редактору нужный файл. Ещё можно притянуть что де некоторе время назад было ограничение на кол-во подкаталогов и их тоже приходилось экономить. ;-)
"Fedora и Ubuntu годами обсуждали, нужно ли собирать пакеты с включённым указателем фреймов"
А про что речь? Про gcc option -fomit-frame-pointer? Чтение оригинала статьи ответа тоже не дало. Кто-нибудь сталкивался с этим? И что же все таки решили эти Ubuntu да Fedora?
Оригинал:
"Fedora and Ubuntu have debated for years whether to build packaged with the frame pointer enabled"
Да, именно про это. Решили в конце концов включить. В Ubuntu 24.04 пакеты (большинство) будут идти без этой опции.
https://www.phoronix.com/news/Ubuntu-Frame-Pointers-Default https://www.phoronix.com/news/F38-fno-omit-frame-pointer
У вас был cmake..... да вы счатливец)))
А я тону в баш скриптах и это не самое ужасное. Тут еще и bat скрипты....
Старые добрые подмодули (submodule) git и компиляцию из исходников. Да, это трудоёмко, но в то же время:
Ужасно просто
Разработчики сразу во всём разбираются, даже не имея опыта работы с C++
Не ужасно просто, а просто ужасно. Кому-то надо cmake, кому-то надо autoconf, кому-то надо make с параметрами, кому-то надо perl (привет, openssl), кому-то надо 100500 3rd party зависимостей, которым самим тоже много чего надо (привет, ffmpeg). Да еще надо заставить их использовать наши версии библиотек, а не встроенные (лучи любви в zlib и openssl, которые используют чуть более, чем все, и которые так и норовят прилинковаться из системных данных).
Conan/vcpkg решают большую часть проблем за нас - умные люди уже понаступали на все гвозди.
Итак, вы унаследовали старую кодовую базу на C++. Что дальше?