вопрос в другом.
Разве в С++ есть for без ;; ?
for(int i=0) - так же нельзя или уже можно?

Сколько не читал битв "C vs C++", почему то противники С++ "заставляют" его использовать в самых "тяжелых" проявлениях - RTTI, виртуальные функции (хотя они не тяжелые).
С++ можно использовать только за более жесткий контроль типов. И все.
Потом понять, что ссылки - это удобно и код становится чище.
Потом начать применять приведение типов static_cast(безопасное) и reinterpret_cast(опасное, на усмотрение программиста) вместо С-ного приведения типа (uint32_t *)var. Представьте, как легко найти в коде места, где вы приводите типы рискованно и которые надо проверить в случае ошибки.
Потом понять, что конструктор - это удобно. И их можно использовать в структурах.
Пространства имен.
Все эти возможности несут нулевой оверхед и делают код удобнее и понятнее.


Это нововведение стандарта С++ за 2011 год - "range-based for".
Отлично описано в этой статье


А не нужно туда заглядывать.
Задач, где нужна оптимальность кода, не так много. Чаще пишется обычный, не критичный ко времени исполнения код, развесистая логика. Тут важнее читабельность исходников. И не только для автора.
Разговоры "я пишу один и мне все понятно" в пользу бедных.


Очень хотелось бы поверить. Но слишком много неизвестных - какой был компилятор (сейчас компиляторы совершенствуются), каков Ваш уровень мастерства как С++ программиста, каков уровень как С программиста, в каком конкретно месте была потеря скорости?

Вот пример, который привел Александр, хороший с точки зрения проверки С vs C++, т.к. хорошо переводится на С++.

Сообщение отредактировал Slash - Nov 28 2014, 16:31

неплохо... то есть вместо for(int i=0;i<n;i++) зафигачили трудночитаемую конструкцию, которая при этом еще работает через одно место множа вызовы.

Есть интересные нововведения 11 стандарта, но часть из них для борьбы с разросшимися шаблонами, и их не стоит применять для разработки железа. А именно этот пример читабельность не улучшает, и скорость не увеличивает... так что это ради понтов не более....


однако грустный момент, как соответствовать то? Стандарты выходят быстрее продуктов...



прикольно, я начинающий%).... я про авто не сном не духом, что-то в моих книжках про них авторы не упомянули



верно для компьютеров не верно для железа, все таки пока еще такты считаем, хочется чтобы схема и реагировала побыстрее и дел делала побольше.
Про читабельность, я пишу на С# и там часто использую foreach, но в данном конкретном случае этот аналог - for читабельность не увеличил, по мне даже уменьшил ссылками и прочим...

Компилятор - CCS, cgtools - довольно свежие. И дело не в компиляторе.
Плюсовой код порождал множественные вызовы функций, что страшное зло для DSP-циклов, плюс - как я понимаю из-за сложности для оптимизатора, он не мог правильно рассчитать кол-во проходов циклов, распараллелить обработку так как не мог просчитать зависимости переменных друг от друга и т.п.
Потеря была во всех критичных местах - фильтрах, обработках массивов сэмплов и т.д.. Остальные места меня не интересовали.


Мы вообще-то находимся в области embedded, где и размер кода и скорость его выполнения всегда будут важны, так как при улучшении этих показателей, позволяют впихнуть приложение в менее мощный, а значит - более дешёвый МК.

Разве как и где не взаимосвязаны? Очевидно, что данные сохраняются по указателю в структуре данных задачи. И это разжевывать не нужно.
Для "минимум коопертивной многозадачности" задача как раз таки вырождается в машину состояния. Для примера можно, например, посмотреть выход с препроцессора для protothreads



Непонятен смысл рефакторинга указателей. Мало того, что массив превращается в контейнер, так еще указатели превращаются в объекты с перегруженным operator []. Ради чего это сделано? Кто и кому будет кидать исключение для .at() на микроконтроллере? Или все это ради for на наборе? Как-то избыточно.

Чтобы внести конкретики. Зачем мне это надо и почему не RTOS: нужно написать библиотеку, которую можно будет помещать, в тело задачи, а можно просто в суперлупе. Не заталкивать же в библиотеку, RTOSину, если есть необходимость в многопоточности. Классическое решение, конечно, это автоматы состояний. Но по ходу обсуждений, выяснилось, что вариаций на эту тему, причем очень интересных в том числе, очень много. Я думал, и еще не совсем отказался от этой затеи - разбираюсь, попробовать отгрузку контекста таким же механизмом как в RTOS, но тогда возникают трудности с кроссплатформенностью. Но при этом все предложения в области автоматов мне тоже интересны, спасибо всем кто делится своим опытом на эту тему.

Кстати, в lwip решена ровно эта задача. Всё может работать без оси. Ось нужна только для sockets API, и то только потому, что это самое sockets API предполагает наличие оси.

На автоматах?

Да.