Отлично что появляются нативные версии библиотек под каждый язык. Будет работа у разработчиков, будут платить зарплату на поддержку данной реализации под конкретный язык.
Тем не менее, я не уверен что кодировщики (ffmpeg), архиваторы (любой хоть zlib), мат-либы (NumPy) и многи другие вообще хоть когда-то будут переписывать под какой-то иной язык. C и в куда меньшей мере CPP здесь вне конкуренции.
То что отсутствует библиотека в vcpkg, ну так мы же должны на дистанции смотреть с конкретными примерами. По vcpkg, когда они разобрались с базовой архитектурой своего пакетного менеджера (а там переделок хватало в первые три года), то они взяли норм темп на добавление новых либ. Вот здесь страница с релизами vcpkg, https://github.com/microsoft/vcpkg/releases, обратите внимание что в каждом релизе указано кол-во обновленных и добавленных библиотек.
Релизные срезы пошли каждый месяц и ежемесячно добавляется по 5-10-20 библиотек. А обновляется по 100-200. Это отличный уровень поддержки я уверен как от сообщества так и от множества коммерческих компаний. Пройдет немного времени и будет там все Вам необходимое.
Обратите внимание что порт не добавить и не обновить если не пройдет внутренний CI/CD на всех поддерживаемых платформах а также глубокий ревью - это указывает на очень хорошие контроль качества и регрессий.
И на этом фоне давайте сравним термин "тулинг плюсов" 10 лет назад со сборкой всего самостоятельно километровыми скриптами/руками под нужный компилятор и сейчас с пакетными менеджерами. Ну и наконец - другие языки моложе, в них учтено множество ошибок, а многие из них и не компилируемые вовсе, там от пакетного менеджера требуется не собрать мудреную библиотеку с десятком зависимостей разными компиляторами под разные платформы, а тупо скачать несколько файлов и разложить по папочкам. Уровень сложности решаемых задач даже нельзя сопоставлять.
Ну короче, это все лирика, я просто за позитивный настрой =)
Достаточно открыть vcpkg.io и ознакомиться с огромным количеством библиотек написанных на C/CPP, чтоб увидеть - 90% современной базы кода основана на указанных языках. Все остальные языки и фреймворк не переписывают ни одну базовую библиотеку но почти все в той или иной мере через биндинги и прочие приколы завязаны на них. Таким образом место CPP отнюдь не только в игровых движках/десктопах/ембедед. Это фундамент на котором строится если не все, то львиная доля остального.
ПС. Извините, сразу дополню коммент мнением по самой статье, раз уж начал 🙂.
Ну вы бы блин ещё к фортрану и коболу докопались по поводу синтаксиса/стиля итд. CPP занимает свою важную нишу и имеет преогромную кодовую базу(пример выше), вносить изменения в язык нужно крайне осторожно.
Долго хидеры компилятся? Ну дайте больше потоков, юзайте jom коли студийный nmake по сей день в одно ядро долбиться. Используйте cmake+ninja итд. Это вообще не проблема уже, а время разработчиков языка можно потратить на более важные проблемы.
Не читаемые ошибки и тупые классические IDE, так не проблема языка - это MS и Ко должны позаботиться.
Если среда разработки лагает - переходите на Qt Creator или VS Code и CMake, никаких лагов, кроссплатформенность, менеджмент зависимостей из vcpkg, простота и лёгкость из коробки.
Если сам язык не устраивает или не подходит под какую-то задачу, ну так возьмите другой язык - их вон наклепали гору куда лучше под конкретные задачи. Правда там любой поскреби - рано или поздно доскребешься до C/CPP или библиотек на них.
То как выглядят лямбды, итераторы, стандартная библиотека - ну вот так вот исторически сложилось, такова цена свободы и универсальности языка, да есть определенные нюансы. Ну так зато к примеру у вас лямбда это +/- обычный CPP объект (ну функтор), только безымянный и в compile time созданный компилятором, потому и синтаксис такой специфический.
Ну да надо лямбде перечислить что нужно захватить или просто захватить все, но где тут проблема то? Вы хотите чтоб решение принималось за вас? А как вы можете рассказать? Какой-то может есть универсальный или эвристический алгоритм который поймет что нужно а что нет? А это повлияет на рантайм или на компайлтайм?
Тут чего не коснись - может так в ответ по башке прилететь всему сообществу - десятилетиями аукаться будет. Многое из сказанного в статье это вкусовщина. Мне вот например нравится как многое сделано.
Уж пусть лучше CPP развивается медленно но предсказуемо. Вы смотрите вокруг на примеры. Питон с 2 на 3 версию сколько уже, 15 лет до конца никак не перейдет? До сих пор тянут лямку с питоном 2.7, все никак не закопают и в линуксе до сих пор жонглировать приходится чтоб то один то другой скрипт запустить то во 2 то в 3 питоне. А тоже были светлые идеи типа "давайте-ка за старое не будем цепляться". Надо оно в языке который вместе с C является базой для чуть не всего ИТ? Не думаю.
ППС: тем не менее спасибо за статью, было интересно, прошу прощения за излишнюю эмоциональность в изложении мнения/ответа 😉. Предлагаю сконцентрироваться на плюсах которые вокруг языка появились и развиваются в верную сторону, типа стандартизации проектов с CMake/CMakePresets, с нормальными менеджерами зависимостей типа vcpkg/conan итд. Может сам язык и не сильно развивается, но инфраструктура вокруг него разительно улучшилась в последние 5 лет.
Безусловно, содержимое статьи полезно в качестве иллюстрации как все слелать с нуля, но в реальных проектах я бы рекомендовал использовать vcpkg, это если не отраслевой стандарт, то уж точно очень популярная штука для сборки c/cpp библиотек под практически все актуальные платформы и их варианты.
Т.е. Ваша сборка свелась бы к чему-то типа: ./vcpkg install opus:arm-android opus:x64-android и тд. Попробуйте обязательно.
Понимаю что у Вас речь идет о самостоятельном изучении работы с IR, спасибо за статью! Просто дополню, похожую задачу я лично решал при помощи Aqara Air Conditioning Companion, это такая розетка от Xiaomi с IR и Wi-Fi, может бысть использована как через приложения Xiaomi так и интегрироваться с Android или Apple HomeKit (через homebridge на Raspberry PI), а также может управляться вручную через протокол MIIO. При этом сам Raspberry может находиться где-то в кладовке, а рядом с кондером будет лишь данная розетка-переходник и связь по Wi-Fi.
Поясню свой вопрос про виды деятельности, список я видел, но насколько я помню — весь год обсуждалось что самозанятыми могут быть только репетиторы, няни и клининг услуги. Поэтому и не сразу понял как интерпретировать список. Собственно круто, что ограничений по категориям, если верить списку — нет.
Что касается «места деятельности» — вопрос занятный, в статье написано:
Причем в законе речь идет не о регистрации по месту жительства (или прописке, как привыкли называть), а о месте ведения деятельности. Что это такое, в законе не указано.
Поэтому первый вопрос – что считать местом ведения деятельности для самозанятого лица.
Вкупе с тем что нет договоров/счетов и вообще отчетности, а «место деятельности» может будет и не привязано к месту регистрации — то что мешает указать любой регион? Более того, а если заказчики в основном из Мск? Место деятельности — по месту расположения заказчиков или по месту исполнителя? А если заказчики иностранцы (Upwork к примеру)? В общем ооочень много неотвеченных вопросов есть к этому, без сомнения, полезному закону.
Насчет 3D. Как-то пробовал запустить Гвинт (https://www.playgwent.com/ru), все было очень плохо с cpu и температурой, хотя на обычной винде в примерно аналогичной конфигурации, подобных проблем не было. Может конечно это не относится к Parallels Desktop, но все же ситуация печалит)
Сложности могут возникнуть только при необходимости запустить кутешный eventloop, да и то решаемые, в остальном же QtCore такая же подключаемая библиотека как и любая другая, за одним исключением — это хорошо документированное, многофункциональное решение, а не сборная солянка, как тот же boost.
Насчет поддержки платформ — так в Qt есть слой архитектурной абстракции, нужно реализовать не так много компонентов, чтоб библиотека завелась на новой платформе (http://doc.qt.io/qt-5/qpa.html, http://doc.qt.io/qt-5/portingguide.html).
Уверен, что работа проведена масштабная, хочется почитать остальные статьи, но… Зачем вы переизобрели Qt? В крайнем случае могли бы его форкнуть и развивать, но вот так… Честно сказать я офигел))
PS: для кроссплатформенной работы с сетью есть обычные сокеты. Curl немного облегчает задачу, но вы ведь все делаете по хардкору)
А если серьезно, ваш проект очень крут. Желаю удачи в развитии!
Офтоп.
Последнее время меня терзает вопрос, а почему собственно производители браузеров не хотят добавить нативную поддержку нового языка, похожего на QML, как альтернативу HTML в свои движки?
Это же было бы так круто — заменить весь этот ужас HTML/CSS/etc на новый JSON-подобый и декларативный стандарт! Тем более что есть готовый пример в виде Qt/QML.
Я понимаю, что сейчас активно пилится WebAssembly и когда он будет готов, то хоть весь Qt можно будет в браузере использовать, но все же это немного не то — не будет 99% веб-программистов/верстальщиков его юзать.
Отлично что появляются нативные версии библиотек под каждый язык. Будет работа у разработчиков, будут платить зарплату на поддержку данной реализации под конкретный язык.
Тем не менее, я не уверен что кодировщики (ffmpeg), архиваторы (любой хоть zlib), мат-либы (NumPy) и многи другие вообще хоть когда-то будут переписывать под какой-то иной язык. C и в куда меньшей мере CPP здесь вне конкуренции.
То что отсутствует библиотека в vcpkg, ну так мы же должны на дистанции смотреть с конкретными примерами. По vcpkg, когда они разобрались с базовой архитектурой своего пакетного менеджера (а там переделок хватало в первые три года), то они взяли норм темп на добавление новых либ. Вот здесь страница с релизами vcpkg, https://github.com/microsoft/vcpkg/releases, обратите внимание что в каждом релизе указано кол-во обновленных и добавленных библиотек.
Релизные срезы пошли каждый месяц и ежемесячно добавляется по 5-10-20 библиотек. А обновляется по 100-200. Это отличный уровень поддержки я уверен как от сообщества так и от множества коммерческих компаний. Пройдет немного времени и будет там все Вам необходимое.
Обратите внимание что порт не добавить и не обновить если не пройдет внутренний CI/CD на всех поддерживаемых платформах а также глубокий ревью - это указывает на очень хорошие контроль качества и регрессий.
Да даже свой порт сделать очень просто, в несколько строчек (если исходная либа на CMake), вот взгляните на пару моих примеров: https://github.com/microsoft/vcpkg/pull/34510
И на этом фоне давайте сравним термин "тулинг плюсов" 10 лет назад со сборкой всего самостоятельно километровыми скриптами/руками под нужный компилятор и сейчас с пакетными менеджерами. Ну и наконец - другие языки моложе, в них учтено множество ошибок, а многие из них и не компилируемые вовсе, там от пакетного менеджера требуется не собрать мудреную библиотеку с десятком зависимостей разными компиляторами под разные платформы, а тупо скачать несколько файлов и разложить по папочкам. Уровень сложности решаемых задач даже нельзя сопоставлять.
Ну короче, это все лирика, я просто за позитивный настрой =)
Достаточно открыть vcpkg.io и ознакомиться с огромным количеством библиотек написанных на C/CPP, чтоб увидеть - 90% современной базы кода основана на указанных языках. Все остальные языки и фреймворк не переписывают ни одну базовую библиотеку но почти все в той или иной мере через биндинги и прочие приколы завязаны на них. Таким образом место CPP отнюдь не только в игровых движках/десктопах/ембедед. Это фундамент на котором строится если не все, то львиная доля остального.
ПС. Извините, сразу дополню коммент мнением по самой статье, раз уж начал 🙂.
Ну вы бы блин ещё к фортрану и коболу докопались по поводу синтаксиса/стиля итд. CPP занимает свою важную нишу и имеет преогромную кодовую базу(пример выше), вносить изменения в язык нужно крайне осторожно.
Долго хидеры компилятся? Ну дайте больше потоков, юзайте jom коли студийный nmake по сей день в одно ядро долбиться. Используйте cmake+ninja итд. Это вообще не проблема уже, а время разработчиков языка можно потратить на более важные проблемы.
Не читаемые ошибки и тупые классические IDE, так не проблема языка - это MS и Ко должны позаботиться.
Если среда разработки лагает - переходите на Qt Creator или VS Code и CMake, никаких лагов, кроссплатформенность, менеджмент зависимостей из vcpkg, простота и лёгкость из коробки.
Если сам язык не устраивает или не подходит под какую-то задачу, ну так возьмите другой язык - их вон наклепали гору куда лучше под конкретные задачи. Правда там любой поскреби - рано или поздно доскребешься до C/CPP или библиотек на них.
То как выглядят лямбды, итераторы, стандартная библиотека - ну вот так вот исторически сложилось, такова цена свободы и универсальности языка, да есть определенные нюансы. Ну так зато к примеру у вас лямбда это +/- обычный CPP объект (ну функтор), только безымянный и в compile time созданный компилятором, потому и синтаксис такой специфический.
Ну да надо лямбде перечислить что нужно захватить или просто захватить все, но где тут проблема то? Вы хотите чтоб решение принималось за вас? А как вы можете рассказать? Какой-то может есть универсальный или эвристический алгоритм который поймет что нужно а что нет? А это повлияет на рантайм или на компайлтайм?
Тут чего не коснись - может так в ответ по башке прилететь всему сообществу - десятилетиями аукаться будет. Многое из сказанного в статье это вкусовщина. Мне вот например нравится как многое сделано.
Уж пусть лучше CPP развивается медленно но предсказуемо. Вы смотрите вокруг на примеры. Питон с 2 на 3 версию сколько уже, 15 лет до конца никак не перейдет? До сих пор тянут лямку с питоном 2.7, все никак не закопают и в линуксе до сих пор жонглировать приходится чтоб то один то другой скрипт запустить то во 2 то в 3 питоне. А тоже были светлые идеи типа "давайте-ка за старое не будем цепляться". Надо оно в языке который вместе с C является базой для чуть не всего ИТ? Не думаю.
ППС: тем не менее спасибо за статью, было интересно, прошу прощения за излишнюю эмоциональность в изложении мнения/ответа 😉. Предлагаю сконцентрироваться на плюсах которые вокруг языка появились и развиваются в верную сторону, типа стандартизации проектов с CMake/CMakePresets, с нормальными менеджерами зависимостей типа vcpkg/conan итд. Может сам язык и не сильно развивается, но инфраструктура вокруг него разительно улучшилась в последние 5 лет.
Безусловно, содержимое статьи полезно в качестве иллюстрации как все слелать с нуля, но в реальных проектах я бы рекомендовал использовать vcpkg, это если не отраслевой стандарт, то уж точно очень популярная штука для сборки c/cpp библиотек под практически все актуальные платформы и их варианты.
Т.е. Ваша сборка свелась бы к чему-то типа: ./vcpkg install opus:arm-android opus:x64-android и тд. Попробуйте обязательно.
Правда корпус самому надо подбирать.
Вот в этом репозитории можно почитать подробнее github.com/LASER-Yi/homebridge-mi-acpartner, там же в issues#64 есть дополнение как завести с любым кондером.
PS: Сорри если слегка не в тему)
Поясню свой вопрос про виды деятельности, список я видел, но насколько я помню — весь год обсуждалось что самозанятыми могут быть только репетиторы, няни и клининг услуги. Поэтому и не сразу понял как интерпретировать список. Собственно круто, что ограничений по категориям, если верить списку — нет.
Что касается «места деятельности» — вопрос занятный, в статье написано:
Вкупе с тем что нет договоров/счетов и вообще отчетности, а «место деятельности» может будет и не привязано к месту регистрации — то что мешает указать любой регион? Более того, а если заказчики в основном из Мск? Место деятельности — по месту расположения заказчиков или по месту исполнителя? А если заказчики иностранцы (Upwork к примеру)? В общем ооочень много неотвеченных вопросов есть к этому, без сомнения, полезному закону.
Сложности могут возникнуть только при необходимости запустить кутешный eventloop, да и то решаемые, в остальном же QtCore такая же подключаемая библиотека как и любая другая, за одним исключением — это хорошо документированное, многофункциональное решение, а не сборная солянка, как тот же boost.
Насчет поддержки платформ — так в Qt есть слой архитектурной абстракции, нужно реализовать не так много компонентов, чтоб библиотека завелась на новой платформе (http://doc.qt.io/qt-5/qpa.html, http://doc.qt.io/qt-5/portingguide.html).
Ах да, еще pimpl вместо ifdef хорошо бы использовать
Уверен, что работа проведена масштабная, хочется почитать остальные статьи, но… Зачем вы переизобрели Qt? В крайнем случае могли бы его форкнуть и развивать, но вот так… Честно сказать я офигел))
PS: для кроссплатформенной работы с сетью есть обычные сокеты. Curl немного облегчает задачу, но вы ведь все делаете по хардкору)
А если серьезно, ваш проект очень крут. Желаю удачи в развитии!
Офтоп.
Последнее время меня терзает вопрос, а почему собственно производители браузеров не хотят добавить нативную поддержку нового языка, похожего на QML, как альтернативу HTML в свои движки?
Это же было бы так круто — заменить весь этот ужас HTML/CSS/etc на новый JSON-подобый и декларативный стандарт! Тем более что есть готовый пример в виде Qt/QML.
Я понимаю, что сейчас активно пилится WebAssembly и когда он будет готов, то хоть весь Qt можно будет в браузере использовать, но все же это немного не то — не будет 99% веб-программистов/верстальщиков его юзать.