Нужны ли коллбэки или это синтаксический сахарок сомнительно

Коллбэк - исполняемый код, передаваемый посредством указателя в функцию как аргумент.
Обычно механизм коллбэков (касательно mbed) применяется при использовании какой-нибудь обширной библиотеки, оказавшейся строго между физическим уровнем и уровнем приложения.
Классический пример - библиотека файловой системы. Разумно, что мы подключаем библиотеку для физической реализации протокола обмена данными с носителем (HDD, SD-card и т.д.) плюс библиотеку ФС. И на уровне приложения используем что-нибудь вроде функций readFile/writeFile из библиотеки ФС пробрасывая через эти функции указатели на функции readData/writeData из библиотеки физической реализации. Типа все библиотеки работают как черные ящики, всё прекрасно.

Проблема в том, что в самой популярной библиотеке ФС для mbed - FatFs - не используются коллбэки. В числе файлов библиотеки дается файлик, который нужно подправить руками. Т.е. чуточку залезть в черный ящик. Т.е. концепция "библиотека - это черный ящик, а коллбэки - это способ послать в черный ящик исполняемый код" ступает нафиг. Т.е. зачем тогда нужны коллбэки? Механизм-то их применения нихрена не простой. По сравнению с "подправить файлик в библиотеке". Не, я понимаю в библиотеках USB они буйным цветом цветут. Но в случае библиотеки USB такой механизм навязан разработчиками библиотеки. Есть ли кейсы на которые механизмы коллбэков ложаться идеально ровно? Или коллбэки - это синтаксический сахар сомнительного свойства?

0

Сообщение от dosykus_2 выходцы с ПС кодинга,.

Так вот тоже так думаю. Ирсений уже высказывался ранее про свопы и раскрутку HDD-блинов для свопа.
Я прикидываю, если управление шпинделем винторезного станка будет ждать, пока засвопится ОЗУ. Блин, писюковые погромисты пусть лучче громят компы, а если и хотят переходить на сложные низкоуровневые вещи, то пусть занимаются нормальным самообразованием, без этого долбанного кича.

Вообще мне кажется, что Ирсений тупо пописывает где-то статейки, потому сюда и вылезает с вопросом о "кейсах", выдавая потом набранное за своё. Стопудово. Уж больно его стиль похож на журналюшный разоблачительно-бульварный. Заголовок этой темы посмотрите, ётс..

И вообще, я чето так смотрю, тут почемуто путают коллбэки и прерывания. Прерывыния - они действительно могут возникать "внезапно" для ничего не подозревающей программы. Ну а коллбэк? Он всегда предсказуем, потому что вызывается прямо и непосредственно в строго определенном шаге программы. Или опять писюковые погромисты че-то где-то перепутали?
Callback - это обычная йобаная стандартная функция, а названа она так, потому что по своему характеру похожа на "побежал-схватил-прибежал-отдал". И в машинных кодах коллбэк представляет собой инструкцию типа branch <адрес_памяти>, то есть ровно такую же, как и при обычном вызове функции.

0

Сообщение от ivsy Ровно так же внедряются и другие подходы/решения. Коллбэки всего лишь одни из них.

+1. Коллбэки - мелкая ерунда, которую программист должен писать там, где она нужна, не приходя в сознание. И не писать там, где не нужна. Примитивный инструмент, чуть сложнее простых указателей.

Функция qsort из стандартной библиотеки, которую тут вспоминали - очень характерный пример. Интересно, есть тут люди, способные написать её аналог без callback? (если что - это возможно, только код усложнится)
Аналог - в смысле, сортировка массива любых данных, функция qsort или что там её заменит не должна ничего о них знать (т.к. может быть вызвана для разных массивов), а вызывающий код не должен ничего знать о внутреннем устройстве сортировки (замена quick sort на shitt или heap sort не должна менять вызывающий код).

0

Сообщение от ivsy Паттерны, естественно, использую, но давно не слежу за этим (они просто давно "сидят в мозгу" и применяются на автомате по мере необходимости).

Было бы крайне интересно послушать о применении ООП и паттернов в mbed. Вы правы насчет того, что в ходе прогресса в mbed постепенно просачиваются наработки более крупных систем. Но в то же время весь опыт старших систем нельзя целиком применять на тех же mcu. Какие бы вы посоветовали материалы почитать по паттернам, что бы ощутить их преимущества для mbed но в то же время не создалось ощущение "из пушки по воробьям"?

0

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

0

Сообщение от Ирсений Кстати. Интересно, по Мисре - ... брейк в циклах и континью Мисра - строго отменяет (правила №57/№58) ....

А мы эти правила строго отменили и спокойно пользуемся и брейком и континуем. Только смотрим два раза на код, и тестируем хорошо.

0

Сообщение от Ирсений Было бы крайне интересно послушать о применении ООП и паттернов в mbed. Вы правы насчет того, что в ходе прогресса в mbed постепенно просачиваются наработки более крупных систем. Но в то же время весь опыт старших систем нельзя целиком применять на тех же mcu. Какие бы вы посоветовали материалы почитать по паттернам, что бы ощутить их преимущества для mbed но в то же время не создалось ощущение "из пушки по воробьям"?

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

0

Сообщение от oomomstir Функция qsort из стандартной библиотеки, которую тут вспоминали - очень характерный пример.

К qsort тоже есть вопросы.

Можно себе представить написанную нами библиотеку с алгоритмами сортировки на любой вкус. И каждая функция будет требовать аргументом указатель на функцию сравнения. Но. А по каким критериям мы вообще можем сортировать?
1) По возрастанию абсолютного значения? Ок.
2) По возрастанию модуля? Ну - ок.
3) А еще? На ум приходит сортировка по алфавиту. Ну-у... вещь специфическая. Особенно для mbed.
4) Сортировка массива структур по значению, вычисляемому "на лету" и не содержащемуся в элеметнах структуры? Условно, в структуре есть координаты точек X и Y, нам нужно отсортировать точки по удаленности от некой базовой точки. Э-э-э... при каждом перемещении элемента вместо простого сравнения - возведение в квадрат, возведение в квадрат, сумма, корень, сравнение. И так - по многу раз. Быстрее добавить элемент в структуру, вычислить его один раз для каждого элемента массива и далее - см. 1)

Может лучше вместо проброса функции сравнения аргументом сделать галочку "модуль/абсолютное_значение"?

Да и qsort - рекурсивный алгоритм, что для mcu - достаточно рискованное мероприятие.

0

Сообщение от Ирсений А по каким критериям мы вообще можем сортировать?

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

Сообщение от Ирсений Да и qsort - рекурсивный алгоритм, что для mcu - достаточно рискованное мероприятие.

Сортировок есть много и разных. Быстрая сортировка далеко не всегда оптимальный алгоритм. Хотя рекурсивность не проблема, qsort можно реализовать и без рекурсии.

0

В каком случае функция может принимать на вход другую функцию, как аргумент?

Например в различного вида меню. Микроменю как пример этого.. Ну или например у TI в его подобии OS которую он использует для своего ZigBee стека. Там задача добавляется в массив как адрес ф-ции.

0

callback (в виде параметра, таблицы) полезен если у меня он меняется.
Если он один и не меняется я могу и через wiok, #define сделать - по фиг как.
Обычно писатели библиотек предполагают, что будет более универсально с динамическими callback. При этом раздутие кода и лишние действия их не очень волнуют. Работает и ладно.
ST еще не очень, а вот nRF или TI они во все дырки их суют (да и вообще там мрак внутри - хотя снаружи всё чинно и благородно).

0

Сообщение от ivsy достать из структуры ключ, если нужно - преобразовать его в величину, которую можно сравнивать

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

0

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

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

0

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

Я тут подумал, что даже сортировку по алфавиту легче произвести предварительно преобразовав ключевое поле - "массив символов" в числовой ключ перед сортировкой (а не делая это "на лету", в ходе сравнений внутри сортировки).
1) выясняем самое длинное слово. Пускай в нем N знаков
2) считаем слова (для русского алфавита) - 33-ричными числами. Причем, если слово состоит из M символов, то дополняем его на этапе вычисления числового ключа 33-ричными нулями справа в количестве N-M шт.
3) заполняем доп.поле для сортировки сосчитанными числами
4) выполняем сортировку по числовому ключу.

Т.е. в самой сортировке нужно, пожалуй, два флажка "возрастание/убывание" и "абсолютное_значение/модуль".

0

Сообщение от Ирсений 2) считаем слова (для русского алфавита) - 33-ричными цифрами. Причем, если слово состоит из M символов, то дополняем его на этапе вычисления числового ключа 33-ричными нулями справа в количестве N-M шт. 3) заполняем доп.поле для сортировки сосчитанными числами 4) выполняем сортировку по числовому ключу..

ЧОООО??? эээ ппп... какие, ёп, 33-ричные цифры? Ибицца серце перестало. Таблицу кодировки символов показать или сами найдете?
Слухайте, погромисты - Арсюша, ivsy и им сочувствующие - господа, вы че, с дубу рухнули или вообще не в теме хоть сколь-ко то???
Писец, я фсю жызнь пользовался ASCII кодировкой для перевода буквы в число, для сортировки по алфавиту, для перевода между "маленькими" и "большими" буквами, для перекодировки и вывода шрифтов... и безо всяких там 33-ричных цифр. А тут - на тебе, новое слово Арсюши ломает стереотипы. Ну ващеее ребзя вы чето ващеееее. И вы еще называете себя "очень важными персонами", ётс... Не, ну что не день, так новые "открытия". Куда котицца мир... Че ваапще происходит?

0

Сообщение от Ирсений Сообщение от oomomstir Функция qsort из стандартной библиотеки, которую тут вспоминали - очень характерный пример.

К qsort тоже есть вопросы.

Можно себе представить написанную нами библиотеку с алгоритмами сортировки на любой вкус. И каждая функция будет требовать аргументом указатель на функцию сравнения. Но. А по каким критериям мы вообще можем сортировать?
1) По возрастанию абсолютного значения? Ок.
2) По возрастанию модуля? Ну - ок.
3) А еще? На ум приходит сортировка по алфавиту. Ну-у... вещь специфическая. Особенно для mbed.
4) Сортировка массива структур по значению, вычисляемому "на лету" и не содержащемуся в элеметнах структуры? Условно, в структуре есть координаты точек X и Y, нам нужно отсортировать точки по удаленности от некой базовой точки. Э-э-э... при каждом перемещении элемента вместо простого сравнения - возведение в квадрат, возведение в квадрат, сумма, корень, сравнение. И так - по многу раз. Быстрее добавить элемент в структуру, вычислить его один раз для каждого элемента массива и далее - см. 1)

Может лучше вместо проброса функции сравнения аргументом сделать галочку "модуль/абсолютное_значение"?

Да и qsort - рекурсивный алгоритм, что для mcu - достаточно рискованное мероприятие.

Вот! Это ключевой момент.
Штука в том, что так действительно можно сделать. Но за это вы расплатитесь тем, что у вас sort будет знать про ваши типы данных.
Т.е. вы не сможете использовать библиотечный sort - вам надо будет написать свой, именно для ваших типов. Получается, что функция sort жёстко сцеплена (coupling) с остальным кодом. https://ru.wikipedia.org/wiki/... %B8%D0%B5)

В мелком проекте - это не проблема вообще, и такой подход зачастую оправдан.

Проблемы - только в крупных проектах. Нельзя написать sort раз и навсегда, при изменении кода или структур данных в одном месте - приходится менять в других местах, вылезают трудноотлавливаемые баги... В общем, с какого-то момента привыкаешь добиваться слабого зацепления, и callbacks - просто инструмент для этого.

А разработчикам библиотек без этого вообще никак. У них нет доступа к вашему коду, поэтому написать функцию sort, понимающую флажок - они не могут. Практически единственный вариант - callbacks.

Хотя есть, есть ещё один вариант. Реализован в STM32CubeMX (сейчас сюда сбегутся люди с воплями "калокуб"). Дать вам шаблон кода, в который вы должны вписывать свои кусочки. Поверьте, вам не понравится =)

0

Сообщение от oomomstir Вот! Это ключевой момент. Штука в том, что так действительно можно сделать. Но за это вы расплатитесь тем, что у вас sort будет знать про ваши типы данных.

Он имеет ввиду, что можно qsort-у сразу сказать, где внутри структуры лежать специально подготовленные данные для сравнения.

0

Сообщение от oomomstir Хотя есть, есть ещё один вариант. Реализован в STM32CubeMX (сейчас сюда сбегутся люди с воплями "калокуб"). Дать вам шаблон кода, в который вы должны вписывать свои кусочки. Поверьте, вам не понравится =)

Во-от! По факту, одна из наиболее популярных библиотек для mbed - FatFs - так и устроена - в ней нужно дописать кусочек. Хотел бы понять плюсы/минусы "дописывание" vs коллбэк.
Как я понял, если проект большой, такого уровня как пишет ув.ivsy, то коллбэки начинают играть красками. Если это программа - контроллер от лифта - дописывание удобней.
Хотелось бы оценить граничную сложность проекта начиная с которой надо отходить от дописывания в сторону коллбэков.

0

Пишите как вам удобнее, нет единых правил. Система должна работать согласно ТЗ отвечать необходимым требованиям. Как именно это сделано - уже на совести программиста. В одном из "больших и сложных" проектов коллбэки были только в библиотеке gui emWin, и то, неудобства не доставляли. Крутится в низкоприоритетнои таске и пускай. При этом был, ethernet, http/ftp серверы на несколько клиентов, fatfs с дисками на флеш памяти и виртуальный в sdram, куча различной периферии, всякие виды памяти на разных интерфейсах, кучка шаговых движков и dc. В общем чуть сложнее мигалки. Рулила всем freertos с кучей в sdram. Указатели на функции были, коллбэки в своем коде как то не пригодились. И как то все крутилось "параллельно". Файлы на фтп заливались по 9 мБ/с, двигатели работали, тайминги соблюдались. В чем проблема залезть в черный ящик и посмотреть что там внутри? Ничего критичного в этом нет. У кучи сторонних библиотек порты под определенный проц без каких либо коллбэков, сам пишешь функции драйвера под свое железо. Хотя взять тот же TI , например cc2640 с двумя ядрами - там черт ногу сломит в их ОС, все на коллбэках. С другой стороны удобно - функцию написал, зарегил в недрах их либы, вызывается тогда когда нужно. Слегка непрозрачная работа, но проблем не было.

0

Сообщение от Ирсений Хотелось бы оценить граничную сложность проекта начиная с которой надо отходить от дописывания в сторону7 коллбэков.

Все зависит не от размера проекта, а от того, хотите ли вы повторно использовать код как "черный ящик" или готовы каждый раз лезть в потроха и вспоминать как все это устроено.

0

Сообщение от Ирсений Хотелось бы оценить граничную сложность проекта начиная с которой надо отходить от дописывания в сторону коллбэков.

А очень просто. Как стало мучительно больно без них - начинайте пользоваться. Со временем привыкнете переходить на них чуть раньше.
Ещё, может, и к концепции интерфейсов привыкнете (это чуть сложнее callback: не одна функция, а несколько, см. https://ru.wikipedia.org/wiki/... %B8%D0%B5)). Тоже одна из базовых вещей.

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

0