ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
О смысле всего сущего0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынокОбъявления
МикроконтроллерыPLD, FPGA, DSP AVRPICARM, RISC-VТехнологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты
1035790 Топик полностью
Связанные сообщения
Logger
[protodb] Protocol Debugger. Отладка и реверс-инжиниринг протоколов.2023-11-12
Допустим, я хочу сделать в threadX логгер. Он будет писать в кольцевой буфер в памяти, из которого медленно и печально будет вып...2020-06-18
+1. Проблемы с детектированием наезда, на необработанные данные, обгона указателя чтения, можно решить, если использовать не ука...2020-05-17
Нормальный логгер, к сожалению, делается только на C++... На C сам язык начинает сильно мешать. Что потенциально можно было бы ...2019-12-11
Так рассуждать, труды автора fmtlib тоже не оправданы. Мол есть printf, он всё делает. Но это не так, очень даже оправданы. Там ...2019-11-13
Использование gdb для распечатки значений в контрольных точках. Демонстрация концепции по ссылке.2019-11-08
Помимо прочего при нормальном программировании всегда делается какой-то "логгер" ведущий протокол работы программы. Потому, что ...2019-08-10
fk0, легенда (12.09.2020 02:10, просмотров: 812) ответил Aleksey_75 на опять плюсы ((( поубивабы!
В плюсах можно сделать шикарнейший логгер. Во-первых не занимающий програмной памяти или памяти данных (оперирует адресами текста в ELF-файле, сам текст в Flash -- отсутствует), во-вторых работающий быстро, в-третьих умеющий распечатывать enum'ы и другие типы, в-третьих выдающий компактный бинарный вывод. Который можно имея ELF файл от этой версии прошивки восстановить в текст. В языке "C" лучшее что можно сделать -- только первый пункт и последний, причём последний 

плохонько.


На первый пункт я давал только что ссылку (http://caxapa.ru/401461). Делается легко.


Если синтаксис и семантика printf'а, то быстро на C не получится. Лучшее что может сделать C -- вызвать функцию с переменным числом аргументов, она может в рантайме, медленно и печально, распарсить строку формата, сериализовать согласно строке аргументы и сериализовать ссылку на строку...


В то же время код на C++ позволяет совершенно фантастическую вещь: строку вида logger("format %d %s %x....", a, b, c) сразу превратить максимально эффективный код, который ничего парсить не будет, а сразу сгенерируются по месту инструкции, ктоорые засунут в нужном формате и нужное место кольцевого буфера и a, и b, и c. В этом мощь C++. Он позволяет генерировать почти что оптимальный машинный код. Компилятор будет генерировать, по заданным правилам, а не ты руками писать.


Третий пункт -- нормально не решается в языке без ООП скорей в языке без Argument Dependent Lookup. Вообще мощь C++ в значительной степени этой "фиче" тоже. Что можно отделить мух от котлет, операции над типами от самих типов. В рамках чистого ООП (как в Delphi, C#) такое невозможно попросту. Это помимо шаблонов и метапрограммирования.


Четвёртый пункт в голом C возможен, но опять же упирается в эффективность кода. Я описывал (и реализовывал) идею сериализации: http://caxapa.ru/976585

На C++ опять же получается по месту генерирать эффективный зависимый от типа выводимых данных код. В голом C так не получится. Т.е. можно всё то же самое написать руками, но это ж чудовищно, писать всё вручную каждый раз, просто написать output(a,b,c,d...) и ожидать эффективного кода -- невозможно.


Про C++:

http://caxapa.ru/907638/ -- о языках программирования и метапрограммировании;

http://caxapa.ru/965849/ -- о многомерности C++ и программировании управлемом типам;

http://caxapa.ru/965825/ -- о преимуществах статического полиморфизма и метапрограммирования;

http://caxapa.ru/965513/ -- о преимуществах C++ по отношению к ошибкам.

http://caxapa.ru/956884/ -- в C++ скрытая сложность вытаскивается наружу, в Python, C# -- прячется, но она везде есть.

[ZX]
Ответить