Чтобы понять, нужно ли вообще заменять vector из STL на что-то другое, нужно профилировать программу и посмотреть, какие куски исполняются дольше всего. А то можно ускорить в 10 раз то, что исполняется 1% времени, и толку никакого не будет.
Выше давали совет распараллелить код и исполнять его в нескольких потоках одновременно - ИМХО, вот это может действительно серьезно ускорить программу.
Была компания Ntonyx, которая больше 20 лет разрабатывала программы для "очеловечивания" исполнения MIDI-композиций. Эти программы изменяют композиции, чтобы они при воспроизведении звучали так, как бы их играл живой музыкант (добавляют микро-ускорения/замедления, изменяет громкости нот и т.д.). В них вложено много труда и знаний людей с, в том числе, высшим музыкальным образованием (это не реклама, и я в ней не работал, просто знаю про них).
Даже их софт не всегда хорошо имитирует исполнение живым человеком, т.к. задача в самом деле непростая. А здесь, надо же - всего лишь нажимай кнопку в нужные моменты, и ты уже дирижёр! :-) И весь код программы всего в несколько экранов уместился (хоть бы под спойлер его убрали, если не хочется выкладывать куда-нибудь).
constfloat HZS[]
Вместо таблицы можно частоту нот рассчитать небольшой процедурой в начале программы. А то и прямо в коде считать в строке:
f_sub = HZS[baseIdx - 12]
Чуть выше же не боитесь использовать функцию возведения в степень powf, вряд ли на современных процессорах скорость её вычисления как-то повлияет на работу программы.
Тут ещё и написано всё на "голом" Windows API. ИМХО, удобнее было бы использовать какие-нибудь библиотеки вроде MFC и Visual Studio (бывают и бесплатные версии, если волнует вопрос с лицензией). Какой бы древней MFC ни была, она все-таки значительно сокращает количество кода при написании Windows-приложений с графическим интерфейсом. Вручную создавать окна и обрабатывать сообщения в WndProc - можно, но зачем? ;-)
у всех производителей клавишных инструментов типа синтезаторов или MIDI-клавиатур дешевле всего котируются инструменты, у которых нет динамического нажатия на клавиши
Причем, реально оценивается скорость нажатия (velocity). Наверное, сейчас MIDI-клавиатур без такой функции уже и купить невозможно. А еще бывают клавиатуры с aftertouch. Который обычно используется не для "классического" исполнения на фортепиано, а для включения всяких дополнительных эффектов синтеза/обработки звука, насколько я знаю (если я ошибаюсь, поправьте меня).
ИМХО, как раз впрок купить на каком-нибудь маркетплейсе штук 20 батареек жаба душит куда меньше, когда это стоит, как 4, а то и 2 батарейки на кассе любого офлайнового магазина. Я понимаю, что в офлайновом это могут быть какие-нибудь недешевые Duracell, а в маркетплейсе - noname, у которых емкость, возможно, меньше, но в пульте ДУ и то, и другое обычно год запросто проработает (зачастую - пока не вздуется или вытечет).
В конце концов, не могут все нововведённые фичи быть полезными и нужными абсолютно всем. Вспоминается, как был здесь один где-то с год назад, который пытался утверждать, что auto - зло, и всегда типы нужно писать явно. Даже пару статей опубликовал с подобными утверждениями, которые неслабо заминусовали.
У каждого свои представления о гармонии. Комитет руководствуется тем, чем люди пользуются, и в чем испытывают потребность. Возможно, это выглядит тупым с чьей-то точки зрения, но у каждого есть возможность самостоятельного выбора - пользоваться этим или нет.
Перестать беспокоиться о криворуких говнокодерах. Не умеют в nullptr, delete, array index out of bounds, etc - пускай на Бейсике пишут
То есть, RAII тоже выпилить, заодно со smart pointers? ;-)
В общем, не впихивать в более менее стабильное ядро языка лишние протоны и нейтроны
Вроде под Ваши требования подходит C++11/14. Можно в опциях компилятора включить ограничение, что он не поддерживает всё, что новее (C++17 и далее) - profit?
Читал недавно про сеть магазинов LIDL - они на своих товарах штрих-коды с двух сторон на упаковке наносят, чтобы максимально ускорить "пропикивание" на кассе. Кассиры и так там пробивают товар, как угорелые, так им еще и не надо задумываться о поиске штрих кода - какой стороной товар ни схвати, код сразу под рукой будет.
ИМХО, здесь вообще все можно на видеокарте делать. И в ней тоже есть распараллеливание.
Зря поставили минус, ИМХО. Вдруг это намек на анекдот про "у меня стартап, я пока один работаю" ;-)
Чтобы понять, нужно ли вообще заменять vector из STL на что-то другое, нужно профилировать программу и посмотреть, какие куски исполняются дольше всего. А то можно ускорить в 10 раз то, что исполняется 1% времени, и толку никакого не будет.
Выше давали совет распараллелить код и исполнять его в нескольких потоках одновременно - ИМХО, вот это может действительно серьезно ускорить программу.
Была компания Ntonyx, которая больше 20 лет разрабатывала программы для "очеловечивания" исполнения MIDI-композиций. Эти программы изменяют композиции, чтобы они при воспроизведении звучали так, как бы их играл живой музыкант (добавляют микро-ускорения/замедления, изменяет громкости нот и т.д.). В них вложено много труда и знаний людей с, в том числе, высшим музыкальным образованием (это не реклама, и я в ней не работал, просто знаю про них).
Даже их софт не всегда хорошо имитирует исполнение живым человеком, т.к. задача в самом деле непростая. А здесь, надо же - всего лишь нажимай кнопку в нужные моменты, и ты уже дирижёр! :-) И весь код программы всего в несколько экранов уместился (хоть бы под спойлер его убрали, если не хочется выкладывать куда-нибудь).
constfloatHZS[]Вместо таблицы можно частоту нот рассчитать небольшой процедурой в начале программы. А то и прямо в коде считать в строке:
f_sub = HZS[baseIdx - 12]Чуть выше же не боитесь использовать функцию возведения в степень
powf, вряд ли на современных процессорах скорость её вычисления как-то повлияет на работу программы.Тут ещё и написано всё на "голом" Windows API. ИМХО, удобнее было бы использовать какие-нибудь библиотеки вроде MFC и Visual Studio (бывают и бесплатные версии, если волнует вопрос с лицензией). Какой бы древней MFC ни была, она все-таки значительно сокращает количество кода при написании Windows-приложений с графическим интерфейсом. Вручную создавать окна и обрабатывать сообщения в
WndProc- можно, но зачем? ;-)Причем, реально оценивается скорость нажатия (velocity). Наверное, сейчас MIDI-клавиатур без такой функции уже и купить невозможно. А еще бывают клавиатуры с aftertouch. Который обычно используется не для "классического" исполнения на фортепиано, а для включения всяких дополнительных эффектов синтеза/обработки звука, насколько я знаю (если я ошибаюсь, поправьте меня).
Да, тоже GP на Озоне брал не раз. Нормально по цене/качеству.
ИМХО, как раз впрок купить на каком-нибудь маркетплейсе штук 20 батареек жаба душит куда меньше, когда это стоит, как 4, а то и 2 батарейки на кассе любого офлайнового магазина. Я понимаю, что в офлайновом это могут быть какие-нибудь недешевые Duracell, а в маркетплейсе - noname, у которых емкость, возможно, меньше, но в пульте ДУ и то, и другое обычно год запросто проработает (зачастую - пока не вздуется или вытечет).
Напоминает отзыв на маркетплейсе: товар получил, но открою потом, оценка 5 ;-)
За что лямбды запрещены? Это же вообще C++11, даже не 17.
Может, все-таки надевать? А то непонятно, где у брюк голова ;-)
Если правильно помню, можно написать decltype auto, тогда ссылка никуда не денется.
Что насчет auto в параметрах лямбда-функций?
Ещё давно в детском журнале было, даже с карикатурой: "ученик шёл к доске, исправляя двойку" :)
cppreference тоже не мгновенно обновляется.
В конце концов, не могут все нововведённые фичи быть полезными и нужными абсолютно всем. Вспоминается, как был здесь один где-то с год назад, который пытался утверждать, что auto - зло, и всегда типы нужно писать явно. Даже пару статей опубликовал с подобными утверждениями, которые неслабо заминусовали.
Разве?
Data-parallel types (SIMD) (since C++26) - cppreference.com
std::simd: шаблоны векторизации без intrinsics в C++ / Хабр
У каждого свои представления о гармонии. Комитет руководствуется тем, чем люди пользуются, и в чем испытывают потребность. Возможно, это выглядит тупым с чьей-то точки зрения, но у каждого есть возможность самостоятельного выбора - пользоваться этим или нет.
То есть, RAII тоже выпилить, заодно со smart pointers? ;-)
Вроде под Ваши требования подходит C++11/14. Можно в опциях компилятора включить ограничение, что он не поддерживает всё, что новее (C++17 и далее) - profit?
Читал недавно про сеть магазинов LIDL - они на своих товарах штрих-коды с двух сторон на упаковке наносят, чтобы максимально ускорить "пропикивание" на кассе. Кассиры и так там пробивают товар, как угорелые, так им еще и не надо задумываться о поиске штрих кода - какой стороной товар ни схвати, код сразу под рукой будет.