Оглавления нет. Вместо кодовых вставок сырой текст. Пояснений почти нет, просто некрасиво оформленный код
Полистал документацию. Компоненты обо всем и ни о чем. Ощущение, что было принято решение сделать свои велосипеды почти на всё, когда есть альтернативы. У такого решения есть обоснование?
Поверил бы больше, если датой публикации было бы 1 апреля
Для чайников - я просто могу взять свою залежавшуюся rx-580 и под линуксами попользоваться разным локальным ИИ инструментарием, который по идее работает с ядрами CUDA?
Я помню пробовал в SD побаловаться на ubuntu, но запустилось соответственно только под CPU (8 ядер 16 потоков) и под какие-то там средние настройки, генерацию одной итерации нужно ждать минуты 3. Долговато. Что можно ожидать от rx-580 карточки в среднем?
Концепция простая, Substitation Failure Is Not An Error. Компилятор, когда ловит прям ошибку подстановки типа, не завершает работу с ошибкой, а просто отбрасывает этот вариант, продолжает работу.
Скрытый текст
Вот например трейт на проверку, есть ли в типе метод "hello"
В данном случае ошибку может вызвать выражение decltype(&T::hello) . Если метода hello нет, то это ошибка подстановки, но SFINAE напрямую говорит нам что это не ошибка :) И этот вариант просто будет отброшен. Останется по умолчанию тот первый вариант, который будет типа false. Если же метод hello есть и ошибки подстановки не произойдет, то для такого типа будет true и метод можно вызвать
Через такое игольное ушко протянуто почти всё мета-программирование с++. Т.е. у нас в императивном стиле нет мета-информации, мы не можем перебрать в цикле поля, методы и всё такое. (рефлексия в С++26 планируется). Мы можем лишь делать предположения и проверять наши предположения
var list = new List<int>(initialList)
{
[^1] = 15
};
Когда-то я смотрел на похожую штуку в Python и молился чтобы этого не увидеть в своем ламповом C#. Что не версия, то завозят кучу синтаксического сахара, всё более изощренные ключевые слова и операторы. В пределе ситуация такая, что в какой-то момент ловишь передоз и синтаксический диабет.
Для этого перенесем реализацию в заголовочный файл и добавим ключевое слово inline для соблюдения ODR — one definition rule. То же самое сделаем и для конструктора.
Методы классов/структур inline по умолчанию, если объявление и определение это одно и то же (в определении класса, которое, как правило, в заголовочнике).
Такого тезиса в статье не было. Есть легкая кастомизируемость контейнера, но это мелочи. В основном все юзают QC и не с моей подачи
вы насильно впихиваете
Каюсь, такое есть. В этом смысле я фанатик. Но у людей все равно есть выбор, и мне приятно, что много людей посчитали это удобным для каждодневного использования в рабочих задачах
нифига она не на 5 минут
Инструкция сильно меньше статьи. В статье отразил ход мыслей в процессе создания и с какими проблемами сталкивался. В боевой инструкции на голую систему 6 шагов, 4 из которых просто копипаст команд в терминал (установка докера, подтягивание скриптов запуска с репозитория, ...). 5 минут это для того кто делает в первый раз, я для интереса прогонял за 1 минуту.
проект не надо было разворачивать год
про год речи нигде не было. 1-2 дня. Развернуть чтобы просто скомпилировалось это одно, это условно "быстро" Развернуть с учетом всего накопленного полезного инструментария, специфичных настроек, ... уже долго
Вместо того, чтобы юзать простой удобный инструмент, вы из принципа городите костыли
Изначально работал как вы и говорите, QC на хосте. Но неоднократно столкнувшись с проблемами, описанными в статье, нашел для себя такое решение. Оно оказалось настолько удобным, что больше QC на хосте у меня не бывал. И не одному мне полезно - как я уже говорил, многие коллеги пользуют на постоянку.
у меня есть вынуждено-развернутое окружение проекта под винду, на домашнем ПК и иногда (пару раз в квартал) я использую его для решения редких специфичных задач, где платформа играет роль. Но это не значит, что я хотел бы сидеть на ней всегда, как я уже сказал, у меня нет личного предпочтения к Win. Так что да, я избегаю винды
В статье упомянул, что распределение рабочих компов примерно 50 на 50 (win, linux), плюс тестируют также на разных платформах, так что у меня нет вынужденной необходимости всегда держать под рукой win окружение
Вы при желании можете просто запустить QtC внутри WSL и всё
Да, как и могу запустить его на хост-линуксе. Но смысл именно в том, чтобы собрать в пакет утилиты, определенные зависимости, настройки разных конфиг файлов, ... И собственно иметь переносимое рабочее окружение, которое шарится не только между моими рабочими компами, но и с коллегами.
Этим стабильно пользуется 10-15 человек, потому что с нуля настраивать окружение долго, а у меня в рабочей документации четкая инструкция по которой можно за 5 минут получить полностью настроенную IDE с комплектом, подвязанными дебагерами, сборочной системой нужной версии, шаблонами создаваемых продуктов, сниппетами, собранной под Qt комплект утилитой интроспеции Qt приложений, ... и многое многое другое. За 5 минут реального времени с вычетом пассивного ожидания скачивания образа.
Нет, контейнер состряпал уже как 2 года назад, тогда этой штуки не было..) Вообще вижу там целый набор расширений недавних от Qt. Возможно, когда с их помощью можно будет делать все то же, что и в QC, то стоит задуматься еще разочек о переходе на базу VSC :)
У меня нет предпочтения к Win как к рабочей системе, но допустим. В крайнем случае в этом выражении Win+WSL можно заменить на какой-нибудь хостовый линукс и получится что-то например Ubuntu+VSC
Как у вас обеспечивается переносимость такого рабочего окружения между компьютерами?
вот побольше конкретики плюсом к тому, что написал @navrocky
Это не описано в статье, но QC в дереве проекта от сборочной системы qbs имеет полезное контекстное меню, которым я регулярно пользуюсь (добавление продуктов, добавления файлов в ресурсы qrc, ...). В единственном расширении VSC на qbs контекстного меню нет совсем, эти фичи пришлось бы делать по другому, либо допиливать расширение
В проекте используем кастомные wizard. В VSC есть расширения такого плана, но нужно было бы всё на них переделать
Это не описано в статье, но Подавляющее большинство коллег работают на QC. Мое решение с порога было бы сильно менее популярное для общественности и скорее всего только я один бы этим пользовался, будь базой VSC.
Qt-шная документация в формате .qch. Я не нашел способа отображать ее в VSC. В QC по F1 на каком-либо символе мгновенно получаешь доку
p.s. я не говорю что невозможно использовать VSC как среду под описанный стек, но в моих условиях QC смотрелся выигрышнее, как быстрое и не сильно ломающее традиции, решение
Благодарю за дельный совет. В текущей реализации это уже пихать некуда, т.к. разделение create | start. Но возможно в будущем, для каких-то других ситуаций будет полезно
Это из разряда мечтаний. Qt-специфичные технологии имеют лучшую поддержку в IDE, внезапно, QtCreator :) И обеспечивать поддержку этим приблудам в vsc желания мало, с учетом того что из коробки в QtCreator они есть.
Например в vsc лучше обертка над отладчиком (ИМХО), на уровне расширений больше вариантов по созданию шаблонов продуктов, намного понятнее механизм создания своих расширений, ну и в целом сообщество намного больше со всеми вытекающими.
Но этого недостаточно на текущем уровне, когда вся эта история с IDE, исключительно моя инициатива и держится только на энтузиазме. Выхлоп будет несопоставим трудозатратам, так я это оценил, когда с кавалерийского наскока попробовал получить в vsc уровень комфорта QtCreator со стеком Qt + QML + C++
Если вы имеете ввиду какой-нибудь .ova (например для virtualBox), то на мой взгляд нет:
Есть тормоза и задержки (даже на хорошем компуторе). Как я не пытался прокидывать драйвера видеокарты, у меня не получалась безупречная скорость отклика, как с докера. Вероятно дело в том что там активно целое десктоп окружение в довесок
Обновление версии = скачать новый бинарный экспорт .ova, например 10гб (оптимистично). Снимки (snapshot вроде?) поддерживаются только на машине где они были сделаны и не экспортируются для других пользователей.
Придумываем правило: комментарий документации в .h не должен иметь расхождений с дубликатом в .cpp.
Пишем утилиту по автоматической синхронизации шапок комментариев .h -> .cpp (подсказка, как это можно сделать по-взрослому -> clang умеет привязывать doxygen комменты к узлам AST C++)
Если слегка запарится с именем и сделать имя файлов тестов типо такого:
Для Func.cs
Тест - Func.cs.test.cs
То в среде разработки он будет отображаться как вложенный в Func.cs, более явная принадлежность
Это также работает например с razor
File.razor
File.razor.cs (отображается как вложенный)
Репозиторий называется CUtils-Win, в Readme еще раз прописано CUtils Windows
В репозитории лежат скомпилированные библиотеки под Windows.
Где тут кроссплатформа?
Последний пример кода явно поврежден.
Оглавления нет. Вместо кодовых вставок сырой текст. Пояснений почти нет, просто некрасиво оформленный код
Полистал документацию. Компоненты обо всем и ни о чем. Ощущение, что было принято решение сделать свои велосипеды почти на всё, когда есть альтернативы. У такого решения есть обоснование?
Поверил бы больше, если датой публикации было бы 1 апреля
За потенциально глупый коммент - аймсори
Для чайников - я просто могу взять свою залежавшуюся rx-580 и под линуксами попользоваться разным локальным ИИ инструментарием, который по идее работает с ядрами CUDA?
Я помню пробовал в SD побаловаться на ubuntu, но запустилось соответственно только под CPU (8 ядер 16 потоков) и под какие-то там средние настройки, генерацию одной итерации нужно ждать минуты 3. Долговато. Что можно ожидать от rx-580 карточки в среднем?
умоляю, не надо новых ключевых слов :)
Концепция простая, Substitation Failure Is Not An Error. Компилятор, когда ловит прям ошибку подстановки типа, не завершает работу с ошибкой, а просто отбрасывает этот вариант, продолжает работу.
Скрытый текст
В данном случае ошибку может вызвать выражение
decltype(&T::hello). Если метода hello нет, то это ошибка подстановки, но SFINAE напрямую говорит нам что это не ошибка :) И этот вариант просто будет отброшен. Останется по умолчанию тот первый вариант, который будет типа false. Если же метод hello есть и ошибки подстановки не произойдет, то для такого типа будет true и метод можно вызватьЧерез такое игольное ушко протянуто почти всё мета-программирование с++. Т.е. у нас в императивном стиле нет мета-информации, мы не можем перебрать в цикле поля, методы и всё такое. (рефлексия в С++26 планируется). Мы можем лишь делать предположения и проверять наши предположения
Когда-то я смотрел на похожую штуку в Python и молился чтобы этого не увидеть в своем ламповом C#. Что не версия, то завозят кучу синтаксического сахара, всё более изощренные ключевые слова и операторы. В пределе ситуация такая, что в какой-то момент ловишь передоз и синтаксический диабет.
Методы классов/структур inline по умолчанию, если объявление и определение это одно и то же (в определении класса, которое, как правило, в заголовочнике).
Можно конечно написать, но это ничего не делает
Такого тезиса в статье не было. Есть легкая кастомизируемость контейнера, но это мелочи. В основном все юзают QC и не с моей подачи
Каюсь, такое есть. В этом смысле я фанатик. Но у людей все равно есть выбор, и мне приятно, что много людей посчитали это удобным для каждодневного использования в рабочих задачах
Инструкция сильно меньше статьи. В статье отразил ход мыслей в процессе создания и с какими проблемами сталкивался. В боевой инструкции на голую систему 6 шагов, 4 из которых просто копипаст команд в терминал (установка докера, подтягивание скриптов запуска с репозитория, ...). 5 минут это для того кто делает в первый раз, я для интереса прогонял за 1 минуту.
про год речи нигде не было. 1-2 дня.
Развернуть чтобы просто скомпилировалось это одно, это условно "быстро"
Развернуть с учетом всего накопленного полезного инструментария, специфичных настроек, ... уже долго
Изначально работал как вы и говорите, QC на хосте. Но неоднократно столкнувшись с проблемами, описанными в статье, нашел для себя такое решение. Оно оказалось настолько удобным, что больше QC на хосте у меня не бывал. И не одному мне полезно - как я уже говорил, многие коллеги пользуют на постоянку.
у меня есть вынуждено-развернутое окружение проекта под винду, на домашнем ПК и иногда (пару раз в квартал) я использую его для решения редких специфичных задач, где платформа играет роль. Но это не значит, что я хотел бы сидеть на ней всегда, как я уже сказал, у меня нет личного предпочтения к Win. Так что да, я избегаю винды
В статье упомянул, что распределение рабочих компов примерно 50 на 50 (win, linux), плюс тестируют также на разных платформах, так что у меня нет вынужденной необходимости всегда держать под рукой win окружение
Да, как и могу запустить его на хост-линуксе. Но смысл именно в том, чтобы собрать в пакет утилиты, определенные зависимости, настройки разных конфиг файлов, ... И собственно иметь переносимое рабочее окружение, которое шарится не только между моими рабочими компами, но и с коллегами.
Этим стабильно пользуется 10-15 человек, потому что с нуля настраивать окружение долго, а у меня в рабочей документации четкая инструкция по которой можно за 5 минут получить полностью настроенную IDE с комплектом, подвязанными дебагерами, сборочной системой нужной версии, шаблонами создаваемых продуктов, сниппетами, собранной под Qt комплект утилитой интроспеции Qt приложений, ... и многое многое другое. За 5 минут реального времени с вычетом пассивного ожидания скачивания образа.
Нет, контейнер состряпал уже как 2 года назад, тогда этой штуки не было..)
Вообще вижу там целый набор расширений недавних от Qt. Возможно, когда с их помощью можно будет делать все то же, что и в QC, то стоит задуматься еще разочек о переходе на базу VSC :)
У меня нет предпочтения к Win как к рабочей системе, но допустим. В крайнем случае в этом выражении Win+WSL можно заменить на какой-нибудь хостовый линукс и получится что-то например Ubuntu+VSC
Как у вас обеспечивается переносимость такого рабочего окружения между компьютерами?
вот побольше конкретики плюсом к тому, что написал @navrocky
Это не описано в статье, но
QC в дереве проекта от сборочной системы qbs имеет полезное контекстное меню, которым я регулярно пользуюсь (добавление продуктов, добавления файлов в ресурсы qrc, ...). В единственном расширении VSC на qbs контекстного меню нет совсем, эти фичи пришлось бы делать по другому, либо допиливать расширение
В проекте используем кастомные wizard. В VSC есть расширения такого плана, но нужно было бы всё на них переделать
Это не описано в статье, но
Подавляющее большинство коллег работают на QC. Мое решение с порога было бы сильно менее популярное для общественности и скорее всего только я один бы этим пользовался, будь базой VSC.
Qt-шная документация в формате .qch. Я не нашел способа отображать ее в VSC. В QC по F1 на каком-либо символе мгновенно получаешь доку
p.s. я не говорю что невозможно использовать VSC как среду под описанный стек, но в моих условиях QC смотрелся выигрышнее, как быстрое и не сильно ломающее традиции, решение
Благодарю за дельный совет. В текущей реализации это уже пихать некуда, т.к. разделение create | start. Но возможно в будущем, для каких-то других ситуаций будет полезно
Это из разряда мечтаний. Qt-специфичные технологии имеют лучшую поддержку в IDE, внезапно, QtCreator :) И обеспечивать поддержку этим приблудам в vsc желания мало, с учетом того что из коробки в QtCreator они есть.
Например в vsc лучше обертка над отладчиком (ИМХО), на уровне расширений больше вариантов по созданию шаблонов продуктов, намного понятнее механизм создания своих расширений, ну и в целом сообщество намного больше со всеми вытекающими.
Но этого недостаточно на текущем уровне, когда вся эта история с IDE, исключительно моя инициатива и держится только на энтузиазме. Выхлоп будет несопоставим трудозатратам, так я это оценил, когда с кавалерийского наскока попробовал получить в vsc уровень комфорта QtCreator со стеком Qt + QML + C++
Немного поглазел, выглядит интересно. До этого не щупал. Думаю пощупаю на досуге, благодарю
Если вы имеете ввиду какой-нибудь .ova (например для virtualBox), то на мой взгляд нет:
Есть тормоза и задержки (даже на хорошем компуторе). Как я не пытался прокидывать драйвера видеокарты, у меня не получалась безупречная скорость отклика, как с докера. Вероятно дело в том что там активно целое десктоп окружение в довесок
Обновление версии = скачать новый бинарный экспорт .ova, например 10гб (оптимистично). Снимки (snapshot вроде?) поддерживаются только на машине где они были сделаны и не экспортируются для других пользователей.
Такая сигнатура с передачей по значению позволяет мувать в функцию, но при этом остается вариант с копией. Например:
void setSomeSh(std::shared_ptr<Resource> ptr) {
m_some = std::move(ptr);
}
Вызывающий код может передать туда lvalue, или rvalue
std::shared_ptr<Resource> myPtr;
setSomeSh(myPtr)
setSomeSh(std::move(myPtr));
В случае конст ссылки всегда будет лишний инкремент шареда, даже если его можно было избежать, сигнатура со значением дает выбор.
Сори что без кодэблоков, пишу с телефона
clang-format не рассматривался? Заявляет, что умеет в Java (в том числе)
Для С++ пользуем в конторе давно
Вот вам тема для еще одной статьи.
Придумываем правило: комментарий документации в .h не должен иметь расхождений с дубликатом в .cpp.
Пишем утилиту по автоматической синхронизации шапок комментариев
.h -> .cpp (подсказка, как это можно сделать по-взрослому -> clang умеет привязывать doxygen комменты к узлам AST C++)
profit
Если имеются ввиду шапки в .h, то они перемещены не будут, т.к. определения приводятся к порядку объявлений, а не наоборот
Если у вас в .cpp есть шапки с комментами, не знаю, такие сценарии видел крайне редко