libstdc++ от gcc 5.4.0 весит 1.5Mb, Qt5Core от Qt 5.8.0 весит 5.2Mb. Разница, конечно, в 3.5 раза, но назвать ее критической едва ли возможно. Особенно с учетом возможностей, которые Qt предоставляет. Многие embedded решения отказываются от libstdc++ в пользу Qt.
Использование своих велосипедов для работы с сетью вызывает улыбку. Либо у вас сеть только номинально, либо вы очень серьезные сетевики с крутым опытом, либо делаете что-то не то. Сеть в серьезном приложении очень часто является самым узким местом, и изобретать тут велосипеды вместо использования проверенных либ типа boost.asio — фундаментальная ошибка в архитектуре ПО.
с файловой системой у нас свои несложные классы-обёртки
Готов найти не менее трех проблем в ваших несложных обертках.
В итоге, у нас минимум зависимостей от сторонних библиотек
А в чем, собственно, профиты, кроме того, что можно написать «у нас минимум зависимостей от сторонних библиотек»? Какие-то проблемы написать «sudo apt install ...»?
Сейчас хорошо, но я все-таки предлагаю довести до отлично :)
Дело в том, что в коде сборки вы переопределяете CMAKE_INSTALL_PREFIX на папку в директории с сорцами sdk. Если ее оставить пустой, то по умолчанию на никсах она определена как /usr/local. Вам остается просто написать, что инсталлировать хедеры нужно в include/easy_profiler, либки в lib/, исполняемые файлы в bin/, файлы со скриптами можно кинуть в share/. А фишка в том, что cmake по умолчанию ищет свои конфигурационные файлы в /usr/local/lib/cmake. Это значит, что если вы просто на никсах будете устанавливать все в папки по умолчанию, то прям из коробки можно будет писать
cmake…
make
sudo make install
и дальше в коде, без CMAKE_PREFIX_PATH, сразу писать
find_package(easy_profiler).
На винде, увы, это не прокатит, потому что там нет логики рассовывания библиотек по системе, поэтому CMAKE_PREFIX_PATH писать придется.
Далее, есть еще такое предложение. Везде в коде вы пишите add_definitions и include_directories. На самом деле, это штука устаревшая, и работает локально. Намного удобнее использовать target_compile_definitions и target_include_directories, которым можно указывать дополнительно PUBLIC, PRIVATE, INTERFACE в зависимости от того, нужно ли экспортировать эти директивы и хедеры в проекты, которые подключают ваш проект. В итоге, если вы определите target_compile_definitions(easy_profiler PUBLIC BUILD_WITH_EASY_PROFILER), то все проекты, которые будут указывать в target_link_libraries вашу библиотеку, автоматически подключает все определения с модификатором PUBLIC. Тоже самое касается и хедеров, если проделать аналогичное с target_include_directories.
О чем хочется сразу сказать — поправьте нормально файлы сборки. Дело в том, что, во-первых, при указании cmake папки сборки, финальные исполняемые файлы все равно зачем-то копируются в каталог сорцов. Портить папку с сорцами, особенно когда я указал этого не делать — плохой тон.
Во-вторых, хочется все это проинсталлировать в систему (Linux), а не собирать все это в отдельную папку, потом прописать пути и т.д. Инсталляции пока нет.
В-третьих, раз уж используется cmake, хочется в своем проекте просто написать find_package(easy_profiler) и получить сразу пути к хедерам и библиотекам, а также все необходимые дефайны. А чтобы руками не писать модуль FindEasyProfiler.cmake, рекомендую почитать про package layout cmake. То есть это позволит проинсталлировать в систему вашу библиотеку сразу с автоматически сгенерированным конфигом cmake со всеми правильными путями, клиенту нужно будет написать в своем коде только find_package(easy_profiler).
Есть еще вопросы конкретно по использованию, но я их в личку напишу.
Есть еще один супер-супер важный момент — нет никакого желания со всеми этими людьми ехать в одном пространстве. Я еще к этому более-менее спокоен, но львиная доля моих друзей говорит, что лучше пешком, на велосипеде в мороз, каршеринге или такси, чем спускаться лишний раз в метро. И причин тут навалом: вонь, ходьба по ногам, воровство, порча вещей (сумки, куртки), угрюмые лица вокруг, священные войны на тему «не уступил место», давка и т.д. и т.п. Да, если нужно гарантированно приехать к определенному времени, лучше выбрать метро, но если никуда не спешишь — можно и в пробки постоять, песни попеть, книги почитать.
На самом деле, от лихачества и прочего избавиться почти невозможно, потому что всегда будет кто-то опаздывающий. Даже штрафы могут быть не таким серьезными стимулом (ну, ты можешь опаздывать на самолет, либо ты катаешься на бентли и тебе по барабану все эти штрафы).
Мало того, как бы грустно это не звучало, но кроме как максимализации цены использования авто в городе, проблему почти никак не решить. Да, в Москве просто по-идиотски настроены светофоры, и вполне могут гореть зеленым пустой дороге 3 минуты, а на дороге с пробкой выделяться 15 секунд. Но если это проблему исправить (а я все-таки надеюсь, что ее исправят), то просто авто пользоваться станет чуть выгоднее, что увеличит количество машин, что увеличит пробки. Авто сейчас купить не проблема, если прям очень надо — есть тазы по 15-20 тысяч рублей, доступно почти всем.
В итоге действенные меры — дорогие парковки (на некоторое время они и правда неплохо разгрузили центр), платный въезд в центр, дорогие полисы страхования (можно было бы сделать, скажем так, зоны страхования) и прочее. При этом можно увеличивать количество каршеринг авто, уменьшая оплату за них. Можно делать сильные льготы мотоциклистам, можно сделать велосипедный транспорт самым главным на дороге (как это сделано, скажем, в Амстердаме).
Многого из этого не хочется видеть на наших дорогах, но, имхо, только это может привести к снижению потока авто.
Меня, честно говоря, уже начал утомлять этот тред. Я не понимаю, как ты не понимаешь!
Есть большой проект, который состоит из большого количества библиотек. Скажем, ModuleA, ModuleB, ModuleC и т.д.ModuleA, например — купленный за лям баксов проект у сторонней организации, и допиленный нами до нужного функционала. Лежит в отдельном репе. ModuleB — наша математическая модель, которую пишет всего пара человек, разбирающиеся в вопросе. Он также закрыт от большинства.
ModuleC — какой-нибудь удобный враппер над какой-нибудь библиотекой, нам все равно, кто его пишет, главное — чтобы хорошо работал.
Каждый отдельный модуль является самодостаточным. Его можно скачать, собрать, прогнать юнит-тесты и прочее.
Большой прожект состоит из этих мелких проектов, которые вливаются в него с помощью subtree. Он собирается на билд-сервере, дальше уже прогоняются юнит-тесты и прочие тесты всего проекта. Дальше q&a берут с сервера deb пакет, ставятся себе и уже тыкают в него на поиск багов, которые спрогнозировать сложно.
Данный воркфлоу вполне себе пашет уже долгое время, свои задачи он решает, все довольны.
А «Выделять 2 файла из модуля и давать кому-то на разработку» — это к чему было?
Это было к предыдущего сообщению:
Почему вы думаете, что иметь один репозиторий, давая доступ к его части лучше, чем иметь 2 репозитория?
Ну нужно пояснить, что у нас происходит.
У нас большой C++, состоящий из большого количества модулей (компилируются в итоге в статические/динамические библиотеки). Ясное дело, каждый модуль мы можем выделить в отдельный репозиторий, и дать к нему полный доступ. Юзер может писать там код, добавлять тесты и т.д.
Финальный проект собирает такие модули в один проект, и компилируется в готовый продукт. Дальше уже готовый продукт тестируется на наличие разных ошибок и багов.
Первые 5 команд — это фундамент всего git. В конце-концов, даже при общении с коллегами приходится говорить «ты запушил изменения?», «ща сделаю коммит и...», «смерж ветки» и прочее. Можно и в gui все делать, ок, ну надо понимать, что происходит. И, как я уже говорил, с этой задачей и бабушки справляются.
Использование своих велосипедов для работы с сетью вызывает улыбку. Либо у вас сеть только номинально, либо вы очень серьезные сетевики с крутым опытом, либо делаете что-то не то. Сеть в серьезном приложении очень часто является самым узким местом, и изобретать тут велосипеды вместо использования проверенных либ типа boost.asio — фундаментальная ошибка в архитектуре ПО.
Готов найти не менее трех проблем в ваших несложных обертках.
А в чем, собственно, профиты, кроме того, что можно написать «у нас минимум зависимостей от сторонних библиотек»? Какие-то проблемы написать «sudo apt install ...»?
Спрашиваю любопытства ради, а не для холиваров: зачем собирать кластеры на Windows?
Дело в том, что в коде сборки вы переопределяете CMAKE_INSTALL_PREFIX на папку в директории с сорцами sdk. Если ее оставить пустой, то по умолчанию на никсах она определена как /usr/local. Вам остается просто написать, что инсталлировать хедеры нужно в include/easy_profiler, либки в lib/, исполняемые файлы в bin/, файлы со скриптами можно кинуть в share/. А фишка в том, что cmake по умолчанию ищет свои конфигурационные файлы в /usr/local/lib/cmake. Это значит, что если вы просто на никсах будете устанавливать все в папки по умолчанию, то прям из коробки можно будет писать
cmake…
make
sudo make install
и дальше в коде, без CMAKE_PREFIX_PATH, сразу писать
find_package(easy_profiler).
На винде, увы, это не прокатит, потому что там нет логики рассовывания библиотек по системе, поэтому CMAKE_PREFIX_PATH писать придется.
Далее, есть еще такое предложение. Везде в коде вы пишите add_definitions и include_directories. На самом деле, это штука устаревшая, и работает локально. Намного удобнее использовать target_compile_definitions и target_include_directories, которым можно указывать дополнительно PUBLIC, PRIVATE, INTERFACE в зависимости от того, нужно ли экспортировать эти директивы и хедеры в проекты, которые подключают ваш проект. В итоге, если вы определите target_compile_definitions(easy_profiler PUBLIC BUILD_WITH_EASY_PROFILER), то все проекты, которые будут указывать в target_link_libraries вашу библиотеку, автоматически подключает все определения с модификатором PUBLIC. Тоже самое касается и хедеров, если проделать аналогичное с target_include_directories.
Во-вторых, хочется все это проинсталлировать в систему (Linux), а не собирать все это в отдельную папку, потом прописать пути и т.д. Инсталляции пока нет.
В-третьих, раз уж используется cmake, хочется в своем проекте просто написать find_package(easy_profiler) и получить сразу пути к хедерам и библиотекам, а также все необходимые дефайны. А чтобы руками не писать модуль FindEasyProfiler.cmake, рекомендую почитать про package layout cmake. То есть это позволит проинсталлировать в систему вашу библиотеку сразу с автоматически сгенерированным конфигом cmake со всеми правильными путями, клиенту нужно будет написать в своем коде только find_package(easy_profiler).
Есть еще вопросы конкретно по использованию, но я их в личку напишу.
Мало того, как бы грустно это не звучало, но кроме как максимализации цены использования авто в городе, проблему почти никак не решить. Да, в Москве просто по-идиотски настроены светофоры, и вполне могут гореть зеленым пустой дороге 3 минуты, а на дороге с пробкой выделяться 15 секунд. Но если это проблему исправить (а я все-таки надеюсь, что ее исправят), то просто авто пользоваться станет чуть выгоднее, что увеличит количество машин, что увеличит пробки. Авто сейчас купить не проблема, если прям очень надо — есть тазы по 15-20 тысяч рублей, доступно почти всем.
В итоге действенные меры — дорогие парковки (на некоторое время они и правда неплохо разгрузили центр), платный въезд в центр, дорогие полисы страхования (можно было бы сделать, скажем так, зоны страхования) и прочее. При этом можно увеличивать количество каршеринг авто, уменьшая оплату за них. Можно делать сильные льготы мотоциклистам, можно сделать велосипедный транспорт самым главным на дороге (как это сделано, скажем, в Амстердаме).
Многого из этого не хочется видеть на наших дорогах, но, имхо, только это может привести к снижению потока авто.
Есть большой проект, который состоит из большого количества библиотек. Скажем, ModuleA, ModuleB, ModuleC и т.д.ModuleA, например — купленный за лям баксов проект у сторонней организации, и допиленный нами до нужного функционала. Лежит в отдельном репе. ModuleB — наша математическая модель, которую пишет всего пара человек, разбирающиеся в вопросе. Он также закрыт от большинства.
ModuleC — какой-нибудь удобный враппер над какой-нибудь библиотекой, нам все равно, кто его пишет, главное — чтобы хорошо работал.
Каждый отдельный модуль является самодостаточным. Его можно скачать, собрать, прогнать юнит-тесты и прочее.
Большой прожект состоит из этих мелких проектов, которые вливаются в него с помощью subtree. Он собирается на билд-сервере, дальше уже прогоняются юнит-тесты и прочие тесты всего проекта. Дальше q&a берут с сервера deb пакет, ставятся себе и уже тыкают в него на поиск багов, которые спрогнозировать сложно.
Данный воркфлоу вполне себе пашет уже долгое время, свои задачи он решает, все довольны.
Это было к предыдущего сообщению:
У нас большой C++, состоящий из большого количества модулей (компилируются в итоге в статические/динамические библиотеки). Ясное дело, каждый модуль мы можем выделить в отдельный репозиторий, и дать к нему полный доступ. Юзер может писать там код, добавлять тесты и т.д.
Финальный проект собирает такие модули в один проект, и компилируется в готовый продукт. Дальше уже готовый продукт тестируется на наличие разных ошибок и багов.
git flow можем посчитать за одну команду.
Ну ок, еще сюда можно вписать add, rebase, diff, log, хотя этого можно и не знать, используя какое-либо gui.