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

[SasaVitebsk]

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

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

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

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

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

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

Мой класс TCanal посылает запрос, ждет получения ответа определенное время, при отсутствии ответа повторяет запрос указанное кол-во раз и т.д. При этом получается отнюдь не цикл из трех строк, как вы привели...

При объектном подходе (не важно на С или на С++) мне надо сделать это ровно один раз, а потом использовать без изменений. При этом в одном проекте у меня может быть любое количество таких объектов.
Если не выделить эту функциональность в отдельные ф-ции + структуру С или класс С++, то максимум - у меня будет "рыба", которую я буду копи\пастить на N проектов и в рамках проекта на M уартов - в результате получится целая куча примерно одинакового кода, при адаптации которого я всякий раз должен буду вспоминать как он работает.
Еще вариант - написать по такой "рыбе" соответствующие макросы и поиметь кучу нюансов, с ними связанных.
Однако макросы будут довольно сложными (если учесть требование нескольких обработчиков в рамках проекта) + это фактически "скрытая" генерация дополнительного кода. Так не проще ли использовать классы в С++ или эмулировать их структурами + функциями в С?
При этом всего два недостатка:
1. Надо тщательно продумать и разработать эту общую функциональность
2. Некоторая потеря в скорости по сравнению с копи\пастом \ макросами. Однако если учесть, что скорость по УАРТу обычно не слишком высокая, то этими потерями в десятков\сотен тактов вполне можно пренебречь.

[Rst7]

Мой класс TCanal посылает запрос, ждет получения ответа определенное время, при отсутствии ответа повторяет запрос указанное кол-во раз и т.д. При этом получается отнюдь не цикл из трех строк, как вы привели...

Из пяти. Во внешней функции, напрмер так (хотя у меня совсем по другому, там не сразу повторяется запрос, а на следующем круге)

Код

char r=3;
do
{
c=DO_RS(&PPKP,1,CurRS,abon);
if ((c!=4)||(c!=2)) break; //Ну или другое условие проверим
}
while(--c);

Или тут тоже проще написать кучу методов, повызывать их? Или все-таки почеловечески, пробуем 3 раза, если обмен свершился, прекращаем попытки?

При объектном подходе (не важно на С или на С++) мне надо сделать это ровно один раз, а потом использовать без изменений. При этом в одном проекте у меня может быть любое количество таких объектов.

Уменьшение писанины. С этим согласен.

Если не выделить эту функциональность в отдельные ф-ции + структуру С или класс С++, то максимум - у меня будет "рыба", которую я буду копи\пастить на N проектов и в рамках проекта на M уартов - в результате получится целая куча примерно одинакового кода, при адаптации которого я всякий раз должен буду вспоминать как он работает.

Мой опыт говорит, что всегда надо что-то точить. Не получается универсальности.

Еще вариант - написать по такой "рыбе" соответствующие макросы и поиметь кучу нюансов, с ними связанных.
Однако макросы будут довольно сложными (если учесть требование нескольких обработчиков в рамках проекта) + это фактически "скрытая" генерация дополнительного кода. Так не проще ли использовать классы в С++ или эмулировать их структурами + функциями в С?

Не доходит до меня. У меня есть код (приведенный выше), который я использую (конечно, внося изменения) во всех проектах. Что мне даст изготовление этого кода в соответствии с парадигмами цпп?

При этом всего два недостатка:
1. Надо тщательно продумать и разработать эту общую функциональность

На Си тоже надо. Не думаете ли вы, что я не думаю над своим софтом? Так что это не недостаток.

2. Некоторая потеря в скорости по сравнению с копи\пастом \ макросами. Однако если учесть, что скорость по УАРТу обычно не слишком высокая, то этими потерями в десятков\сотен тактов вполне можно пренебречь.

Далеко не всегда.

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

Или тут тоже проще написать кучу методов, повызывать их? Или все-таки почеловечески, пробуем 3 раза, если обмен свершился, прекращаем попытки?

Еще раз . У меня есть объект, который умеет передать запрос, получить ответ, повторить передачу при необходимости, сообщить об отсутствии ответа.
Чтобы его использовать в конкретном проекте, я пишу обработчики 3-х прерываний примерно по 3 строки в каждом + пару 3-х строчных функций, которые в(ы)ключают приемник\передатчик УАРТа.
Еще нужна ф-ция, которая выставляет флаг получения ответа - для его последующей обработки.

Класс TCanal (а точнее производные от него) используется в других классах, которые содержит логику управления внешними устройствами.

Преимущества моего TCanal перед несколькими вашими функциями:
1. Легко тиражировать - если у меня в устройстве 4 уарта, я просто создаю четыре объекта + пишу обвязку для каждого (элементарную). Для ваших функций мне потребуется руками растиражировать каждую используемую переменную (а это как минимум, указатель на буфер, длина, число повторов максимальное и текущее, время ожидания и т.д.) и каждую функцию.
2. Мне не надо вообще ничего менять в базовом классе при написании нового протокола. Мне надо просто написать производный класс, в котором будет подключаться обработчик полученных байт + сам этот обработчик.
3. У меня логика посылки\повтора посылки отделена от логики "выцепления" пакета из потока байт (начало\конец пакета, длина, crc и т.д.). У вас - нет. Если в новом протоколе формат пакетов будет другой, в вашем случае придется по живому резать весь код; в моем - просто написать новый обработчик.
4. Параметры - время ожидания, число повторов и т.д. задаются в одном месте. Их четко видно в коде и легко поменять на другие. У вас они вшиты в ваши функции.

Мой опыт говорит, что всегда надо что-то точить. Не получается универсальности.

Если написать грамотно (и потом раз несколько повторно переписать ), точить придется в производном классе, не меняя код в базовом. А возможно - вообще не придется, если предусмотреть соответствующие параметры.

Не доходит до меня. У меня есть код (приведенный выше), который я использую (конечно, внося изменения) во всех проектах. Что мне даст изготовление этого кода в соответствии с парадигмами цпп?

см выше.

На Си тоже надо. Не думаете ли вы, что я не думаю над своим софтом? Так что это не недостаток.

Думаете конечно. Но написать общий код обычно сложнее, чем для конкретной задачи.

Далеко не всегда.

Если критично быстродействие - есть встраивание ф-ций, шаблоны и т.д.

Программа понятна. Читабельна. Обозрима. Какой плюс мне даст переделка этого кода в соответствии с ООП? Как бы вы порекомендовали разложить это по классам/методам? Какой выигрыш я получу?

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

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