Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Это же физика, а не религия. Мало ли что кажется. Если предположить, что драйвер сможет с такой обратной связью работать, то ток через светодидиоды упадет примерно в 3.5 раза. Допустим светодиоды продолжат работать на условно линейном участке ВАХ, тогда электрическая мощность лампы упадет в 3.5-4 раза. И опять же если предположить что на этом участке светоотдача линейна, то и светвовой поток снизится в 3.5-4 раза. Но это все нужно проверять либо по документации, либо экспериментально.
Достаточно в назначении платежа указать что-нибудь подобное, и как минимум со счетом получателя возникнут проблемы в виде блокировки/ограничения транзакций. Где-то же была история, как кому-то отправили несколько переводов по 1р с соответствующими сообщениями, а он потом мучился, пытаясь разблокировать счет…
Давно было дело по памяти пишу. На stm32F102CBT делал устройство, которое цифрует сигнал и гонит данные по USB bulk. К сожалению нигде не записал результаты тестирования, но что-то в районе 7 000 000 b/s чистыми данными получилось выжать. Помню, что почти подобрался к теоретическому максимуму в 8 Mb/s. Размер bulk транзацкции у меня был 1024, и с учетом что каждый новый фрэйм стартует раз в 1мс, как раз и получается что чистых данных по bulk 8 Mb/s.
Все не совсем так. На сайте СТМ цены прежние и норм поставщики пишут что поставят по этим ценам, только срок поставки 52 недели. А это склады лютуют на фоне дефицита. Мы с той же проблемой столкнулись. Удалось найти на время другой подобный контроллер по приемлемой цене, но с переразводкой платы и переносе ПО, благо у СТМ с переносом по минимум проблем.
Лично мне кажется такой человек нужен команде и в чем-то даже полезен. Он не портит общую картину. Отличное от других мнение — это большая польза команде. Это позволяет не только глубже разобраться в вопросе, но и лучше разобраться в своем собственном мнении. Когда все тебе поддакивают, то скорее всего им безразлично твое мнение и в итоге ты не можешь получить реальную оценку своей идеи. Другой вопрос, что над софт скилс надо работать и спорить/общаться доброжелательно и уважительно, независимо от исходов спора.
Состав команды штука не постоянная, наводить на макросы и читать определение дополнительное обременение. Лично я для себя осознал, что это действительно ненужное и усложнение, когда у нас практику студенты проходили. Они знали язык, но макросы сбивали их столку и заставляли задать лишь один вопрос — «а зачем?!», и когда я пытался объяснить по их глазам было видно что они не совсем согласны со мной. Плюс введение макроса это не только усложнение в чтении, но и в написании, теперь надо им везде пользоваться, помнить его. И обычно количество таких макросов имеет свойство расти.
Я не против макросов в целом, я против их использования в тех местах, где синтаксис языка и так неплохо справляется.
Довольно банальная мысль, но я против макросов, которые дублируют и так вполне понятные конструкции языка. Эти макросы хорошо понятны Вам — вы их придумали и вы ими пользуетесь. Но для нового человека это доп нагрузка, нужно их выучить, и если код с for или range он прочитал бы сходу просто владея синтаксисом языка, то макросы придется дополнительно изучить и запомнить.
Согласен, причина в том что исходный блок изначально полностью отсутствует в памяти. memmove должен просто переместить блок вперед(для чего начнет копирование с конца, чтобы не испортить), а раз блока как такового еще нет, то нужный результат не будет достигнут. Поэтому и нужен свой алгоритм копирования. В итоге memcpy нельзя из-за ограничения по пересечению, что на мой взгляд сводится к тому что стандарт не регламентирует с какой стороны начнется копирование и какими частями, а memmove нельзя по описанной ранее причине.
Еще не все прочитал, но уже вопросы:
«Обратите внимание, что из-за возможного перекрытия мы не можем использовать memcpy или memmove.»
Не знаю про какой стандарт речь, и были ли в более ранних стандартах отличия, но C99 накладывает ограничение о недопустимости перекрытия только на memcpy. А memmove — можно использовать для пересекающихся регионов.
Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Это же физика, а не религия. Мало ли что кажется. Если предположить, что драйвер сможет с такой обратной связью работать, то ток через светодидиоды упадет примерно в 3.5 раза. Допустим светодиоды продолжат работать на условно линейном участке ВАХ, тогда электрическая мощность лампы упадет в 3.5-4 раза. И опять же если предположить что на этом участке светоотдача линейна, то и светвовой поток снизится в 3.5-4 раза. Но это все нужно проверять либо по документации, либо экспериментально.
Ошибка в обработчике ошибок, как мило)) ИМХО 90% кода обрабатывающего ошибки не работает, если этот код проверялся только в голове у программиста.
Не хватило только ошибки в протоколах безопасности, чтобы фэйл совсем эпичным вышел.
Все не совсем так. На сайте СТМ цены прежние и норм поставщики пишут что поставят по этим ценам, только срок поставки 52 недели. А это склады лютуют на фоне дефицита. Мы с той же проблемой столкнулись. Удалось найти на время другой подобный контроллер по приемлемой цене, но с переразводкой платы и переносе ПО, благо у СТМ с переносом по минимум проблем.
Я не против макросов в целом, я против их использования в тех местах, где синтаксис языка и так неплохо справляется.
«Обратите внимание, что из-за возможного перекрытия мы не можем использовать memcpy или memmove.»
Не знаю про какой стандарт речь, и были ли в более ранних стандартах отличия, но C99 накладывает ограничение о недопустимости перекрытия только на memcpy. А memmove — можно использовать для пересекающихся регионов.