Для чего нужны callback-функции

Для чего нужны callback-функции? И можно привести какой-нибуль пример по их использованию.

0

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

0

Сообщение от Святогор А теперь серийный порт на c#

Мы в разделе C++

Добавлено через 41 секунду

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

Так каков ваш вариант реализации того же функционала?

0

Сообщение от Croessmah Вы увеличиваете свои знания по мере необходимости а не сразу читаете том после которого сможете нарисовать пиксел. Выше написал про библиотеки.

Можете меня считать полным идиотом но я закончив вуз по ПО зная несколько языков программирования пишу разные программы в основном для себя , но я не умею создавать и подключать Dll библиотеки. Пользоваться их возможностями совершенно невозможно там все работает не так как ожидаешь. Проще самому заново написать аналогичное дело. Это адское изобретение, их хрен подключишь все время глючат, потом скомпилированный код не работает. Документацию по ним пишут какие-то биороботы и подразумевается что ты знаешь историю развития отрасли за последние 40 лет со всеми приколами и подковырками.

0

Сообщение от Святогор Так вот возвращаясь к collback функциям. Имхо они делают код не читаемым

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

0

Сообщение от Croessmah Так каков ваш вариант реализации того же функционала?

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

Добавлено через 4 минуты

Сообщение от Алексей1153 когда в Qt разрешили пользоваться лямбдами в качестве слотов, то коллбэки расцвели удобством. До этого код описания слота (по сути - коллбэка) был размазан по трём местам в двух файлах, и это было порой неудобно

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

0

Сообщение от Святогор Проще самому заново написать аналогичное дело.

Попробуйте, например, написать библиотеку для работы с pdf.

Сообщение от Святогор Судя по всему ресурсы железа они точно не экономят а скорее просто транжирят.

Судя по всему, вы вообще не понимаете что это такое, как работает и зачем нужно.

Сообщение от Святогор Подход совершенно очевидный это что то вроде микросервисов.

И вот нужно микросервису сообщить, чтобы он во время своей работы обратился к другому микросервису.
Так у нас и появятся callback-микросервисы. Дожили...

0

Сообщение от Croessmah Заметьте - "библиотеку" Serial уже кто-то написал за вас, а она уже использует более низкоуровневые интерфейсы. "API" железяки куда сложнее, почему вы не предложите прямо в "процессор" добавить команду Serail.print?

Видите ли в чем дело. На каком бы уровне вы не программировали даже на ассемблере или в машинных кодах, в любом случае кто то уже очень много написал до вас, ваш код не составит и одной десятой процента от того бутерброда технологий который позволяет вашему коду работать. Собственно сама структура процессора со всеми миллиардами транзисторов это то же определённого рода код реализованный в железе.
Команду Serail.print не нужно реализовывать в железе она обеспечивает базовое использование возможностей от которого вы можете плясать в глубину. Если это продвижение в освоении предусмотрено то вы быстро дойдете до самой глубины и потрогаете процессор за его биты и байты. Если же нет дефолтного доступа к возможностям то вас ждут годы осовения информации прежде чем вы сможете в своей программе сделать элементарные вещи. Вот в аруино можно делать сразу а в qt нужны недели.

0

Сообщение от Святогор Вот в аруино можно делать сразу а в qt нужны недели.

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

0

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

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

0

Сообщение от Святогор но не пойму в чем их преимущество

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

0

Сообщение от Святогор Между ними коммуникация, сам сервис должен уметь спрашивать что ему нужно и принимать то что ему прислали.

Это будет "божественный микросервис"?
Банально. Хотим вывести информацию на вот это вот устройство вывода.
Микросервис должен будет из коробки поддерживать все существующие и будущие устройства?
Или ему всё-таки можно будет передавать микросервис-драйвер, который умеет работать с устройством?

0

Сообщение от Croessmah Вы же понимаете, что Arduino по уровню - это такая игрушка по сравнению с другими вычислителями? И не поверите, в Arduino тоже нельзя сразу взять и сразу научиться сим-картами манипулировать - нужно, как минимум, написать обертку, чтобы просто и удобно отправлять СМС.

Я ардуино привел для примера какой может быть подход а не для того чтобы показать что все компьютеры должны стать такими же.
Что касается сим карт. Подключение работа с сим картами весьма сложная процедура. И сложная она именно потому что те люди которые пишут библиотеки для gsm устройств c сим картами и для прочих устройств никогда не утруждают себя созданием дефолтного пути для пользователя. Они требуют обязательно сразу ввести все настройки (включая те которые они сами не знают как работают) требуют знание особенностей работы сотовой сети и протоколов связи. В этом и проблема. Я не могу пользоваться отпракой СМС до тех пор пока не узнаю целую кучу информации которая по большей части мне никогда не понадобится и 99 процентов настроек не будут меняться вообще никогда.

Есть ещё старая проблема. Почему устройства сами не содержат драйверы? Уже 20 лет как флеш память стала дешёвой и разместить 512 мегабайт памяти для драйверов на разные ос на самой например видеокарте не представляет проблемы.
То есть по идее все современные устройства могут иметь полный универсальный и исчерпывающий вариант plugnplay.
Вы воткнули неизвестное устройство в систему, и оно тут же в известном месте и в известном виде публикует информацию о себе и список драйверов для разных ос. Более того устройство на чистейшем человеческом языке может написать кто оно такое кто его сделал серийный номер и адрес сайта производителя и даже мануал . И без всяких там id div и прочего птичьего языка который был нужен когда в устройстве было 8 байт перезаписываемой памяти.

Добавлено через 15 минут

Сообщение от Croessmah Это будет "божественный микросервис"? Банально. Хотим вывести информацию на вот это вот устройство вывода. Микросервис должен будет из коробки поддерживать все существующие и будущие устройства? Или ему всё-таки можно будет передавать микросервис-драйвер, который умеет работать с устройством?

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

0

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

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

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

А потом окажется, что для вашей ОС драйверов нет, потому что вчера вы обновились с WinY до WinZ, а железяка в магазине лежала три года. Итог - устройство больше размером и дороже стоит, а дрова всё равно закачивать придется.

Сообщение от Святогор кто его сделал серийный номер и адрес сайта производителя и даже мануал .

А на упаковке не написано?

Сообщение от Святогор Уже 20 лет как флеш память стала дешёвой и разместить 512 мегабайт памяти для драйверов на разные ос на самой например видеокарте не представляет проблемы.

На больших дорогих устройствах, наверное, можно. Но обычно с ними в комплекте идет диск или флешка с драйверами. Да и уже лет 20 как скачивание и установка дров не является проблемой (пока еще, но всё может поменяться ).

Здесь же всё как всегда. Из одного рупора кричат, - "поставьте флешку и дайте дрова с устройством", а из соседнего - "нахрена мне эти дрова на устройстве?"

Сообщение от Святогор Устройство ввода-вывода с точки зрения системы тоже микросервис, оно получает сообщение и выполняет его.

Так а как указать какой микросервис использовать?
Как только вы в один микросервис отправите "имя" ("номер", "идентификатор", "путь", ...) другого микросервиса и первый микросервис начнет что-то делать через второй - вы получите микросервис обратного вызова.

0

Вот вам пример общения с ос как он фактически выглядит:

пользователь:
хочу вывести смайлик на экран
ос: нихт ферштейн ERROR UNDEFINED COMMAND

напечатай вот эти пикселы вот тут.
нет у нас пикселов есть байты. И нет тут.
Ну у вас же есть экран?
Незнаю.
А что есть?
10 тысяч строк ответа.
А есть устройство графического вывода?
есть. Какое вам надо.
Любое.
Конкретно.
Все.
Конкретно.
Ок какие есть
Вот они:шцарыулдрамржф
А что как с ними общаться ?
Ищи книги.
Ок устройство вывод № 4 тыт тут?
Да
Выведи пиксел с такими координатоами.
Заполните сначала бланк там 42 позиции.
А как?
Читай книгу.
Заполнил выводи пиксел.
Ок
Ну и где он?
Незнаю читай книгу.

Добавлено через 8 минут

Сообщение от Croessmah Так а как указать какой микросервис использовать? Как только вы в один микросервис отправите "имя" ("номер", "идентификатор", "путь", ...) другого микросервиса и первый микросервис начнет что-то делать через второй - вы получите микросервис обратного вызова.

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

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

Добавлено через 4 минуты

Сообщение от Croessmah На больших дорогих устройствах, наверное, можно. Но обычно с ними в комплекте идет диск или флешка с драйверами. Да и уже лет 20 как скачивание и установка дров не является проблемой (пока еще, но всё может поменяться ). Здесь же всё как всегда. Из одного рупора кричат, - "поставьте флешку и дайте дрова с устройством", а из соседнего - "нахрена мне эти дрова на устройстве?"

Пользователь не должен скачивать и искать драйвера. И даже если они скачиваются они должны храниться в устройстве.
Ос не должна этим заниматься. Она должна спросить ваше устройство хочет качнуть драйвер разрешить ему лезть на сайт за дровами да нет?

0

Тут все накинулись на Святогор, но он говорит разумную вещь. Поясню.
Я начинал программировать на С++ в школе, Комп.класс у нас был под чистым досом (винда тоже была для изучения офисных приложух, но программировать лучше было под настоящим досом, чтобы не ждать пока майкрософт Студия на стареньком компе загрузится(а может повесит его наглухо))

Так вот там программирование давалось очень легко как раз благодаря тому что не надо было тратить несколько лет в консольных приложениях, пока не изучишь С++. У Досовского Борланд С++ были библиотеки т.н. Borland Graphics Interface позволяющего включить граф.режим одной командой. И набором простых команд рисовать круги, эллипсы, прямоугольники, произвольные полигоны и.т.д. ни разу не задумываясь о создании окна, обработке сообщений, сохранении всяких дескрипторов рисования, ну или в случае доса о генерации прерываний.
Благодаря этому программирование учить было просто.
Хочешь нарисовать солнышко - думаешь только о том, на какой синус умножить координату лучика в цикле, а не о том, как блин этот лучик хранится в видеопамяти!

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

0

Сообщение от Kuzia domovenok Так вот там программирование давалось очень легко как раз благодаря тому что не надо было тратить несколько лет в консольных приложениях, пока не изучишь С++.

Как будто кто-то сейчас запрещает взять другой язык вместо C++.
Я вот помню с DirectDraw на VB6 познакомился.
С понятиями 3D на Blitz3D (там тоже VB-подобный синтаксис).
Основные понятия, алгоритмы, структуры данных - всё это до C++ было по большому счету.
Даже WinAPI изучался до С++.
Конечно, если сразу наскоком пытаться всё и сразу понять, взяв при этом максимальную сложность - так не бывает.

А вот я еще помню тот момент когда узнал, что в VB6 есть типы и как ускорилась программа, когда я её переписал указывая нужные типы у переменных.

0

Сообщение от Святогор Вы сделали танчик и он должен существовать отдельно это же сразу очевидно

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

В общем это не очевидно и это не тривиально. И свести это к тривиальному нельзя.

0

Сообщение от TRam_ на сколько сместилась каждая из них

Страшное зрелище - гусеница обгоняет танк.

0

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

0

TRam_, да я понял о чем вы, но страшность зрелища это никак не уменьшает.

0