я имел ввиду forward declaration. Например либа libwebsockets, у нее часть структур в публичном хидере обьявлена без содержимого. А полное обьявление уже в private-lib-core.h.
а новое правило не конфликтует с "27–Если код не используется ..."?
Функции из вашего примера, "CAN_FrameXXX" наверно можно сделать static, так как они судя по названию только для модуля CAN. Продолжив рефакторинг, убираем префикс "CAN_Frame", функция же локальная, зачем нам лишнее в названиях.
Можно попробовать установить на щетку вибромотор, подходящего размера. И включать его при протирании полов, при мойке щетки или ее последующего отжима, то мне кажется эффективность повысится.
если возможно, то покажите пример си кода, чтобы выкинуло проверку. В недавнем прошлом, я столкнуся с подобным желанием, но не смог добиться от gcc\clang такой оптимизации в простом методе модификации строки. Проверка оставалась всегда, а статичным метод нельзя было сделать.
Если компилятор гарантирует, что переменная не может быть NULL, то зачем тратить ресурсы на проверку того, что невозможно? Ресурсы не только у cpu, но и написание кода, добавление теста на бранч с null и т.п. Насчет библиотечных методов частично соглашусь, так как предполагаю, если в стандарт занесут нулябельность, то c либами будут нюансы. И в них в публичных методах придется проверять NULL. Но библиотеки это еще не все программирование.
мне кажется зря это пытаются определить. И считаю правильным, что для memXXX null это UB. В любом случае в них не должен null попадать. Есть же пропозалы на nullability аттрибуты, и это позволит в compile-time проверять, да и код станет чище и быстрее без лишних проверок.
:) а матрешка из нескольких виртуалок сделает работу мгновенной. Про диск согласен, очевидная причина. Но как GUI становится лучше? Хотя это субьективно и чтобы намерить что-то придется запарится. А желания пока такого нет
Реализация импорта/экспорта настроек — довольно сложная вещь. Для разработки этого функционала нужно было затронуть весь проект на 100%. Важно было предусмотреть обратную совместимость с прошлыми и будущими версиями
Скажите пжлст, для подобной совместимости вам приходится список настроек только наращивать и не удалять\изменять ни один из существующих элементов? Наверно есть шанс, что в новых версиях ПО будут накапливаться уже "не нужные" настройки?
spinlock, там тоже "тупой" поллинг флага.
я имел ввиду forward declaration.
Например либа libwebsockets, у нее часть структур в публичном хидере обьявлена без содержимого. А полное обьявление уже в private-lib-core.h.
Еще применяют для приватности кода в библиотеках. Не получиться пользоваться не публичными методами, так как часть структур обьявлена в сишниках.
в тестах
а новое правило не конфликтует с "27–Если код не используется ..."?
Функции из вашего примера, "CAN_FrameXXX" наверно можно сделать static, так как они судя по названию только для модуля CAN. Продолжив рефакторинг, убираем префикс "CAN_Frame", функция же локальная, зачем нам лишнее в названиях.
Можно попробовать установить на щетку вибромотор, подходящего размера. И включать его при протирании полов, при мойке щетки или ее последующего отжима, то мне кажется эффективность повысится.
если возможно, то покажите пример си кода, чтобы выкинуло проверку. В недавнем прошлом, я столкнуся с подобным желанием, но не смог добиться от gcc\clang такой оптимизации в простом методе модификации строки. Проверка оставалась всегда, а статичным метод нельзя было сделать.
Если компилятор гарантирует, что переменная не может быть NULL, то зачем тратить ресурсы на проверку того, что невозможно? Ресурсы не только у cpu, но и написание кода, добавление теста на бранч с null и т.п.
Насчет библиотечных методов частично соглашусь, так как предполагаю, если в стандарт занесут нулябельность, то c либами будут нюансы. И в них в публичных методах придется проверять NULL. Но библиотеки это еще не все программирование.
мне кажется зря это пытаются определить.
И считаю правильным, что для memXXX null это UB. В любом случае в них не должен null попадать. Есть же пропозалы на nullability аттрибуты, и это позволит в compile-time проверять, да и код станет чище и быстрее без лишних проверок.
вероятно у вас в сишном коде ошибка, должно быть
while( counter <= n)очки тоже не дефолтная оснастка
Уже лет 5 пользуюсь очками, но никак не привыкну :(
Спасибо, я и не подозревал что это исправляется.
а может сразу попытаться добавить пользователя в базу данных? Пусть "она" думает за уникальность. И с многопоточностью проблем уже не будет
желательно добавить конденсатор между "Output" и "GND" потенциометра. Не любят потенциометры постоянку, "шуршать" начинают.
:) а матрешка из нескольких виртуалок сделает работу мгновенной.
Про диск согласен, очевидная причина.
Но как GUI становится лучше? Хотя это субьективно и чтобы намерить что-то придется запарится. А желания пока такого нет
:) элементарно, это же для кейсов 32¾ , 34¾ и 37¾
Классно!
:) напомнило сказку "Каша из топора", тот случай когда периферия умней мозгов
Скажите, а модули ядра для работы непосредственно с железом, как например тут вы тоже смогли переписать? Тогда это круто.
Скажите пжлст, для подобной совместимости вам приходится список настроек только наращивать и не удалять\изменять ни один из существующих элементов? Наверно есть шанс, что в новых версиях ПО будут накапливаться уже "не нужные" настройки?
Или какой-то другой "хитрый" подход?
:) а тогда где гарантия что этот таймер спасет при зависании проги? Например после запуска таймера и перед переходом в сон