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

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

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

0

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

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

Хотите что-то спросить, в чем-то разобраться - так спросите прямо, что именно интересует, а не устраивать всей этой ебаной херни в таком разоблачительном тоне бульварных газетенок.

0

Гуглить "dependency injection" и "inversion of control".

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

0

callbackи нужны в прикладном программировании для асинхронной модели, там где есть долгие процессы, которые не должны лочить основной код. В остальном же это зло которое приводит к callback Hell и прочим велосипедам для их обхода.
В МК с прерываниями они нах не нужны.

0

Сообщение от oomomstir Гуглить "dependency injection" и "inversion of control".

Это совершенно другой инструмент, который решает другие задачи, к колбекам отношения не имеет.

0

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

Речь не о блокировании каких-либо процессов, а о том, что соответствующее событие (на которое нужно вызвать коллбек) происходит асинхронно и независимо от основной программы. Тот же обмен по USB как раз из этой оперы. Ну и наличие коллбеков вовсе не значит автоматически наличие коллбек хелл, есть масса ситуаций, в которых проблема не возникает. Ну и если уж проблема с коллбек хеллом стала вырисовываться, то вполне есть способы с ней бороться, например, ReactiveX (RxJs/RxJava/RxCPP/etc).

Сообщение от otixsom В МК с прерываниями они нах не нужны.

Я с удовольствием послушаю чем обработчик прерывания принципиально отличается от колбека.

0

Сообщение от Ирсений Не, я понимаю в библиотеках USB они буйным цветом цветут. Но в случае библиотеки USB такой механизм навязан разработчиками библиотеки.

Нет, он "навязан" самим протоколом.

Сообщение от Ирсений Есть ли кейсы на которые механизмы коллбэков ложаться идеально ровно?

Да, они хорошо подходят для обработки небольшого количества относительно однородных асинхронных событий.

Сообщение от Ирсений Или коллбэки - это синтаксический сахар сомнительного свойства?

Коллбеки не являются синтаксическим сахаром в принципе. И вообще вам не стоит применять термин, значение которого вы плохо понимаете.

0

Сообщение от ivsy Коллбеки не являются синтаксическим сахаром в принципе. И вообще вам не стоит применять термин, значение которого вы плохо понимаете.

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

0

Сообщение от ivsy Сообщение от otixsom callbackи нужны в прикладном программировании для асинхронной модели, там где есть долгие процессы, которые не должны лочить основной код. В остальном же это зло которое приводит к callback Hell и прочим велосипедам для их обхода.

Речь не о блокировании каких-либо процессов, а о том, что соответствующее событие (на которое нужно вызвать коллбек) происходит асинхронно и независимо от основной программы. Тот же обмен по USB как раз из этой оперы. Ну и наличие коллбеков вовсе не значит автоматически наличие коллбек хелл, есть масса ситуаций, в которых проблема не возникает. Ну и если уж проблема с коллбек хеллом стала вырисовываться, то вполне есть способы с ней бороться, например, ReactiveX (RxJs/RxJava/RxCPP/etc).

Сообщение от otixsom В МК с прерываниями они нах не нужны.

Я с удовольствием послушаю чем обработчик прерывания принципиально отличается от колбека.
В МК на одном ядре асинхронность... Ну ну.

0

Сообщение от otixsom callbackи нужны в прикладном программировании для асинхронной модели, там где есть долгие процессы, которые не должны лочить основной код. В остальном же это зло которое приводит к callback Hell и прочим велосипедам для их обхода. В МК с прерываниями они нах не нужны.

Спасибо за ответ. Да, это разумно - сделать аналог прерывания после того, как библиотека выполнит какой-либо длительный процесс, что бы не лочить основную программу (например, пока раскручиваются блины HDD).

Т.е. да, такое софтовое прерывание нужно. Но способ его написания может быть различен. Или пробрасывание функции указателем через аргументы или дописывание руками библиотечки. И вот опять: есть ли в таком случае хоть какие-нибудь преимущества у механизма, связанного с указателем на функции?

За вчерашний вечер мне пришел в голову интересный пример. С одной стороны - он здорово ложится на идеологию коллбэков, с другой стороны - его применение в mbed сомнительно. Может быть вы как нибудь его прокомментируете.

В каком случае функция может принимать на вход другую функцию, как аргумент? Если наша функция производит дифференцирование, интегрирование, преобразование Фурье, свертку и т.д. Т.е. если представить библиотеку для мат.анализа, ее функции будут предназначены для работы над другими функциями. И данная библиотека будет нуждаться в передаче из нашего приложения функций, как аргументов.

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

0

Сообщение от otixsom В МК на одном ядре асинхронность... Ну ну.

По отношению к основному процессу, любые прерывания это асинхронные события. Думаю, вы путаете асинхронность с параллелизмом, это разные, хотя и связанные понятия. И да, на одном ядре (или в одном потоке) вполне может работать асинхронная программа, тот же node.js, например. Обычно для этого используются select-ы (речь идет о системном вызове, если что).

0

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

Думаю, даже поверхностное знакомство с функциональным программированием снимет много подобных вопросов. Если нужен чисто императивный пример, то есть несколько паттернов программирования, которые удобно реализовывать передавая указатель на функцию. Скажем, типичная стратегия (это название паттерна, если что), которая задает, например, алгоритм обработки данных, может быть передана (в виде указателя на функцию) в другую функцию, которая, например, занимается вытаскиванием данных откуда-нибудь. Это позволяет а) разделить обязанности (вытаскивание данных отдельно, алгоритм обработки отдельно, вытаскивание ничего не знает об обработке, обработка ничего не знает о том, откуда взялись данные), и б) многократно использовать обе части независимо одну от другой (сменить вытаскивание не трогая алгоритм обработки или наоборот, сменить алгоритм не трогая вытаскивание даных или применить алгоритм обработки где-нибудь еще). Еще один (полезный) побочный эффект - при таком подходе получается, что при необходимости реализовывать N алгоритмов обработки и М способов вытаскивания данных, нужно написать N+M функций. При традиционном подходе (когда все в одном) пришлось бы написать N x M функций. Что достаточно геморно даже для малых M и N, не говоря уже о ситуации когда надо добавить новый алгоритм или вытаскивание данных.

0

Коллбэк не всегда асинхронщина, асинхрон - не всегда коллбэк.
Тот же классический qsort, которому надо передавать и функцию сравнения элементов. Никакой асинхронщины, но коллбэк в чистом виде.

0

Большое спасибо, ув.ivsy за развернутый, взвешенный и интересный ответ. Хотелось бы уточнить несколько вопросов:
1. Пишете ли вы что-либо для mbed? В частности, для mcu.
2. Если да, то используете ли вы паттерны проектирования? В частности, "стратегию".
3. Если да, то могли бы вы привести один или несколько кейсов?

0

Сообщение от Ирсений Большое спасибо, ув.ivsy за развернутый, взвешенный и интересный ответ. Хотелось бы уточнить несколько вопросов: 1. Пишете ли вы что-либо для mbed? В частности, для mcu. 2. Если да, то используете ли вы паттерны проектирования? В частности, "стратегию". 3. Если да, то могли бы вы привести один или несколько кейсов?

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

0

callbackи на МК с большим трудом можно оправдать в либах, которые используются поверх или совместно с OS, там где нужно ждать ответы от периферии или действий из-вне пользователей.
Ну или вот как выше приводили пример с функций сортировки.

В С есть достаточно хороший механизм определения wiok функций.

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

0

Сообщение от BusMostir О боже, да какие, к чертям, блины HDD в эмбедде на микроконтроллерах?

Ну найти живой пример из эмбеда совсем не сложно. Например, контроллер CNC станка вполне может дожидаться раскрутки шпинделя до определенной скорости. Иметь коллбек (например, прерывание) по этому событию может оказаться вполне удобным.

0

Сообщение от otixsom callbackи на МК с большим трудом можно оправдать в либах, которые используются поверх или совместно с OS, там где нужно ждать ответы от периферии или действий из-вне пользователей.

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

Сообщение от otixsom И давайте не лезть в высокие материи прикладного (и прочего за рамками МК) программирования, там с callbacks тоже далеко не все гладко и не всегда оправдано их использование.

Естественно. Любой програмный механизм имеет свою область применения. Коллбеки тут ничем не примечательны. Что же касается "высоких материй", то их стоит воспринимать как источник информации. Так или иначе, но задачи, решаемые с помощью МК, все время усложняются. "Высокие материи" задачи подобного уровня решают уже много лет, набили все возможные шишки и нашли приемлемые решения. Зачем же изобретать велосипед заново? Куда разумнее просто применить уже готовые решения, приспособив их для эмбеда. Собственно, худо-бедно, преодолевая (не)здоровый консерватизм эмбеда, все эти решения и технологии постепенно проникают в эмбед, становятся мейнстримом. Лет 15-20 назад на человека, который собирался писать на С для МК смотрели как сейчас на мифического "ардуинщика". Сейчас писать на С норма, а на пишуших на асме смотрят как на ретроградов. Аналогично происходит переход и на плюсы. Ровно так же внедряются и другие подходы/решения. Коллбэки всего лишь одни из них.

0

Сообщение от ivsy Сообщение от BusMostir О боже, да какие, к чертям, блины HDD в эмбедде на микроконтроллерах?

Ну найти живой пример из эмбеда совсем не сложно. Например, контроллер CNC станка вполне может дожидаться раскрутки шпинделя до определенной скорости. Иметь коллбек (например, прерывание) по этому событию может оказаться вполне удобным.
Я сам занимаюсь промышленной автоматикой. И контроллер шпинделя не тупо ждет раскрутки, а в реальном времени получает инфу с высокосростного абсолюного углового энкодера, следя за вращением шпинделя в реальном времени, постоянно, а не по прерыванию.
Конечно, в такие сферы всяких там Арсениев и на пушечный выстрел не подпустят, "дабы чего не вышло"

0

Сообщение от otixsom callbackи на МК с большим трудом можно оправдать в либах, которые используются поверх или совместно с OS, там где нужно ждать ответы от периферии или действий из-вне пользователей. Ну или вот как выше приводили пример с функций сортировки. В С есть достаточно хороший механизм определения wiok функций. И давайте не лезть в высокие материи прикладного (и прочего за рамками МК) программирования, там с callbacks тоже далеко не все гладко и не всегда оправдано их использование.

Кстати. Интересно, по Мисре - указатели на функции - разрешены. Правила №104/№105 намекают на это. Арифметику указателей Мисра отменяет (правило №101), брейк в циклах и континью Мисра - строго отменяет (правила №57/№58) и всё такое... А вот коллбэки почему-то достаточно слабо ограничены. Хотя казалось бы - конструкция предрасполагает к ошибкам.

0