К знатокам, Локальные переменные. Опции

[SasaVitebsk]

Пишу достаточно простую прогу. Пытаюсь оптимизировать.

Столкнулся с одной бедой. Попробую описать.

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

Проблема в том, что я не могу ввести локальные переменные на два прерывания. Таким образом я ввожу статик. Но тогда во втором прерывании компилятор пытается сохранить значения. А мне это не надо ни капельки. Чтобы этого избежать я ввёл локальные переменные и во втором прерывании выполнил присваивание локальным статик. Код получился значительно компактнее, но всё равно выполняется никому не нужное присваивание. А это 6 указателей!

Теперь сам вопрос.
Могу ли я указать компилятору что можно разрушать переменные в данном прерывании. То есть что не надо их хранить. Или как это сделать. Надо типа переобъявить статические переменные локальными. Не знаю как выразится. Надеюсь поняли.

[Rst7]

3. У меня логика посылки\повтора посылки отделена от логики "выцепления" пакета из потока байт (начало\конец пакета, длина, crc и т.д.). У вас - нет. Если в новом протоколе формат пакетов будет другой, в вашем случае придется по живому резать весь код; в моем - просто написать новый обработчик.

У меня тоже отделена. Функция посылки пакета и приема (DO_RS) - одна, а вызов во внешнем цикле (RS_TRX), там и думаем, чего делать при ошибках. Пример реализации я написал выше. Что не так?

4. Параметры - время ожидания, число повторов и т.д. задаются в одном месте. Их четко видно в коде и легко поменять на другие. У вас они вшиты в ваши функции.

Нет проблем. Я делаю #define и все видно. Какие вопросы? Тоже легко поменять...

Лично мне удобнее организовывать код как несколько кирпичиков, которые можно складывать друг с другом в разных вариантах без переделки самих кирпичей, а только за счет "разного цемента" . Т.е., я написал такой кирпичик, отладил его в рамках какого-нибудь проекта, а затем без изменений (вообще!) использую в другом. За счет ООП я могу, имея один кирпич, несколькими строками кода наклепать несколько подобных. Постепенно я улучшаю кирпичи, при этом они автоматически улучшаются и в старых проектах после перекомпиляции (или старые проекты становятся полностью неработоспособными , но это уже проблема осторожного улучшения и использования системы контроля версий).

Слова. Именно такими словами тут попрекают тех, кто говорит - "мне не нужен С++". Хорошо, допустим, я в своей уверенности, что цпп - от лукавого, не прав. Я привел пример кода, расскажите, чем бы ооп украсило (или улучшило) данный код? Не забудьте рассмотреть проблему в контексте оптимальности выходного кода.

[Непомнящий Евген...]

У меня тоже отделена. Функция посылки пакета и приема (DO_RS) - одна, а вызов во внешнем цикле (RS_TRX), там и думаем, чего делать при ошибках. Пример реализации я написал выше. Что не так?

У вас ф-ция DO_RS намертво привязана к конкретному уарту, конкретному таймеру и конкретному формату пакетов. При изменении любой из составляющих, вам придется менять ф-цию DO_RS.

Если в программе два канала связи с внешними устройствами, вам потребуется ровно две функции DO_RS, даже если протокол одинаков. А если 4 - то 4 ф-ции. А если 8 ...

Нет проблем. Я делаю #define и все видно. Какие вопросы? Тоже легко поменять...

Опять же, если "каналов" несколько, то ...

Слова. Именно такими словами тут попрекают тех, кто говорит - "мне не нужен С++". Хорошо, допустим, я в своей уверенности, что цпп - от лукавого, не прав. Я привел пример кода, расскажите, чем бы ооп украсило (или улучшило) данный код? Не забудьте рассмотреть проблему в контексте оптимальности выходного кода.

Тут похоже религиозная война начинается
Чем украсило - уже рассказал в постах выше. Если переписать это с использованием ООП, то вы получаете легко тиражируемый (без изменений) код. А если у вас много протоколов, то суммарный объем написанного кода уменьшается, вместе с числом потенциальных ошибок.
Что касается оптимальности. Да, если использовать общий код, вы получите оверхед по сравнению со специализированным. Там, где этот оверхед принципиален, возможно от общего кода придется отказаться и переписать его руками для конкретного случая. Но таких мест в реальной программе крайне мало, и обычно связь с внешними устройствами по RS-485 (232) таким местом не является. Если используется сколь-нибудь длинная линия, то скорости там порядка 9600.

Вы напираете на "ненужность с++", но говорите фактически о ненужности ООП. Никто не мешает использовать ООП и на чистом С. Еще раз обращаю ваше внимание на winAPI. Не знаю, что в Линуксе, но подозреваю - что-то в этом духе...

[Rst7]

У вас ф-ция DO_RS намертво привязана к конкретному уарту, конкретному таймеру и конкретному формату пакетов. При изменении любой из составляющих, вам придется менять ф-цию DO_RS.

А вам - необходимый метод. Не забываем, что таймера тоже обычно разные. А если мы сделаем таймер програмный, то надо просто озаботиться, чтобы к нему был нормальный интерфейс (тут правда, вы можете подумать, что я заговорил словами, употребляемыми при ООП, однако это не так. Это ООП подхватило слово интефейс )

Если в программе два канала связи с внешними устройствами, вам потребуется ровно две функции DO_RS, даже если протокол одинаков. А если 4 - то 4 ф-ции. А если 8 ...
Опять же, если "каналов" несколько, то ...

Да и хрен с ними, с двумя. Все равно будет примерно одинаково, что класс с разными методами, что две функции. Да и в моем способе две функции будут меньше - потому что результирующий код работает с регистрами, а не с памятью для хранения переменных.

Если у меня будет много однотипных каналов, я переделаю этот код так, чтобы и рыбку съесть (т.е. будет одна функция) и остальное сделать (хоть 32)

Тут похоже религиозная война начинается

Нет. Напали на человека, что ему надо на плюсы переписывать, а я предложил посмотреть на алгоритм.

Чем украсило - уже рассказал в постах выше.
Если переписать это с использованием ООП, то вы получаете легко тиражируемый (без изменений) код. А если у вас много протоколов, то суммарный объем написанного кода уменьшается, вместе с числом потенциальных ошибок.
Что касается оптимальности. Да, если использовать общий код, вы получите оверхед по сравнению со специализированным. Там, где этот оверхед принципиален, возможно от общего кода придется отказаться и переписать его руками для конкретного случая. Но таких мест в реальной программе крайне мало, и обычно связь с внешними устройствами по RS-485 (232) таким местом не является. Если используется сколь-нибудь длинная линия, то скорости там порядка 9600.

Да зачем же носить с собой то, что не пригодится в других проектах...

Вы напираете на "ненужность с++", но говорите фактически о ненужности ООП. Никто не мешает использовать ООП и на чистом С. Еще раз обращаю ваше внимание на winAPI. Не знаю, что в Линуксе, но подозреваю - что-то в этом духе...

Скажем так, я против повального увлечения ООП. И особенно против высказываний класса "А вот на плюсах (ооп) будет круто, а на чистом си - это плохо, немодно, нет классов, я не могу код использовать в другом проекте, я не могу исправить две строчки/дефайна" и т.д.

И просьба. Не надо говорить, что я не делал больших проектов, или мал опыт, или... Ну вообщем, давайте не будем приводить аргументы этого класса.

Вы на какой вопрос отвечаете? Я спросил не "что такое полиморфизм", это я знаю и без википедии. Я спросил, где в обсуждаемом вами с оппонентом примере просматривается оный полиморфизм?

Не просматривается. Однако, предвидя один из возможных дальнейших ходов беседы (вот полиморфизм - это да!) ответил в воздух. Извините, поспешил. Могу ли я узнать, будет ли поворот в сторону обсуждения данной проблемы? Если да, то, может быть вы прокомментируете мой ответ (или скажем так, позицию).

[Непомнящий Евген...]

А вам - необходимый метод. Не забываем, что таймера тоже обычно разные. А если мы сделаем таймер програмный, то надо просто озаботиться, чтобы к нему был нормальный интерфейс (тут правда, вы можете подумать, что я заговорил словами, употребляемыми при ООП, однако это не так. Это ООП подхватило слово интефейс )

А вот тут вы не правы. Мне надо будет написать внешнюю функцию, которая будет включать и выключать этот таймер. А в прерывании таймера дернуть метод объекта TCanal.
Ф-ция включения и выключения таймера же состоит всего из пары строк и ее написание не сравнимо с копированием всего DO_RS и выкусыванием всех обращений к таймеру. А если таймеры не симметричные - типа 0 и 1/3 в Атмеге128, то геморроя прибавится.

Да и хрен с ними, с двумя. Все равно будет примерно одинаково, что класс с разными методами, что две функции.

Еще раз. Класс TCanalXXX у меня не меняется вообще никогда. Почему? Потому что он использует таймер, вызывая две функции, которые реализует "цемент" - а именно -
ext_startTimer(byte timerID, uint interval)
ext_stopTimer(byte timerID)
УАРТ он использует, также вызывая внешние функции.
При добавлении нового экземпляра канала, мне надо добавить вполне конкретный маленький кусочек кода в каждую из этих внешних функций. И все.

Да и в моем способе две функции будут меньше - потому что результирующий код работает с регистрами, а не с памятью для хранения переменных.

Да. Более того, ваш код быстрее. В нем таймер включается непосредственно, а не вызовом внешней функции. В данном случае, имхо, этот оверхед не принципиален. Если он будет принципиален - я воспользуюсь шаблоном или макросом.

Если у меня будет много однотипных каналов, я переделаю этот код так, чтобы и рыбку съесть (т.е. будет одна функция) и остальное сделать (хоть 32)

Ну это и будет ООП в чистом виде. Вы сложите все, что касается канала в структуру и будете передавать всем функциям либо указатель, либо ее номер в некотором глобальном массиве.
Вопрос: почему не сделать так сразу?

Да зачем же носить с собой то, что не пригодится в других проектах...

А кто знает, что понадобится, а что не понадобится. Не хотите оверхеда - настраивайте директивами препроцессора...

Скажем так, я против повального увлечения ООП. И особенно против высказываний класса "А вот на плюсах (ооп) будет круто, а на чистом си - это плохо, немодно, нет классов, я не могу код использовать в другом проекте, я не могу исправить две строчки/дефайна" и т.д.

ООП надо использовать разумно и там, где нужно (как и все остальное ). Местами он сильно облегчает жизнь.

И просьба. Не надо говорить, что я не делал больших проектов, или мал опыт, или... Ну вообщем, давайте не будем приводить аргументы этого класса.

Да я вроде ничего такого не утверждал... Или это тоже "в воздух"?

Не просматривается. Однако, предвидя один из возможных дальнейших ходов беседы (вот полиморфизм - это да!) ответил в воздух. Извините, поспешил. Могу ли я узнать, будет ли поворот в сторону обсуждения данной проблемы? Если да, то, может быть вы прокомментируете мой ответ (или скажем так, позицию).

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

Кстати, тождество С++ === ООП совсем не верно. С++ - язык гибридный, мультипарадигменный, как его называют. Т.е. в нем вполне гармонично уживаются и процедурная, и объектная, и объектно-ориентированная парадигмы. Всякая из них к своему месту.

Насчет гармоничности - я на delphikingdom иногда захожу - так там это смешение парадигм называют скорее свалкой и считают это большим минусом C++ по сравнению с паскалем\дельфи. Впрочем, это уже наверное злостный офтоп.

[dxp]

Насчет гармоничности - я на delphikingdom иногда захожу - так там это смешение парадигм называют скорее свалкой и считают это большим минусом C++ по сравнению с паскалем\дельфи.

А чем им еще своего главного "конкурента" уделать? Только свалкой и обозвать. На самом деле, мультипарадигменность - неотъемлемое качество ЯП, если он претендует на звание языка общего назначения, т.е. достаточно универсального для решения широкого круга задач. Поскольку круг широк, то и инструментов в арсенале должно быть адекватно.

И в этом смысле делфа ничем особым от С++ не отличается - в ней тоже уживаются все эти три парадигмы. Она с С++ имеет гораздо больше общего, чем со своим прародителем - ЯП Паскаль. От него у нее только синтаксис.