Сам недавно обдумывал сделать себе кастомный джойстик. Поэтому вопрос. А почему используете обычный аналоговый стик, а не стик с датчиками холла? Дорого, сложно? У таких стиков лучше с дребезгом и долговечностью дела обстоят. К примеру вот есть ребятки, которые предлагают подобные: https://thegamingsetup.com/guides/hall-effect-joysticks
Если посмотреть на скриншоты двух приложений, то, справедливости ради, всё-таки иконки они нарисовали свои.
Код у них свой, к кодовой базе Adobe отношения не имеет.
Если вы подразумеваете под "спёрли" похожий дизайн. То я предполагаю, что это было сделано сознательно, смысл изобретать велосипед, это удобно, к тому же переход для пользователей на данное приложение будет идти быстрее. Тут, конечно, есть спорный момент, но учитывая, что они это написали сами, неплохо.
Пиар у отечественных продуктов слабоват. Сложно найти их среди зарубежных контор. Но, в частности, отечественный аналог фотошопа вполне себе разрабатывается и продается.
По поводу FastPimpl в видео, хардкодить размер в хедере это первое что приходит в голову, это, конечно, на этапе компиляции проверяется, да и работает в итоге. Но как-то выглядит не очень. Спасибо за ссылку
Ну к слову C# крутой. Я на нем тестовые программки пишу, удобней чем С++. А местами, из-за JIT компиляции бывало, что он быстрее работал нежели программа на C++.
Самое интересное что все вопросы ясны, только вот некоторые термины были непонятные. Это как проходить интервью первый раз и пятый за долгое время. На первом интервью ты все по факту знаешь, но не знаешь многих терминов на английском, а к пятому ты уже синхронизировался и в теме)
Ну я скажу так, я разработчик низкоуровневого софта (драйвера под ОС, либо bare metal под embedded) и мой основной язык это С. По большей части никаких динамических алокаций, абстракций и прочего, что сожрет и так сильно ограниченные ресурсы. И проблема С++ в том, что его многие абстракции не годятся для производительности, они больше про удобство, хотя если не использовать все эти фичи, то разницы нет. И поэтому С++ развращает)
Да не в этом идея) Идея изначальная была в том, чтобы в *.h файле для всех платформ не было различий и не было препроцессора. CRTP позволяет это сделать статически.
CRTP поможет поскольку скроет все платформозависимые типы в классе, который унаследован от шаблонного класса и который находится в платформозависимом файле *.cpp. Тут единственная проблема без оптимизации метод шаблонного класса будет вызывать аналогичный метод целевого класса, как прокси. Но при оптимизации оверхеда не будет. Но шаблоны это такое.
А вот то, что виртуальные методы ухудшают восприятие кода, согласен. Особенно когда взял какой-то проект и разбираешься в его архитектуре. Там местами настолько запутанно, что проще запустить и отрассировать его.
Ну или совсем прекрасно, если можно использовать сущности как глобальные переменные, которые попадут в секцию data или bss. Там все на этапе старта программы алоцируется
У меня реализация класса лежит в динамической библиотеке и экземпляр класса создается через фабрику, там на стеке не будет алокации. К тому же проблема стека в том, что его надо контролировать, чтобы он не переполнился. Если на то пошло и надо оптимизировать по вызову динамической алокации, лучше выделить один раз себе здоровенный кусок памяти и со смещением выдавать своим сущностям.
Я, кстати, ради интереса попробовал собрать с оптимизацией вызовы колбеков на разных компиляторах. И у меня gcc догадался подставить фиксированный адрес, а вот msvс нет (смотрел ассемблер). Хотя у меня msvc не последний. Я к тому что надежда на компиляторы есть)
Подсистема рендеринга это большой класс и архитектурно он в любом случае создавался бы через new. К тому же это делается один раз при инициализации. Алокация во время основного цикла работы программы, вот это плохо. Плюс, внутри этого класса тот же DirectX или Vulkan при инициализации своих сущностей вызывает огромное количество алокаций памяти.
Спасибо. Не знал. Вполне себе рабочий вариант. Но код с шаблонами на c++, по мне, выглядит не очень красиво.
Статья, конечно, шуточная. В своем проекте я всё же запилил виртуальные функции. А реализацию классов в отдельные динамические библиотеки, чтобы можно было заменить файл библиотеки, скажем, с DirectX на Vulkan и без перекомпиляции основного бинарника всё заработало.
Действительно в даташите на USB2642 указана поддержка MMC и отдельным пунктиком также указана поддержка eMMC. А вот USB2244i по даташиту поддерживает MMC и про eMMC ни слова. Хотя я ожидал протокольной совместимости между MMC и eMMC. Странно. Может конечно и не в этом дело. Спасибо, буду экспериментировать.
Есть идея железки процессор которой грузится с eMMC. Для прошивки eMMC хотелось бы использовать USB, который бы притворялся Mass Storage Device (преимущество — не надо писать свой драйвер). Вопрос здесь в микросхеме USB <-> eMMC bridge. Из таких микросхем нашёл только у SMSC (ныне Microchip), сам чип USB2244i. Вот он у нас почему-то не взлетел. Может партия была паленая, либо у нас руки не там. Может кто знает альтернативы этой микросхеме?
Отличная статья, спасибо.
Сам недавно обдумывал сделать себе кастомный джойстик. Поэтому вопрос. А почему используете обычный аналоговый стик, а не стик с датчиками холла? Дорого, сложно? У таких стиков лучше с дребезгом и долговечностью дела обстоят.
К примеру вот есть ребятки, которые предлагают подобные:
https://thegamingsetup.com/guides/hall-effect-joysticks
А что значит "спёрли"?
Если посмотреть на скриншоты двух приложений, то, справедливости ради, всё-таки иконки они нарисовали свои.
Код у них свой, к кодовой базе Adobe отношения не имеет.
Если вы подразумеваете под "спёрли" похожий дизайн. То я предполагаю, что это было сделано сознательно, смысл изобретать велосипед, это удобно, к тому же переход для пользователей на данное приложение будет идти быстрее. Тут, конечно, есть спорный момент, но учитывая, что они это написали сами, неплохо.
Пиар у отечественных продуктов слабоват. Сложно найти их среди зарубежных контор. Но, в частности, отечественный аналог фотошопа вполне себе разрабатывается и продается.
https://alivecolors.com/ru/index.php
А как же UNIGINE? Этот движок даже внесен в росреестр отечественного ПО. Или они хотят здоровой конкуренции, хотя больше похоже на другое)
По поводу FastPimpl в видео, хардкодить размер в хедере это первое что приходит в голову, это, конечно, на этапе компиляции проверяется, да и работает в итоге. Но как-то выглядит не очень. Спасибо за ссылку
Ну к слову C# крутой. Я на нем тестовые программки пишу, удобней чем С++. А местами, из-за JIT компиляции бывало, что он быстрее работал нежели программа на C++.
Самое интересное что все вопросы ясны, только вот некоторые термины были непонятные. Это как проходить интервью первый раз и пятый за долгое время. На первом интервью ты все по факту знаешь, но не знаешь многих терминов на английском, а к пятому ты уже синхронизировался и в теме)
Ну я скажу так, я разработчик низкоуровневого софта (драйвера под ОС, либо bare metal под embedded) и мой основной язык это С. По большей части никаких динамических алокаций, абстракций и прочего, что сожрет и так сильно ограниченные ресурсы. И проблема С++ в том, что его многие абстракции не годятся для производительности, они больше про удобство, хотя если не использовать все эти фичи, то разницы нет. И поэтому С++ развращает)
Согласен, я про препроцессор имел ввиду не надо будет писать #define
Я в комментарий выше написал, что это больше шуточная статья. Подмена сущности с сохранением интерфейса показалось мне забавным.
По поводу что быстрее, понятно, что каждое решение имеет свои плюсы и минусы. И надо понимать где и когда это применять.
Да не в этом идея) Идея изначальная была в том, чтобы в *.h файле для всех платформ не было различий и не было препроцессора. CRTP позволяет это сделать статически.
CRTP поможет поскольку скроет все платформозависимые типы в классе, который унаследован от шаблонного класса и который находится в платформозависимом файле *.cpp. Тут единственная проблема без оптимизации метод шаблонного класса будет вызывать аналогичный метод целевого класса, как прокси. Но при оптимизации оверхеда не будет. Но шаблоны это такое.
А вот то, что виртуальные методы ухудшают восприятие кода, согласен. Особенно когда взял какой-то проект и разбираешься в его архитектуре. Там местами настолько запутанно, что проще запустить и отрассировать его.
Ну или совсем прекрасно, если можно использовать сущности как глобальные переменные, которые попадут в секцию data или bss. Там все на этапе старта программы алоцируется
У меня реализация класса лежит в динамической библиотеке и экземпляр класса создается через фабрику, там на стеке не будет алокации. К тому же проблема стека в том, что его надо контролировать, чтобы он не переполнился. Если на то пошло и надо оптимизировать по вызову динамической алокации, лучше выделить один раз себе здоровенный кусок памяти и со смещением выдавать своим сущностям.
Я, кстати, ради интереса попробовал собрать с оптимизацией вызовы колбеков на разных компиляторах. И у меня gcc догадался подставить фиксированный адрес, а вот msvс нет (смотрел ассемблер). Хотя у меня msvc не последний. Я к тому что надежда на компиляторы есть)
Подсистема рендеринга это большой класс и архитектурно он в любом случае создавался бы через new. К тому же это делается один раз при инициализации. Алокация во время основного цикла работы программы, вот это плохо. Плюс, внутри этого класса тот же DirectX или Vulkan при инициализации своих сущностей вызывает огромное количество алокаций памяти.
Да, такой код в продакшн не годится)
Спасибо. Не знал. Вполне себе рабочий вариант. Но код с шаблонами на c++, по мне, выглядит не очень красиво.
Статья, конечно, шуточная. В своем проекте я всё же запилил виртуальные функции. А реализацию классов в отдельные динамические библиотеки, чтобы можно было заменить файл библиотеки, скажем, с DirectX на Vulkan и без перекомпиляции основного бинарника всё заработало.