Forger

Можете забрать зачетку книжку. Перед переcдачей хорошенько подготовьтесь: перечитайте еще раз "лекции", обратитесь к доп. литературе. Вот еще https://doc.qt.io/archives/qt-4.8/signalsandslots.html

Ах вот оно что! Так бы сразу и сказали, что ни чего не поняли из моих описаний :) Ну, извините, лучше "разжевать" не могу ((

Прекрасно понимаю, поскольку в более ранних проектах делал именно так, как вы сейчас делаете. Очень хорошо понимаю. Но, увы, вы не понимаете подобного построения проектов, которое используется в той же Qt, которое использую я. Увы, напрочь не понимаете зачем это нужно, что это дает и какие решает проблемы, свойственные решениям "в лоб", которые вы используете. Да и понять-то даже не пытаетесь. Ну, что ж: надо, значит - не надо :)

Вы ничего не поняли и того, что пытался донести :( Последняя попытка: При таком вызове будет произведено много вложенных вызовов. extern "C" void TIM2_IRQHandler() { module.thread.handler(); } Ведь напрямую обращаться к полям (данным) класса - неправильно, это напрочь нарушает ООП. Поэтому это придется делать это через соотв. методы в самом классе модуля, потом во вложенном и так далее. Чем сложнее иерархия, тем дольше будем добираться до самого "дна". Еще сложнее "выбираться наружу". Костыльные "inline" где-то помогут, а где-то и нет. Тут как "повезет". Делегат в данном случае дает строго детерминированное время вызова. Глубина вложений не имеет значения. Сложность проекта также не имеет значения. Да и стек прерываний не требуется конский (хотя это - мелочи). Более того, экземпляр module - не глобальный объект, его созданием занимается совсем другое объект (у меня некий Application). Он же управляет "связыванием" модулей другу с другом. Модули НИЧЕГО друг о друге не знают, не никаких перекрестных include "" (посмотрите для примера какой-нибудь нормальный проект под Qt.) Если одному модулю нужно вызвать метод другого, то через делегаты это также производится за детерминированное время. Короче, вот вам простая и тривиальная задачка - нужно обратиться из вложенного класса к его владельцу и вызвать его метод, не имея доступа к экземпляру этого класса-владельца. Так сказать "выбраться наверх". Я раньше это делал через соотв. поля owner, которые нужно было заранее заполнять владельцу классов, который ими владеет. В итоге структура получалась просто ужасный - чем сложнее проект, тем больше эта "паутина" вызовов. Либо строим весь этот огород либо забываем про ООП и пишем по сути на голом процедурном "С". Пусть даже с некой "иерархией". Тут еще много ограничений возникает при такой "плоской" схеме построения, где все всё видят и имеют доступ ко всему, в том числе и полям (данным) вложенных классов. Если и после этого вы не поняли зачем тут нужны делегаты (или на край функторы), и для чего все это, то, увы :(

Перебор - это если если чего-то не хватает или чего-то в притык, в данном случае - ОЗУ. Но у меня с этим проблем нет. Не сомневаюсь, что понимаете про просто делегаты, но я о другом - поэтому слово "делегаты" взял в кавычки. Попробую еще раз объяснить. Речь про проект со строгой иерархией (вложенные классы и т.п.), а не "плоский", как многие до сих применяют в МК. В таких проектах невозможно связать модули/классы/блоки, которые ничего друг о друге не знают, кроме как через делегаты или что-то подобное. И именно в таких проектах классические С-обработчики, как палка в колесе - напрочь все портят и разрушают всю конструкцию. Ваше решение конечно же не спасает - экземпляр класса по сути объявлен глобально, т.е. никому не "принадлежит". Раньше так же делал. Поверьте, я изрядно намучался с подобным подходом - код получался настолько запутанным, что никакие комментарии не спасали. Поэтому для меня незначительный оверхед по входу прерывания и потребность в доп. ОЗУ - это сущие мелочи, по сравнению с выгодой от такого решения. Разумеется, в простых и тем более примитивных проектах нет никакой иерархии и такое решение будет действительно избыточным.

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

Для меня ваши решения - это уже давно пройденный путь, так не делаю по причинам, которые тут уже излагал. Но полагаю, что вы не понимаете этих причин. Отсюда взаимное недопонимание. как раз наоборот, но вы и этого не видите (( Коли так, то предлагаю на этом закончить :)

Поздравляю! Вы решили очень "важную" проблему :) Я раньше тоже так делал - размещал обработчик прямо в файле, где создаются классы, методы которых мы в нем вызываем. Но, увы, проблемы возникли позже при развитии проекта - слишком тесные взаимосвязи, масса глобальных объектов (пусть даже и static), как итог - полноценно использовать ООП не получается (( А раз нет ООП, то и от С++ нет никакого проку. Все это можно и на С сделать. Делегат тут хоть и дает небольшой оверхед, но полностью снимает ограничения, очень нужные для грамотного построения проекта. Второе мне важнее этих крохотных "накладных" расходов. Но кому как ;)

Как я понял: компилятор целиком вашу функцию засунул в C-обработчик. Поскольку они объявлены и реализованы в одном и том же файле. Сам С-обработчик безусловно нельзя заменить С++ функцией. Я именно это имел ввиду под словами "Архитектуру никакой ваш inline не обманет". Вызов функции, привязанной к делегату, требует дополнительных 4 такта: В моих проектах эти доп. 4 такта - "слезы" по сравнению с тем, какой функционал дает делегат.

Сделайте (времмено) uart.UartIrqHandler() пустой, хотя бы с одним оператором __NOP(), покажите disasm Покажите объявление этой UartIrqHandler внутри класса ConsoleUart.

Выделите нужный кусок из disasm при вызове скажем uart.UartIrqHandler() и покажите только его.

Делегаты тут ни при чем. Вы просто хотите за что нибудь уцепиться, чтобы себя же убедить, что некие "делегаты" якобы зло, прекрасно понимая, что имея исходники, можно найти решение даже в таком невероятно редком случае. Чепуху не читаю. При возникновении прерывания все равно произойдет вызов обычной С-функции, адрес которой размещается при сборке проекта в таблице векторов. Далее уже из этой С-функции произойдет вызов вашей (не static) С++ функции с размещением в стеке в регистре R0 соотв значения this. Архитектуру никакой ваш inline не обманет. Можете убедиться лично и посмотреть disasm.

И часто это вам приходилось делать - на грани сотни другой байт балансировать с объемом ОЗУ? Просто ради интереса соберите статистику по своим проектам и посмотрите RAM usage. Уверен, что редко где будет более 50%. Если начнете вызывать из прерываний С++ функции, любые, то разницы никакой не будет. А то и вовсе наоборот. Ваше мнение понятно. Раньше и я разделял это мнение, но времена меняются, проекты становятся сложнее, камни - толще...

МК от этого не будет медленнее работать, не будет тупить или дольше "загружаться". От этого НИЧЕГО не изменится. В конечном счете покупателю изделия совершенно до лампочки, сколько там ОЗУ в МК используется или не используется программером. К тому же существует такой термин - "накладные расходы". Их никто не отменял. Переходим на плюсы с виртуальным методами, RTTI, исключениями и т. п. - накладных расходов не избежать. С другой стороны можно по-прежнему как аборигены сидеть на голом С, бить себя "пяткой в грудь", а при этом даже самые дохлые современные МК по внутрянке обгоняют некоторые компы из прошлого века (не говорю уже про более серьезные МК). Через десятилетие, другое самый дохлый МК будет иметь уже несколько десятков кБ ОЗУ как минимум. Но, уверен, все равно найдутся деятели, которые будут "экономить на спичках". Просто, их будет уже намного меньше Это вы верно заметили. Раздел-то я упустил из виду. Пардон ))

Если проект расходует, например, всего 50% от этого ОЗУ, то эти 6% не имеют никакого значения. Если же ваш проект находится на грани, скажем 94..95% ОЗУ, то закладывание таких жестких ограничений впоследствии может обернуться боком. Оверхед практически такой же самый, какой получается при вызове метода видимого класса из С-функции обработчика, через & или по указателю. А если вызываете виртуальный метод, то как раз очень сильно проигрывает. Компилятор же очень грамотно понимает суть моей затеи. Вы ничего не поняли из моих подробных описаний задачи и способов ее решения. Или просто не хотите вникать, или вообще не читали.