Читаю-читаю про употребление колючек conan'а, думаю ну вот сейчас автор наконец напишет "а давайте теперь попробуем vcpkg" но вот что-то не написал и продолжил употреблять колючки и делать какие-то выводы :(
Если в наличии есть C++20, то подход из статьи https://dfrib.github.io/a-foliage-of-folly/ мне кажется проще и выразительнее. Кстати никакой из встреченных мной способов не умеет работать с битовыми полями (потому что нельзя взять адрес на такое поле), так что параноики могут использовать это для защиты от таких трюков (но вам не защититься от тех, кто эксплуатирует ODR мухахахаха)!
У VS Code по сравнению с VS для меня есть один фатальный недостаток - отсутствие Resharper. Стандартное расширение для C++ очень уж тормознутое.
отдебажить питоновский скрипт, который вызывает плюсовый код, да ещё и настроить это на обычный запуск дебаггера, да ещё и из панели тестирования (тест на питоне).
Вроде всё это можно и из большой студии сделать, Mixed mode debugging, кажется, называется, но у меня так и не завелось. С удовольствием почитал бы, как у вас это устроено.
В стандартную библиотеку это не пролезет, пока не будет принято решение сломать ABI. А это будет ещё не скоро (а может и не будет, хотя по слухам MS всё-таки что-то замышляет).
Возможно стоит добавить голосовалку при оставлении комментария верхнего уровня, хотя что-то в последнее время много комментариев уровня "очень полезно, автор красавчик" даже под некорпоративными статьями.
VTK пилит Kitware, так что вряд ли у них плохой CMake. Он не плохой, он объёмный и там много фич с кучей зависимостей, которые в случае с CPM придется разруливать вам.
Попробуйте, например, VTK добавить через CPM. Ну или CPython. А ещё лучше VTK с поддержкой python. Я не говорю, что это невозможно, в конце концов принцип работы у всех одинаковый. Просто в случае с vcpkg это кто-то уже сделал и оно тестируется, а в случае с CPM это придётся делать самостоятельно.
Пока ваше дерево зависимостей имеет глубину 1-2, пока используемые библиотеки ведут себя нормально, все работает. Дальше CPM начинает испытывать трудности и они сами предлагают использовать vcpkg в таком случае. В какой-то момент поймал себя на мысли, что мне проще написать рецепт для vcpkg, чем в очередной раз разбираться с тем, как для какой-то библиотеки собрать зависимости и как ей потом подсунуть флаги компиляции - vcpkg решает это за меня, причем кроссплатформенно.
Некоторые библиотеки экспортируют таргеты без namespace и с namespace. Вроде, libpng раньше экспортировал png и PNG::PNG. При использовании первого о возможной ошибке вы узнаете только во время компиляции, а при использовании второго - ещё на этапе конфигурации.
Читаю-читаю про употребление колючек conan'а, думаю ну вот сейчас автор наконец напишет "а давайте теперь попробуем vcpkg" но вот что-то не написал и продолжил употреблять колючки и делать какие-то выводы :(
Да, видимо проморгал.
Готовое решение тоже указано в статье: https://github.com/dfrib/accessprivate
Если в наличии есть C++20, то подход из статьи https://dfrib.github.io/a-foliage-of-folly/ мне кажется проще и выразительнее.
Кстати никакой из встреченных мной способов не умеет работать с битовыми полями (потому что нельзя взять адрес на такое поле), так что параноики могут использовать это для защиты от таких трюков (но вам не защититься от тех, кто эксплуатирует ODR мухахахаха)!
Ну то есть писать шлак, чтобы его же потом и минусовать.
Какой-то поток сознания и героическая борьба против чтения документации. https://doc.qt.io/qt-6/custom-types.html
У VS Code по сравнению с VS для меня есть один фатальный недостаток - отсутствие Resharper. Стандартное расширение для C++ очень уж тормознутое.
Вроде всё это можно и из большой студии сделать, Mixed mode debugging, кажется, называется, но у меня так и не завелось. С удовольствием почитал бы, как у вас это устроено.
Json тут правильный, просто автор - кэп, открыл для себя
cacheVariables.Пример кривой документации? Какой API переделали?
А давайте не простой? Почти в каждой статье берут сишную(!) либу на два файла и героически используют её API.
Давайте с зависимостями с кучей таргетов и плагинами. И с санитайзерами. А бонусом соберём это всё под Android.
Vcpkg хоть и не без недостатков, но по перечисленным параметрам не уступает Conan.
В стандартную библиотеку это не пролезет, пока не будет принято решение сломать ABI. А это будет ещё не скоро (а может и не будет, хотя по слухам MS всё-таки что-то замышляет).
Единственное полезное применение
std::for_each- это вместе сstd::execution. Все остальное хуже, чем обычный цикл for.Предлагаю вам взяться за теорему Ферма.
Лучше
vcpkg install qtbase qtdeclarative, иначе будет больно от сборки qtwebengine.Возможно стоит добавить голосовалку при оставлении комментария верхнего уровня, хотя что-то в последнее время много комментариев уровня "очень полезно, автор красавчик" даже под некорпоративными статьями.
VTK пилит Kitware, так что вряд ли у них плохой CMake. Он не плохой, он объёмный и там много фич с кучей зависимостей, которые в случае с CPM придется разруливать вам.
Попробуйте, например, VTK добавить через CPM. Ну или CPython. А ещё лучше VTK с поддержкой python.
Я не говорю, что это невозможно, в конце концов принцип работы у всех одинаковый. Просто в случае с vcpkg это кто-то уже сделал и оно тестируется, а в случае с CPM это придётся делать самостоятельно.
Пока ваше дерево зависимостей имеет глубину 1-2, пока используемые библиотеки ведут себя нормально, все работает. Дальше CPM начинает испытывать трудности и они сами предлагают использовать vcpkg в таком случае.
В какой-то момент поймал себя на мысли, что мне проще написать рецепт для vcpkg, чем в очередной раз разбираться с тем, как для какой-то библиотеки собрать зависимости и как ей потом подсунуть флаги компиляции - vcpkg решает это за меня, причем кроссплатформенно.
Не нужны. Если без этого не работает - что-то криво настроили или не почистили CMakeCache.txt.
90% ошибок из-за двух вещей:
Вместо использования предоставленного vcpkg тулчейна, как указано в документации, люди натравливают CMake прямо на папку vcpkg_installed.
При использовании тулчейна указывают его после вызова
project(), то есть слишком поздно.Какие библиотеки будут собираться решается триплетом.
https://learn.microsoft.com/en-us/vcpkg/concepts/triplets
В вашем случае это будет x64-windows-static или x64-windows-static-md, если ваш проект линкуется с CRT динамически.
PS: PNG с недавних пор сам экспортирует свои таргеты и это учтено в usage, обновитесь :)
Некоторые библиотеки экспортируют таргеты без namespace и с namespace. Вроде, libpng раньше экспортировал png и PNG::PNG. При использовании первого о возможной ошибке вы узнаете только во время компиляции, а при использовании второго - ещё на этапе конфигурации.