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



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





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

Я что-то не очень уловил, где тут (в вашем с оппонентом обсуждении) полиморфизм проглядывает?

Ну да.... Я же забыл... (далее из википедии)


Как выразился кто-то в другой ветке - "Математическую абстракцию тестером не измерить" (там где было сказано и по-поводу - фраза весьма спорна, ну да не суть). Вот и я не могу понять, что есть "более абстрактные программы". Умом то я понимаю, что можно так извратиться, что выполнить



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

Скажете - плохо планировали структуру программы? А у вас всегда безошибочные планы? Не верю


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

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

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


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



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

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

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

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

Альтернатива - каждый проект имеет свой, полностью уникальный код. У меня 50 проектов. И 50 папок с полностью уникальным кодом. Если в рыбе, на базе которой был вручную создан весь этот уникальный код, обнаружилась ошибка, мне надо руками поправить все эти 50 проектов... А до этого мне пришлось 50 раз копи\пастить рыбу, править ее и проверять свои правки...



Почитайте что-нибудь типа "Искусства программирования" (к стыду своему забыл автора).
Там на эту тему очень подробно написано.
И посмотрите, в каком направлении движется индустрия - общие библиотеки, каркасы ...

Что касается мелких методов - так ведь есть встраивание и оптимизация компилятором.

Объем кода при использовании ООП и росте проекта сокращается ... Проверил на паре унаследованных проектов. Как сокращается и объем программы.

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



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

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



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



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



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

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




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

Мне кажется, что вы слишком напряжены. Прошу прощения, если ошибся. Как говорят "там" "take it easy". Я не ставлю себе целью кого-то на чем-то ловить и "ставить подножку".

Я про полиморфизм вот почему спросил. Тут на протяжении уже десятка постов постоянно звучит термин ООП. А ООП без полиморфизма не бывает. Вот я и не понял, где там ООП начинается. Классов и наследования тут (для ООП) недостаточно. Если полиморфизма нет, то и ООП нет, а есть только ОП, сиречь объектное программирование.

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

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


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

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

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


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


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


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

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



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

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

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

В последнее время, к сожалению, такое очень распространено на данном форуме. Вот поэтому я так и отписал. Сорри, что подумал, что вы на меня сейчас нападете



Безусловно. Просто на протяжении двух-трех десятков постов вижу такие фразы:






Но вижу только слова. Не вижу ни одного красивого примера, вызывающего чувство "Вот оно, ради этого стоит жить" Пример с фильтром не удовлетворил, такого класса код в каждом посте, агитирующем за цпп/ооп, прекрасно напишу на си и не буду выдумывать, что в какой класс положить, и как побольше разных ненужных фенечек прикрутить.

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



Ну и я могу так сделать. Когда мне понадобится. А, скорее всего, никогда не понадобится, и посему я обойдусь парой операторов, а не написанием функций и их вызовом.



Если вы немного посмотрели мой код, то наверное увидели, что меня меньше всего волнуют какие там прерывания от таймера. Есть флаг и все. Я получил управление (вышел из wait_int()), проверил его. А так как прерывание от таймера - суть вылет по таймауту, то больше мне тут делать нечего, и с флагом ошибки я вываливаюсь из функции. Зачем мне звать какой-то метод? ООП ради ООП? Вот против я этого.




Давайте обсудим.



И в чем же плюс? Старый вариант у меня останется в виде исходника проекта 1, из которого я сделаю ^C. Т.е. костыль будет в том исходнике проекта 2, в который я сделаю ^V и поработаю руками. Но в следующий проект я этот костыль не понесу, он останется в проекте 2.

Конечно, тут можно сказать, что это тоже способ наследования не средствами языка, а средствами редактора текстов. Я сторонник такого способа. Считаю, что он несет меньше оверхеда в проект.

Ну, это уже от вас зависит. На любой пример можно сказать, что он, де, фигня, не то, не цепляет, не удовлетоворяет и т.д. Апологеты асма тоже грят, что их все устраивает и никаих Сей они знать не желают. Это не в ваш огород камень, это к слову.


В том-то и дело, что не надо стараться делать лишь бы на классах. Надо просто стараться думать, моделировать свою программу в виде объектов. А классы уже - это просто удобное средство реализации, не более.


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

Обязательно почитайте Г.Буча.

Хочу отметить (просто мысли вслух причём чисто мои), анализируя дискуссию, что возможно на мои пристрастия и взгляды (а возможно и на взгляды Rst7) влияет то с чем мы работаем.
Приведу пример.

1) У меня в одном проекте есть 485 и несколько прерываний. Одно из них (регенерация изображения) невозможно прервать и сложно разбить. Время его исполнения такова, что я могу пропустить два байта на скорости 115200. Что для AVR равносильно "дырке в данных". В то время, как на LPC с его буфером FIFO мне это будет по барабану. Иными словами на ARM7 мне можно выписывать практически любой обработчик и не беспокоится об оверхеаде. На AVR - нет.

2) За всю мою историю мне не приходилось работать с 2 а тем более с 3/4/5 UARTами. Не было такой задачи.

Я это к тому, что применение более мощных процессоров и более развитой переферии возможно подтолкнёт к принятию концепции ООП.

Ну а применение более мощных процов будет обязательно. От этого никуда не денешься вне зависимости от наших желаний. Снижение цены 32-ух битников с более мощной переферией и более серьёзными ресурсами, приведёт к сворачиванию 8-ми битников. Это только вопрос времени.

Каждому овощу свое время (поговорка).
А е сли время еще не пришло ?

to rst7
позволю себе резюмировать нашу дискуссию.
Ваши аргументы
1. Код на С более компактен, чем код на С++ с использованием ООП
2. В каждом своем проекте вы имеете оригинальный код, который получили копипастом из предыдущего проекта и который можете совершенно независимо менять.
3. У вас нет никакого оверхеда ни по памяти ни по скорости. За счет прямого использования железно-зависимых вещей ваш код работает максимально быстро и не требует дополнительных переменных.
Итого: ООП-возможности С++ для вас бесполезны.

Мои аргументы:
1. Большой код на С++ с использованием ООП более компактен, чем на С
2. В каждом проекте я использую один и тот же код без изменений. Все мои проекты опираются на общую библиотеку (каркас) объектов. А это существенно сокращает время написания проекта.
3. За счет того, что надо выделять общую часть, у меня автоматически выделяется слой взаимодействия с железом; в общем коде отсутствуют обращения к регистрам процессора. Таким образом, переход на другой процессор проходит максимально безболезненно.
Итого: ООП-возможности С++ мне нужны.

Дальнейший спор на эту тему ИМХО бессмысленен; я не ставлю своей целью убедить вас использовать ООП. Вы не докажете мне преимуществ своего подхода .