Ребята, Вы напрасно ржете. Таких задач как эта вагон и маленькая тележка. )))
зачем тебе вагон и маленькая тележка? - с этого момента у тебя любой девайс будет называться "универсальное устройство в режиме вагона и маленькой тележки".
Не думаю, уважаемый. Вы даже не в курсе в какой отрасли я работаю и для чего подобное устройство может понадобиться. Не надо думать, что Вы директор Мира и все на свете знаете. "Если к вам не прижимаются в метро, милочка, это не значит, что метро в Париже нет."
Узко, мыслите, Уважаемый. Не познать Вам всю глубину наших глубин). А если серьезно. Проект действительно специфичен. Признаю. Но опять же , если Вы не знаете о существовании каких-то вещей (причем весьма длительном) это не значит, что их не существует. А соответсвенно не дает Вам право ржать и называть меня ламером. А вот универсальное устройство в режиме вагона и маленькой тележки это да. Это было круто. )))
Ребята, Вы напрасно ржете. Таких задач как эта вагон и маленькая тележка. )))
Не берите в голову, пускай ржут - смех жизнь продлевает, Вам жалко, что-ли? Чего и как делать (или не делать - оставить IF'ы) я Вам написал в посте №184. Сам бы я делал через классы, но это мнее эффективно, чем Ваши IF'ы. Зато более прозрачно, понятно и, я бы сказал, системно.
как здесь обойтись без ВЫБОРА "Затем, определив тип датчика, просто создавал бы переменную нужного класса..." ?
Никак. Выбор при любом подходе будет. Хотя бы в определении типа датчика - это тоже выбор. А дальше уже можно либо по индексу (как я писал), либо опять же выбором.
Суть решения с классами - не избавиться от выбора, и избавиться от нобходимости понмить об этом выборе после того, как он сделан. Т.е., смотрите "датчикозваисимые действия" во всех 10 классах собраны в один метод. И метод этот одинаково называется во всех 10 классах. Значит, после создания экземпляра класса мы можем напрочь забыть о проблеме типа датчика. просто вызвать метод, а он сделат что нужно для выбранного датчика. Т.е. программа после создания экземпляра класса вообще никак не заязана на тип датичка.
не по-нят-но :(
пусть алгоритм обработки каждого датчика уникален и нельзя в нём через ифы что-то объединить....
определение типа датчика , вызов подпрограммы под него ( о типе датчика можно же забыть ? ) ( устройство должно знать все типы датчиков и подпрограммы для них ) = код А
определение типа датчика , создания экземпляра класса под этот датчик , вызвать метод его обработки ( метод должен знать все типы датчиков и подпрограммы для них ) = код В
в чём разница А и В ?
скорость , объём кода ?
видимо , без примеров мне не понять :(
в чём разница А и В ?
скорость , объём кода ?
видимо , без примеров мне не понять :(
спасибо :)
Разница в парадигме: процедурно ориентированая или ООП. У А несколько более путаный код. У В логическая стройность при немного, порядка 5% худших скоростях и обемах. В первом приближении - как набор переменных у А и структура длятех же переменных у В.
И чисто AVR-овская фича - криво реализовано виртуальное наследование в виде неоправданного расхода RAM, подробней - ищите ссылку на хабру в теме пару страниц назад, я выкладывал. Потому В проигрывает там где не ждали.
Logik , извини , не понятно.... У А несколько более путаный код.
в чём ? напишем 10 подпрограмм НЕ ПУТАННО , под каждый тип датчика....
У В логическая стройность при немного, порядка 5% худших скоростях и обемах. В первом приближении - как набор переменных у А и структура для тех же переменных у В. ...опять непонятно
Logik , извини , не понятно.... У А несколько более путаный код.
в чём ? напишем 10 подпрограмм НЕ ПУТАННО , под каждый тип датчика....
Путаным останится их применение. Ведь они формально никак не связаны, связь тока логическая в голове автора. А это не очевидно даже самому автору будет через год после написания. В ООП они связаны наследованием от базового класса. А вобще это правильно что непонятно. Смена парадигмы - всегда ломка в голове.
ПС. Холивар "ооп vs процедурное" один из старейших и заслуженых. Сказать чего нового в нем низя.
Logik , ООП в дельфях умею - зачем это на МК делать ? А это не очевидно даже самому автору будет через год после написания.
...а в ООП - всё на подкорку запишется ?
нееее , не холливар... оценка того и етого подхода....
Запишется в код в виде наследования, они будут наследоватся от одного предка и это явно определено в их описании.
Это вобще один из известных случаев когда ООП оправдан - наличие нескольких сущностей одинакового логического предназначения (обслуживание датчиков) при различной реализации (датчики разные).
Это вобще один из известных случаев когда ООП оправдан - наличие нескольких сущностей одинакового логического предназначения (обслуживание датчиков) при различной реализации (датчики разные).
чем оправдан ? красотой кода ?
класс - один , дочерей - 10....
датчик - один , подпрограмм- 10....
Нет, одинаковостью кода. Если я делаю процедурно, я должен "всю оставшуюся жизнь" вызывать правильную функцию. Про ООП подходе - функция вызывается одна и та же (на вид, по имени и т.п.), только делает она для разных датчиков разные вещи. Пример я могу сделать, но не сегодня, есл надо - завтра или в понедельник сделаю.
"всю оставшуюся жизнь" вызывать правильную функцию - будет селектор в лупе... только делает она для разных датчиков разные вещи как и выбранная подпрограмма в лупе ? Пример я могу сделать, но не сегодня, если надо - завтра или в понедельник сделаю. было бы классно , но...
...хоть и после НГ , зачем время предновогоднее тратить ?
Seva1800, если вам необходимо иметь код всех датчиков и на этапе setup(), а впрочем совсем не важно тогда где по коду, динамически определять тип датчика, то избежать выбора типа датчика вам никак не удастся и тогда совершенно непонятно что Вы хотели "оптимизировать".
Есть 3 способа реализции таких дел, вам их все тут привели, впрочем вы про них и так явно знали.. какой из способов лучше?
Да все равно, особенно если в основе вашего кода лежит Wiring. Он, wiring, в любом случае "отожрет" как памяти, флеш так и скорости исполнения - значительно больше вашего кода и проверок типа датчика.
Или вас интересуют методы "элегентного чесания пяткой за ухом"? То есть как написать красявее? Тогда ваш путь ООП, виртуализация классов и полиморфизм.
Дочитал спор. Я его всегда отношу к решению вопроса "Заставь дурака Богу молиться - он и лоб расшибет".
В том плане, что каждое средство любого языка дано программисту не "красоты для", а исключительно для полезного применения. И "ООП" - в этом - не исключение. Хотя некоторым нравится переопределять и виртуализировать то, что такого подхода ни разу не требует .. дескать "а посмотрите как я могу", "а я ещё и так могу".. это я и называю "лоб расшибет".
Правильный прогер, всегда помнит о цене "языковой эквилибристики" и находит самый дешевые способы реализации. А написать красиво можно даже на ассемблере. Макровызовы и макроподстановки - вам в руки. Широкое применение ООП, там где оно не требуется по коду оправдано только И только в больших проектах, где без него проект рискует не завершиться никогда из-за объема и сложности задачи. Эта причина - никогда не была важной в решении задач программирования МИКРОКОНТРОЛЛЕРОВ.
То есть, все те, кто тут ратуют за применение ООП, виртуализаций, полиморфизма и прочих "плюшек" - суть занимаются регрессом в обучении новичков. Точка.
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
То есть, все те, кто тут ратуют за применение ООП, виртуализаций, полиморфизма и прочих "плюшек" - суть занимаются регрессом в обучении новичков. Точка.
Правильный прогер, всегда помнит о цене "языковой эквилибристики" и находит самый дешевые способы реализации.
В цену также включаются и время разработки, пригодность кода для сопровождения и развития, ошибкоустойчивость и др производные от понятности и структуированности кода. И ООП здесь мощный инструмент. Плюсы от его применения иногда сильно перекрывают избыточность в 5%. "Эквилибристики" и на макросах с инклудами бывает не менше. Может запретим?
Arhat109-2 пишет:
Широкое применение ООП, там где оно не требуется по коду оправдано
так а кто сэтим спорит?! Любой инструмент должен применятся там где требуется. И задача с кучей датчиков, как раз пример под ООП.
Arhat109-2 пишет:
проект рискует не завершиться никогда из-за объема и сложности задачи. Эта причина - никогда не была важной в решении задач программирования МИКРОКОНТРОЛЛЕРОВ.
Устаревшие представления. Из эпохи когда контроллеры стояли огого а ЗП у програмеров были тю-тю. Тогда да НИИ мог дружно год оптимизировать сотню байт чтоб в 51-й влезть. Сейчас берут контроллер с большей памятю. Так просто дешевле. Следите за трендами, они не стабильны. В некоторые контроллеры сечас запихивают сложные задачи.
Arhat109-2 пишет:
То есть, все те, кто тут ратуют за применение ООП, виртуализаций, полиморфизма и прочих "плюшек" - суть занимаются регрессом в обучении новичков. Точка.
Нет шоб обяснить где какой подход уместен. А мне goto не нравится. Он ничего не расчитывает, значит бесполезный "изврат". Точка.
Может хватит догматизировать личные фобии? Каждому инструменты - свое применение согласно назначению, и ООП не исключение.
Arhat109-2 пишет:
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
Поржал. Спасибо хоть не разжаловать в тестировщики.
Правильный прогер, всегда помнит о цене "языковой эквилибристики" и находит самый дешевые способы реализации.[/quote]В цену также включаются и время разработки, пригодность кода для сопровождения и развития, ошибкоустойчивость и др производные от понятности и структуированности кода. И ООП здесь мощный инструмент. ..
Конечно так и заметьте вовсе НЕ исключает цитированного Вами. :)
Квалификация прогера как раз в том и заключается, чтобы применить самый дешевый спосб реализации самым понятным образом (исключение ошибки) за малое время (скорость разработки).
Спасибо, господа. Не думал, что мой вопрос вызовет такой живой интерес. В общем и целом почти все понятно. Однако, интересно, а можно ли в качестве параметра для goto использовать изменяемый параметр? Бузусловные и условные переходы люблю со времен програмирования на ассемблере для процессора z80. Комп zx spectrum многие наверное помнят. В ассемблере такие переходы позволяют решить кучу проблем.
Так вот я собственно о чем. Делаю ОДНУ процедуру (функцию) обработки сигналов для всех датчиков. Одним из параметров входа является тип датчика type число от 0 до 9. В то же время заранее создан массив с метками, где порядковый номер метки соответстует датчику. В самой процедуре стоят эти метки после котрых идет алгоритм обсчета сигнала с каждого датчика и заканчивается каждый алгоритм ретом. Ну а вначале процедуры стоит что-то типа goto (senstype[type]). Вот тока мне не понятно существуют ли такие конструкции в языке. Таким образом, мы имеем только одну процедуру обработки сигналов для всех датчиком и при этом не будет множественных сравнений. При входе с параметром, например, type 9, произойдет прыжок на какую нить ветку zz9 , выполнятся расчеты и произойдет выход из процедуры... И не нужно будет делать отдельную процедуру обработки сигнала для каждого датчика.
Не. Я вроде хочу делать подстановки разных меток в goto. Короче чтоб у goto был изменяемый параметр соответсвенно и переходы в разные места. Не понятно тока понятно ли это будет компилятору.
Среди программистов высокоуровневых языков считается плохим тоном использование оператора goto, хотя в некоторых случаях он реально эффективен.
Справка из книги "Программирование на языке Си":
Оператор goto передает управление на оператор, помеченный меткой имя-метки. Помеченный оператор должен находиться в той же функции, что и оператор goto, а используемая метка должна быть уникальной, т.е. одно имя-метки не может быть использовано для разных операторов программы. Имя-метки - это идентификатор.
Эти микроконтроллеры не имеют команд вычисляемых переходов со смещением. То, что вы назвали "вычисляемым goto". Чем вам не нравится вариант, предложенный Logik? Таблица адресов функций и .. вычисляемый вызов функции по номеру датчика из этой таблицы адресов? Можно даже запихать в progmem и заставить компилятор сгенерить инструкции lpm и eicall вполне языковыми средствами. Даже мудрить не надо, все делается средствами C/C++ "на выбор".
На самом деле, в GNU C++ (который и используется в IDE) вычисляемый goto есть - не верьте тем. кто говорит, что нет. Можно присвоить метку переменной и делать переход по этой переменной.
Я противник такого программирования, но если Вам так уж приспичило - держите пример кода, только никому не говорите, что это я Вас научил :)
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
Архат, вот Вы написали бред, но написали его так уверенно и безапелляционно, что аж дух захватывает.
Хорошо, давайте рассмотрим пример. Буквально сейчас я готовил «новогоднее чудо» для внучки и мне понадобился такой девайс:
четыре розетки, каждая на своём твёрдотельном реле;
при каждой розетке есть двухцветный светодиод, который горит зелёным, когда в розетке нет напряжения и красным, когда есть;
управление дуальное - на борту имеется инфракрасный приёмник и радиоприёмник. Функции их задублированы. Служат они для включения/выключения розеток. Причём включать/выключать можно хоть по радио, хоть через инфракрасный ПДУ в любом порядке.
Девайс я сделал правда не на ардуино, а на голой 328-ой микросхеме, но разницы никакой – программировал в IDE и заливал из IDE через ICSP.
В программе всё сделано на классах: класс для работы с радиоприёмником, класс для работы с IR-приёмником, от них обоих наследуется класс для дуального управления. Класс для работы с двухцветным светодиодом, класс для работы с реле (светодиод – свойство этого класса), наконец класс, описывающий весь девайс в целом – дуально управляемый массив реле.
Это устройство сейчас стоит и отлично работает – включает, выключает и т.п.
А вот теперь скажите мне – у меня есть хорошо работающий девайс, так с какого перепугу, кому, а главное, зачем я должен доказывать «отсутствие удорожания кода»?
Кого вообще волнует сколько там используется памяти (кроме Вас, конечно).
Вот ответьте кому и зачем я должен доказывать, что отлично работающее устройство использует память эффективно или нет? Кому это интересно?
Не. Я вроде хочу делать подстановки разных меток в goto. Короче чтоб у goto был изменяемый параметр соответсвенно и переходы в разные места. Не понятно тока понятно ли это будет компилятору.
Ну, если правильно объясните - он парень понятливый :)
ЕвгенийП, "для себя" вы можете писать "хоть как" .. это никого ровным счетом не волнует. Сделали, работает? И ладно. Я тоже делаю и работает и что? И у меня Мега2560 со своими 256килами флеша .. а скетч объезда препятствий с вычислением "пролезу ли в эту дырку" .. 1400, ой .. байт. И тоже писан "левой задней ногой" .. и что? Кому это, интересно? И давайте, перестанем "хвастаться" достижениями .. вы почему-то все время провоцируете на это.
Разговор идет не о том, как шустро вы накидали код в классах или как компактно мне это удается без таковых .. речь про "лекции для начинающих". Вот таких как Вы, начиталось уже целое поколение Г(ениев) .. результа, что называется "на лице". Кругом, сплошь и рядом. И проблема в том, что как и вы, многие из них даже не догадываются, что писать можно И шустро И продуктивно с точки зрения потребляемых ресурсов. Этому надо учить начинающих, а не "эквилибристике". И программирование микроконтроллеров - как раз требовательно к такому подходу "в принципе". Только и всего.
Ну, тогда не пишите. "обязано сопровождаться", а то как-то бредово выглядит. У Вас вон универсальная библиотека и ту Вы умудряетесь без элементарного тестирования в публичный доступ выложить, а других учите кто что обязан в обычных, не универсальных кодах.
Ага... Таки работает подстановка в goto. ))).
Хорошо. А мне вот еще, что интересно. Я не силен в истории. А кто, когда, и почему решил, что и спользование таких вещей как goto в коде это плохой тон? Я то всегда думал, что грамотно закомментированный код может быть каким угодно. И все будет в порядке. Не посадят же разбираться с чужим кодом обезьяну из зоопарка. Все равно это будет человек с мозгом в голове и который разбирается в своем деле. )). Хм... Правда, тут опять "если хорошо закомментированный.." и все же хочется понять чем так плох goto.
И чего Вы стесняетесь, Евгений, ))) " никому не говорите, что это я вас научил". )) я ить хотел рассмотреть все варианты. Вы с Архатом мне их показали." Выбирай не хочу.". Тем более это не абстрактный проект. А весьма полезная вещь может родиться.
Ну в общем все процедуры я прописал для своего проекта с 10 датчиками не без Вашей помощи, Господа. Правда прифигел слегка, когда выяснилось, что библиотека работы со строчными LCD I2C не умеет выводить на экран числа в экспонициальной форме ( у меня большой диапазон от 10Е-12 до 10Е+6). Пришлось написать маленькую функцию, чтобы это стало возможным. Осталось собственно ядро. Вот тут я к Вам, господа еще вернусь. Т.к. какая-то каша началась в голове))) На контроллере решил сделать всего 2 кнопки и причем их действие влияющее на работу датчиков будет зависеть от типа подключенного датчика. Кажется, что все просто. Но не тут-то блин было (((
ЕвгенийП, зачем было забивать Seva1800 голову "возможностью косвенных переходов с goto"? Он же так ничего и не понял в том примере.
Спрашивают - отвкчаем. Проблема не в том, что он не понял, а в том, что не понял чего именно он не понял. Ничего, это полезно. Грабли по лбу - лучшая прокачка понималки. Сам регулярно пользую.
А, кстати, что в том примере искуственного? Нормально всё сработает, хоть с датчиками, хоть без, если написать правильно.
кто, когда, и почему решил, что и спользование таких вещей как goto в коде это плохой тон?
Вы затронули жутко срачную тему. Появление любого поста об этом способно вызвать холивар в котором утонет любой изначальный топик. Но в данной ветке изначальный топик давно уже почил, так что, извольте.
Были такие три замечательных мужика (впрочем, не «были», двое из них живы, и дай им Бог здоровья) Эдсгер Дейкстра, Чарльз Хоар и Никлаус Вирт. Надо заметить, что двое из троих (кроме Хоара) не были практическими программистами, но теоретиками были очень сильными. Они выдвинули концепцию «структурного программирования» (СП), которая основывается на том факте, что любую программу можно написать с использованием всего только четырёх программных конструкций: последовательность, ветвление, цикл и вызов подпрограммы. Сиё утверждение было строго математически доказано (смоделирована машина Тьюринга) и они стали активно продвигать эту концепцию. Как видите, goto в этой концепции просто нет.
После публикации идеи, она вызвала жуткий холивар. Линия фронта проходила в основном между теоретиками и восторженными студентами на стороне СП и заслуженными ветеранами – жителями компьютерных залов – на противоположной.
Практические программисты подшучивали. Например: «и чего они привязались к goto? Наверное, потому что это «слово из четырёх букв» (это как если по-русски сказать «слово из трёх букв»)» или «ну, ладно, от goto мы откажемся, но тогда надо подумать о введении оператора comefrom».
Однако, пока практические программисты писали программы, Вирт (университетский профессор) писал учебники и учебные планы. В итоге выросло уже несколько поколений программистов, которые считают слово goto неприличным (ну, четрёхбуквенное же!).
Вот, в кратце история такова.
Seva1800 пишет:
Вы с Архатом
Не надо нас рядом ставить! Он прогер, а я программист!
А это ещё один холиварный водораздел. Как видите, любое появление нас обоих в теме, приводит к холивару и это нормально.
ааа.. ну теперь понятно как goto попал в опалу. Значит можно наплевать на этот "плохой тон". Потому как я понимаю реальных причин его не использовать просто не существует. А традиции и стереотипы существуют везде. Хотя я всегда думал, что в области программирования как раз самое главное гибкость подхода. Однако, нет)) И тут то же самое, что и везде )).
Seva1800, Реальная причина его не использовать - да, только одна: его избыточность. И, как всякая избыточность должна быть устранена из программ. Зачастую, компилятор это сделает даже за вас и даже лучше вас. Но, его отсутствие в коде - повышает читаемость текста, по сути не влияя ни на что, а иногда повышает эту читабельность просто катастрофически. Перечитайте Дейкстру, оно актуально и по сей день.
А если "вобьете его себе в пальцы" - то сможете писать код, практически не требующий тестирований что называется "сразу набело". Очень помогает решать задачи за ограниченный период времени.
А если вобьете в пальцы ещё и Касьянова - то сможете писать сразу "набело" и оптимальный код, не требующий дальнейших оптимизаций .. с той же скоростью что и ООП. :)
А давайте продолжим давать советы новичкам (я вот как раз он). Есть функции возвращающие результат, а есть ничего не возвращающие. При этом невозвращающие могут менять любые глобальные переменные, т.е. фактически возвращают результат.
Зачем тогда применять функции с возвратом результата? Есть подозрение, что это как-то связано с использованием локальных переменных, но не уверен.
А давайте продолжим давать советы новичкам (я вот как раз он). Есть функции возвращающие результат, а есть ничего не возвращающие. При этом невозвращающие могут менять любые глобальные переменные, т.е. фактически возвращают результат.
Зачем тогда применять функции с возвратом результата? Есть подозрение, что это как-то связано с использованием локальных переменных, но не уверен.
ЕвгенийП , обещал следЭтюд на эту тему... я жду , блиииин , а ему спорят....
чем больше Этюдов - тем меньше Этюдов :(
Ребята, Вы напрасно ржете. Таких задач как эта вагон и маленькая тележка. )))
зачем тебе вагон и маленькая тележка? - с этого момента у тебя любой девайс будет называться "универсальное устройство в режиме вагона и маленькой тележки".
*пилите код, Шура! :D
Не думаю, уважаемый. Вы даже не в курсе в какой отрасли я работаю и для чего подобное устройство может понадобиться. Не надо думать, что Вы директор Мира и все на свете знаете. "Если к вам не прижимаются в метро, милочка, это не значит, что метро в Париже нет."
Узко, мыслите, Уважаемый. Не познать Вам всю глубину наших глубин). А если серьезно. Проект действительно специфичен. Признаю. Но опять же , если Вы не знаете о существовании каких-то вещей (причем весьма длительном) это не значит, что их не существует. А соответсвенно не дает Вам право ржать и называть меня ламером. А вот универсальное устройство в режиме вагона и маленькой тележки это да. Это было круто. )))
Ребята, Вы напрасно ржете. Таких задач как эта вагон и маленькая тележка. )))
Не берите в голову, пускай ржут - смех жизнь продлевает, Вам жалко, что-ли? Чего и как делать (или не делать - оставить IF'ы) я Вам написал в посте №184. Сам бы я делал через классы, но это мнее эффективно, чем Ваши IF'ы. Зато более прозрачно, понятно и, я бы сказал, системно.
ЕвгенийП , а как здесь обойтись без ВЫБОРА "Затем, определив тип датчика, просто создавал бы переменную нужного класса..." ?
как здесь обойтись без ВЫБОРА "Затем, определив тип датчика, просто создавал бы переменную нужного класса..." ?
Никак. Выбор при любом подходе будет. Хотя бы в определении типа датчика - это тоже выбор. А дальше уже можно либо по индексу (как я писал), либо опять же выбором.
Суть решения с классами - не избавиться от выбора, и избавиться от нобходимости понмить об этом выборе после того, как он сделан. Т.е., смотрите "датчикозваисимые действия" во всех 10 классах собраны в один метод. И метод этот одинаково называется во всех 10 классах. Значит, после создания экземпляра класса мы можем напрочь забыть о проблеме типа датчика. просто вызвать метод, а он сделат что нужно для выбранного датчика. Т.е. программа после создания экземпляра класса вообще никак не заязана на тип датичка.
не по-нят-но :(
пусть алгоритм обработки каждого датчика уникален и нельзя в нём через ифы что-то объединить....
определение типа датчика , вызов подпрограммы под него ( о типе датчика можно же забыть ? )
( устройство должно знать все типы датчиков и подпрограммы для них ) = код А
определение типа датчика , создания экземпляра класса под этот датчик , вызвать метод его обработки
( метод должен знать все типы датчиков и подпрограммы для них ) = код В
в чём разница А и В ?
скорость , объём кода ?
видимо , без примеров мне не понять :(
спасибо :)
в чём разница А и В ?
скорость , объём кода ?
видимо , без примеров мне не понять :(
спасибо :)
Разница в парадигме: процедурно ориентированая или ООП. У А несколько более путаный код. У В логическая стройность при немного, порядка 5% худших скоростях и обемах. В первом приближении - как набор переменных у А и структура длятех же переменных у В.
И чисто AVR-овская фича - криво реализовано виртуальное наследование в виде неоправданного расхода RAM, подробней - ищите ссылку на хабру в теме пару страниц назад, я выкладывал. Потому В проигрывает там где не ждали.
Logik , извини , не понятно....
У А несколько более путаный код.
в чём ? напишем 10 подпрограмм НЕ ПУТАННО , под каждый тип датчика....
У В логическая стройность при немного, порядка 5% худших скоростях и обемах. В первом приближении - как набор переменных у А и структура для тех же переменных у В.
...опять непонятно
я не спорю - мне не понятно :(
Logik , извини , не понятно....
У А несколько более путаный код.
в чём ? напишем 10 подпрограмм НЕ ПУТАННО , под каждый тип датчика....
Путаным останится их применение. Ведь они формально никак не связаны, связь тока логическая в голове автора. А это не очевидно даже самому автору будет через год после написания. В ООП они связаны наследованием от базового класса. А вобще это правильно что непонятно. Смена парадигмы - всегда ломка в голове.
ПС. Холивар "ооп vs процедурное" один из старейших и заслуженых. Сказать чего нового в нем низя.
Logik , ООП в дельфях умею - зачем это на МК делать ?
А это не очевидно даже самому автору будет через год после написания.
...а в ООП - всё на подкорку запишется ?
нееее , не холливар... оценка того и етого подхода....
Запишется в код в виде наследования, они будут наследоватся от одного предка и это явно определено в их описании.
Это вобще один из известных случаев когда ООП оправдан - наличие нескольких сущностей одинакового логического предназначения (обслуживание датчиков) при различной реализации (датчики разные).
Это вобще один из известных случаев когда ООП оправдан - наличие нескольких сущностей одинакового логического предназначения (обслуживание датчиков) при различной реализации (датчики разные).
чем оправдан ? красотой кода ?
класс - один , дочерей - 10....
датчик - один , подпрограмм- 10....
чем оправдан ? красотой кода ?
Нет, одинаковостью кода. Если я делаю процедурно, я должен "всю оставшуюся жизнь" вызывать правильную функцию. Про ООП подходе - функция вызывается одна и та же (на вид, по имени и т.п.), только делает она для разных датчиков разные вещи. Пример я могу сделать, но не сегодня, есл надо - завтра или в понедельник сделаю.
"всю оставшуюся жизнь" вызывать правильную функцию - будет селектор в лупе...
только делает она для разных датчиков разные вещи
как и выбранная подпрограмма в лупе ?
Пример я могу сделать, но не сегодня, если надо - завтра или в понедельник сделаю.
было бы классно , но...
...хоть и после НГ , зачем время предновогоднее тратить ?
спасибо ! :)
Seva1800, если вам необходимо иметь код всех датчиков и на этапе setup(), а впрочем совсем не важно тогда где по коду, динамически определять тип датчика, то избежать выбора типа датчика вам никак не удастся и тогда совершенно непонятно что Вы хотели "оптимизировать".
Есть 3 способа реализции таких дел, вам их все тут привели, впрочем вы про них и так явно знали.. какой из способов лучше?
Да все равно, особенно если в основе вашего кода лежит Wiring. Он, wiring, в любом случае "отожрет" как памяти, флеш так и скорости исполнения - значительно больше вашего кода и проверок типа датчика.
Или вас интересуют методы "элегентного чесания пяткой за ухом"? То есть как написать красявее? Тогда ваш путь ООП, виртуализация классов и полиморфизм.
Дочитал спор. Я его всегда отношу к решению вопроса "Заставь дурака Богу молиться - он и лоб расшибет".
В том плане, что каждое средство любого языка дано программисту не "красоты для", а исключительно для полезного применения. И "ООП" - в этом - не исключение. Хотя некоторым нравится переопределять и виртуализировать то, что такого подхода ни разу не требует .. дескать "а посмотрите как я могу", "а я ещё и так могу".. это я и называю "лоб расшибет".
Правильный прогер, всегда помнит о цене "языковой эквилибристики" и находит самый дешевые способы реализации. А написать красиво можно даже на ассемблере. Макровызовы и макроподстановки - вам в руки. Широкое применение ООП, там где оно не требуется по коду оправдано только И только в больших проектах, где без него проект рискует не завершиться никогда из-за объема и сложности задачи. Эта причина - никогда не была важной в решении задач программирования МИКРОКОНТРОЛЛЕРОВ.
То есть, все те, кто тут ратуют за применение ООП, виртуализаций, полиморфизма и прочих "плюшек" - суть занимаются регрессом в обучении новичков. Точка.
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
Это кто? Тот кто пишет правильные проги?
Правильный прогер, всегда помнит о цене "языковой эквилибристики" и находит самый дешевые способы реализации.
В цену также включаются и время разработки, пригодность кода для сопровождения и развития, ошибкоустойчивость и др производные от понятности и структуированности кода. И ООП здесь мощный инструмент. Плюсы от его применения иногда сильно перекрывают избыточность в 5%. "Эквилибристики" и на макросах с инклудами бывает не менше. Может запретим?
Широкое применение ООП, там где оно не требуется по коду оправдано
так а кто сэтим спорит?! Любой инструмент должен применятся там где требуется. И задача с кучей датчиков, как раз пример под ООП.
проект рискует не завершиться никогда из-за объема и сложности задачи. Эта причина - никогда не была важной в решении задач программирования МИКРОКОНТРОЛЛЕРОВ.
Устаревшие представления. Из эпохи когда контроллеры стояли огого а ЗП у програмеров были тю-тю. Тогда да НИИ мог дружно год оптимизировать сотню байт чтоб в 51-й влезть. Сейчас берут контроллер с большей памятю. Так просто дешевле. Следите за трендами, они не стабильны. В некоторые контроллеры сечас запихивают сложные задачи.
То есть, все те, кто тут ратуют за применение ООП, виртуализаций, полиморфизма и прочих "плюшек" - суть занимаются регрессом в обучении новичков. Точка.
Нет шоб обяснить где какой подход уместен. А мне goto не нравится. Он ничего не расчитывает, значит бесполезный "изврат". Точка.
Может хватит догматизировать личные фобии? Каждому инструменты - свое применение согласно назначению, и ООП не исключение.
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
Поржал. Спасибо хоть не разжаловать в тестировщики.
Конечно так и заметьте вовсе НЕ исключает цитированного Вами. :)
Квалификация прогера как раз в том и заключается, чтобы применить самый дешевый спосб реализации самым понятным образом (исключение ошибки) за малое время (скорость разработки).
А "мощность ООП" лежит в иной плоскости.
К выбору оптимального алгоритма - https://www.youtube.com/watch?feature=player_embedded&v=rQtereWDc24
Спасибо, господа. Не думал, что мой вопрос вызовет такой живой интерес. В общем и целом почти все понятно. Однако, интересно, а можно ли в качестве параметра для goto использовать изменяемый параметр? Бузусловные и условные переходы люблю со времен програмирования на ассемблере для процессора z80. Комп zx spectrum многие наверное помнят. В ассемблере такие переходы позволяют решить кучу проблем.
Так вот я собственно о чем. Делаю ОДНУ процедуру (функцию) обработки сигналов для всех датчиков. Одним из параметров входа является тип датчика type число от 0 до 9. В то же время заранее создан массив с метками, где порядковый номер метки соответстует датчику. В самой процедуре стоят эти метки после котрых идет алгоритм обсчета сигнала с каждого датчика и заканчивается каждый алгоритм ретом. Ну а вначале процедуры стоит что-то типа goto (senstype[type]). Вот тока мне не понятно существуют ли такие конструкции в языке. Таким образом, мы имеем только одну процедуру обработки сигналов для всех датчиком и при этом не будет множественных сравнений. При входе с параметром, например, type 9, произойдет прыжок на какую нить ветку zz9 , выполнятся расчеты и произойдет выход из процедуры... И не нужно будет делать отдельную процедуру обработки сигнала для каждого датчика.
Предположу: вычисляемый GOTO в Фортране.
Не. Я вроде хочу делать подстановки разных меток в goto. Короче чтоб у goto был изменяемый параметр соответсвенно и переходы в разные места. Не понятно тока понятно ли это будет компилятору.
а чем оно тогда от switch-case будет отличаться?
Среди программистов высокоуровневых языков считается плохим тоном использование оператора goto, хотя в некоторых случаях он реально эффективен.
Справка из книги "Программирование на языке Си":
Оператор goto передает управление на оператор, помеченный меткой имя-метки. Помеченный оператор должен находиться в той же функции, что и оператор goto, а используемая метка должна быть уникальной, т.е. одно имя-метки не может быть использовано для разных операторов программы. Имя-метки - это идентификатор.
Эти микроконтроллеры не имеют команд вычисляемых переходов со смещением. То, что вы назвали "вычисляемым goto". Чем вам не нравится вариант, предложенный Logik? Таблица адресов функций и .. вычисляемый вызов функции по номеру датчика из этой таблицы адресов? Можно даже запихать в progmem и заставить компилятор сгенерить инструкции lpm и eicall вполне языковыми средствами. Даже мудрить не надо, все делается средствами C/C++ "на выбор".
Да... Придется согласиться.
На самом деле, в GNU C++ (который и используется в IDE) вычисляемый goto есть - не верьте тем. кто говорит, что нет. Можно присвоить метку переменной и делать переход по этой переменной.
Я противник такого программирования, но если Вам так уж приспичило - держите пример кода, только никому не говорите, что это я Вас научил :)
void setup() { Serial.begin(115200); void * lab[] = {&&kaka, &&mumu, &&kuku}; const int totalLabels = sizeof(lab)/sizeof(lab[0]); int n = 0; beg: if (n == totalLabels) { void *finlabel = &&fin; goto *finlabel; } goto *lab[n++]; kaka: Serial.println("Kaka Label Area"); goto beg; mumu: Serial.println("Mumu Label Area"); goto beg; kuku: Serial.println("Kuku Label Area"); goto beg; fin: Serial.println("fin Label Area"); } void loop() { }Запустите, посмотрите, что печатает и постарайтесь понять как работает.
"Настоящий программист сумеет написать фортрановскую программу на любом языке!"
Среди программистов высокоуровневых языков считается плохим тоном использование оператора goto
Ну, как же? :))))
"Настоящий программист сумеет написать фортрановскую программу на любом языке" - см. http://www.lib.ru/ANEKDOTY/non_pas.txt
:))))))))))))))))))
Или всякое применение ООП в программировании МК добязано сопровождаться листингом, доказывающим отстуствие удорожания кода.
Архат, вот Вы написали бред, но написали его так уверенно и безапелляционно, что аж дух захватывает.
Хорошо, давайте рассмотрим пример. Буквально сейчас я готовил «новогоднее чудо» для внучки и мне понадобился такой девайс:
Девайс я сделал правда не на ардуино, а на голой 328-ой микросхеме, но разницы никакой – программировал в IDE и заливал из IDE через ICSP.
В программе всё сделано на классах: класс для работы с радиоприёмником, класс для работы с IR-приёмником, от них обоих наследуется класс для дуального управления. Класс для работы с двухцветным светодиодом, класс для работы с реле (светодиод – свойство этого класса), наконец класс, описывающий весь девайс в целом – дуально управляемый массив реле.
Основной скетч в итоге выглядит так:
#include <NECIRremote.h> #include <VirtualWire.h> #include "DualControlledRelaysArray.h" #define IR_PIN 1 // Пин инфракрасного датчика #define RX_PIN 9 // Пин радиоприёмника DualControlledRelaysArray dcra(RX_PIN, IR_PIN); void setup() { dcra.Init(); dcra.ledShow(); dcra.OnDuty(); } void loop() { dcra.processCommand(); }Это устройство сейчас стоит и отлично работает – включает, выключает и т.п.
А вот теперь скажите мне – у меня есть хорошо работающий девайс, так с какого перепугу, кому, а главное, зачем я должен доказывать «отсутствие удорожания кода»?
Кого вообще волнует сколько там используется памяти (кроме Вас, конечно).
Вот ответьте кому и зачем я должен доказывать, что отлично работающее устройство использует память эффективно или нет? Кому это интересно?
Ну, если правильно объясните - он парень понятливый :)
ЕвгенийП, "для себя" вы можете писать "хоть как" .. это никого ровным счетом не волнует. Сделали, работает? И ладно. Я тоже делаю и работает и что? И у меня Мега2560 со своими 256килами флеша .. а скетч объезда препятствий с вычислением "пролезу ли в эту дырку" .. 1400, ой .. байт. И тоже писан "левой задней ногой" .. и что? Кому это, интересно? И давайте, перестанем "хвастаться" достижениями .. вы почему-то все время провоцируете на это.
Разговор идет не о том, как шустро вы накидали код в классах или как компактно мне это удается без таковых .. речь про "лекции для начинающих". Вот таких как Вы, начиталось уже целое поколение Г(ениев) .. результа, что называется "на лице". Кругом, сплошь и рядом. И проблема в том, что как и вы, многие из них даже не догадываются, что писать можно И шустро И продуктивно с точки зрения потребляемых ресурсов. Этому надо учить начинающих, а не "эквилибристике". И программирование микроконтроллеров - как раз требовательно к такому подходу "в принципе". Только и всего.
Ну, тогда не пишите. "обязано сопровождаться", а то как-то бредово выглядит. У Вас вон универсальная библиотека и ту Вы умудряетесь без элементарного тестирования в публичный доступ выложить, а других учите кто что обязан в обычных, не универсальных кодах.
Ага... Таки работает подстановка в goto. ))).
Хорошо. А мне вот еще, что интересно. Я не силен в истории. А кто, когда, и почему решил, что и спользование таких вещей как goto в коде это плохой тон? Я то всегда думал, что грамотно закомментированный код может быть каким угодно. И все будет в порядке. Не посадят же разбираться с чужим кодом обезьяну из зоопарка. Все равно это будет человек с мозгом в голове и который разбирается в своем деле. )). Хм... Правда, тут опять "если хорошо закомментированный.." и все же хочется понять чем так плох goto.
И чего Вы стесняетесь, Евгений, ))) " никому не говорите, что это я вас научил". )) я ить хотел рассмотреть все варианты. Вы с Архатом мне их показали." Выбирай не хочу.". Тем более это не абстрактный проект. А весьма полезная вещь может родиться.
Ну в общем все процедуры я прописал для своего проекта с 10 датчиками не без Вашей помощи, Господа. Правда прифигел слегка, когда выяснилось, что библиотека работы со строчными LCD I2C не умеет выводить на экран числа в экспонициальной форме ( у меня большой диапазон от 10Е-12 до 10Е+6). Пришлось написать маленькую функцию, чтобы это стало возможным. Осталось собственно ядро. Вот тут я к Вам, господа еще вернусь. Т.к. какая-то каша началась в голове))) На контроллере решил сделать всего 2 кнопки и причем их действие влияющее на работу датчиков будет зависеть от типа подключенного датчика. Кажется, что все просто. Но не тут-то блин было (((
Подстановка в goto работает в специально сконструированном примере, в реальной ситуации с датчиками так не получится.
ЕвгенийП, зачем было забивать Seva1800 голову "возможностью косвенных переходов с goto"? Он же так ничего и не понял в том примере.
ЕвгенийП, зачем было забивать Seva1800 голову "возможностью косвенных переходов с goto"? Он же так ничего и не понял в том примере.
Спрашивают - отвкчаем. Проблема не в том, что он не понял, а в том, что не понял чего именно он не понял. Ничего, это полезно. Грабли по лбу - лучшая прокачка понималки. Сам регулярно пользую.
А, кстати, что в том примере искуственного? Нормально всё сработает, хоть с датчиками, хоть без, если написать правильно.
ЕвгенийП, зачем было забивать Seva1800 голову "возможностью косвенных переходов с goto"? Он же так ничего и не понял в том примере.
если не понял - поймёт....
не поймёт - тут ещё и другие читатели есть !
зачем управлять ЕвгенийП , это его тема на форуме.....
Ребят, Вы чего меня обижаете? )) понял, не понял... всё я понял. Можно подумать мы тут с Вами волновую функцию Шредингера обсуждаем.
кто, когда, и почему решил, что и спользование таких вещей как goto в коде это плохой тон?
Вы затронули жутко срачную тему. Появление любого поста об этом способно вызвать холивар в котором утонет любой изначальный топик. Но в данной ветке изначальный топик давно уже почил, так что, извольте.
Были такие три замечательных мужика (впрочем, не «были», двое из них живы, и дай им Бог здоровья) Эдсгер Дейкстра, Чарльз Хоар и Никлаус Вирт. Надо заметить, что двое из троих (кроме Хоара) не были практическими программистами, но теоретиками были очень сильными. Они выдвинули концепцию «структурного программирования» (СП), которая основывается на том факте, что любую программу можно написать с использованием всего только четырёх программных конструкций: последовательность, ветвление, цикл и вызов подпрограммы. Сиё утверждение было строго математически доказано (смоделирована машина Тьюринга) и они стали активно продвигать эту концепцию. Как видите, goto в этой концепции просто нет.
После публикации идеи, она вызвала жуткий холивар. Линия фронта проходила в основном между теоретиками и восторженными студентами на стороне СП и заслуженными ветеранами – жителями компьютерных залов – на противоположной.
Практические программисты подшучивали. Например: «и чего они привязались к goto? Наверное, потому что это «слово из четырёх букв» (это как если по-русски сказать «слово из трёх букв»)» или «ну, ладно, от goto мы откажемся, но тогда надо подумать о введении оператора comefrom».
Однако, пока практические программисты писали программы, Вирт (университетский профессор) писал учебники и учебные планы. В итоге выросло уже несколько поколений программистов, которые считают слово goto неприличным (ну, четрёхбуквенное же!).
Вот, в кратце история такова.
Ребят, Вы чего меня обижаете? )) понял, не понял... всё я понял. Можно подумать мы тут с Вами волновую функцию Шредингера обсуждаем.
Да никто Вас не обижает, не берите в голову (если обидел - извините, не хотел). Грабли прилетят - поймаете, это действительно полезно :)
Ребят, Вы чего меня обижаете? )) понял, не понял... всё я понял. Можно подумать мы тут с Вами волновую функцию Шредингера обсуждаем.
ТС может обидеть каждый... тенденция , однако....
:) :) :)
...не обращай внимания
ааа.. ну теперь понятно как goto попал в опалу. Значит можно наплевать на этот "плохой тон". Потому как я понимаю реальных причин его не использовать просто не существует. А традиции и стереотипы существуют везде. Хотя я всегда думал, что в области программирования как раз самое главное гибкость подхода. Однако, нет)) И тут то же самое, что и везде )).
Seva1800, Реальная причина его не использовать - да, только одна: его избыточность. И, как всякая избыточность должна быть устранена из программ. Зачастую, компилятор это сделает даже за вас и даже лучше вас. Но, его отсутствие в коде - повышает читаемость текста, по сути не влияя ни на что, а иногда повышает эту читабельность просто катастрофически. Перечитайте Дейкстру, оно актуально и по сей день.
А если "вобьете его себе в пальцы" - то сможете писать код, практически не требующий тестирований что называется "сразу набело". Очень помогает решать задачи за ограниченный период времени.
А если вобьете в пальцы ещё и Касьянова - то сможете писать сразу "набело" и оптимальный код, не требующий дальнейших оптимизаций .. с той же скоростью что и ООП. :)
А давайте продолжим давать советы новичкам (я вот как раз он). Есть функции возвращающие результат, а есть ничего не возвращающие. При этом невозвращающие могут менять любые глобальные переменные, т.е. фактически возвращают результат.
Зачем тогда применять функции с возвратом результата? Есть подозрение, что это как-то связано с использованием локальных переменных, но не уверен.
А давайте продолжим давать советы новичкам (я вот как раз он). Есть функции возвращающие результат, а есть ничего не возвращающие. При этом невозвращающие могут менять любые глобальные переменные, т.е. фактически возвращают результат.
Зачем тогда применять функции с возвратом результата? Есть подозрение, что это как-то связано с использованием локальных переменных, но не уверен.
ЕвгенийП , обещал следЭтюд на эту тему... я жду , блиииин , а ему спорят....
чем больше Этюдов - тем меньше Этюдов :(