Второе ближе к реальности. Код реализующий протокол обмена "знает" только об абстрактном интерфейсе связи, один из методов которого send_buffer. Реализация интерфейса для кода протокола не важна. Код реализующий интерфейс может быть работать с uart, или другим физическим интерфейсом, а так же быть частью unit test'а.
А на сколько это вообще применимо, если для микроконтроллера в реальности может использоваться один компилятор со своей оптимизацией, а для юнит теста другой? И даже если вы компилите одни и те же файлы, есть риск получить разный результат на выходе.
IMHO, результат исполнения одного и того же кода написанного на языке высокого уровня должен быть один и тот же, вне зависимости от уровня оптимизации, версии компилятора и прочее. Иначе или код содержит "неопределённое поведение" (UB) или есть проблемы в компиляторе, что менее вероятно, чем первое. Задача программиста писать код без UB и кроссплатформенные unit test'ы помогают в этом.
Пример полезности unit test'ов из моей практики. Пишу код для обмена сообщениями с "железкой" через UART. В данный момент времени у меня нет в наличии этой "железки". Код разделён на две части - протокол сообщений и собственно связь через UART. Код протокола написан, обвязан unit test'ами и протестирован на desktop компьютере с бытрой компиляцией и удобным отладчиком. И я могу быть с высокой доли уверенности сказать, что этот код заработает на целевом железе и останется оттестировать только UART код.
Плюсы:
1. есть ускорение времени разработки как из за быстрой компиляции на desktop компьютере, отсутствия загрузки скомпилированного кода в целевой микропроцессор, удобного отладчика, так из-за того, что не нужно ждать когда появится "железка";
2. Нет "боязни" изменения кода и изменения версии компилятора.
В начале статьи перепутаны понятия "шестерня" и "сцепление", например,
нужно задействовать две шестерни из шести (engaged cluthes)
clutch - сцепление, engaged clutсh - включенное сцепление. В этом типе редукторов шесть сцеплений, максимум два из них могут быть включены одновременно, а шестеренок немного больше чем шесть.
Видеокарта, судя по всему, за долгое время жизни успела побывать в ремонте. Вместо оригинальной микросхемы Video BIOS установлен аналог, изготовленный в СССР.
IMHO, более вероятно, присутствие советской ПЗУ вместо оригинальной "говорит" о наличии в карте "прошитых" кириллических шрифтов, т.е. изменение функционала, а не о ремонте.
Один из способов избежать этих проблем — обеспечить этим константами внешнее связывание, тогда мы сможем иметь единственную переменную (инициализированную один раз), которая является общей для всех единиц трансляции.
или
Мы можем включать constants.h в любое количество cpp-файлов, но эти переменные будут созданы только один раз и совместно использоваться во всех файлах с кодом.
Настораживает, использование слова "переменная", когда речь идет о константах или о константных выражениях.
Кстати про –ция и -tion. Я заметил, что в лексиконе людей "из телевизора" появился англицизм — имплементация, в основном в виде "имплементация соглашений". Что уже слов "реализация" и "выполнение" не хватает? Или у него другой смысл?
Вот, например, der Моnd/moon соотносится с der Monat/month, а заодно и с глаголом messen (ср. англ. measure, дрc. metan) – “измерять”, – потому что по движению луны в древности измерялось время.
В статье на wiktionary про этимологию measure написано:
From Middle English mesure, from Old French mesure, from Latin mēnsūra (“a measuring, rule, something to measure by”), from mēnsus, past participle of mētīrī (“to measure, mete”). Displaced native Middle English mǣte, mete (“measure”) (from Old English met (“measure”), compare Old English mitta (“a measure”)), Middle English ameten, imeten (“to measure”) (from Old English āmetan, ġemetan (“to mete, measure”)), Middle English hof, hoof (“measure, reason”) (from Old Norse hōf (“measure, reason”)), Old English mǣþ (“measure, degree”).
Der Begriff geht über mittelhochdeutsch mezzen → gmh und althochdeutsch mezzan → goh auf germanisch met–a– „messen“ zurück; zugrunde liegt vermutlich indogermanisch me– „messen, abstecken“
Es handelt sich um ein Erbwort, das über mittelhochdeutsches mānōt → gmh auf die seit dem 8. Jahrhundert bezeugten althochdeutschen Formen mānōd → goh, mānōth → goh zurückgeht.[2] Diese wiederum entstammen der (erschlossenen) germanischen Form mǣnōþ- ‚Mond; Monat‘, die ihrerseits den (erschlossenen) indoeuropäischen Formen mēnōt-, mēneses- entspringt.
Исходя из вышеперечисленного, я не нахожу никаких соотношений между der Monat, measure и messen.
Можно поинтересоваться, каким источником вы пользовались для утверждения "der Monat/month заодно [соотносится] и с глаголом messen"? И зачем нужно сравнивать messen с measure?
Было бы интересно узнать, почему в немецком языке существует разница, по сравнению с другими языками, в написании двузначных чисел больше двадцати, т.е. zweiundzwanzig vs. двадцать два.
В статье автор обозначает две «ортогональных» дилеммы:
«Работа с настройками из единого места» против «Пишем все сразу по месту»
«Отложенная запись» против «Блокировка»
Если по первому пункту, лично у меня сомнений нет — работа из единого места есть лучший вариант, то второй пункт для меня не столь очевиден и я ожидал, что автор рассмотрит эту тему в своей статье, но этого не произошло. Честно говоря у меня возникло чувство легкого когнитивного диссонанса.
Предложный уважаемым автором способ доступа к настройкам, кроме уже выше перечисленных обладает еще парой недостатков:
При изменении подряд двух параметров, запись на носитель информации будет произведена дважды.
Потенциально больший расход памяти: один раз память выделяется для хранения кешированных значений, и второй раз в драйвере может быть выделена память под хранение всего буфера/страницы, например для расчета контрольной суммы.
В любом случае статья очень познавательна, особенно, в части особенностей С++17, например автор использует константы для значений по-умолчанию
, потому что по-другому в С++17 работать не будет, если поменять описание параметра с const T& defaultValue, на T defaultValue, то компилятор выдаст ошибку a non-type template parameter cannot have type 'float' before C++20. За это автору + за статью.
Комментатор на видео говорит, что систему тестировали в основном осенью и зимой, когда по моим наблюдениям выпадает наибольшее количество осадков за единицу времени в году, а основными причинами неудачи были: листья деревьев летом и массовое распространение интернета — система поддерживала только голосовую связь. Из собственного опыта, в бытность жил в местности, где уровень сигнала в сотовом телефоне зимой был лучше, чем летом.
Второе ближе к реальности. Код реализующий протокол обмена "знает" только об абстрактном интерфейсе связи, один из методов которого send_buffer. Реализация интерфейса для кода протокола не важна. Код реализующий интерфейс может быть работать с uart, или другим физическим интерфейсом, а так же быть частью unit test'а.
IMHO, результат исполнения одного и того же кода написанного на языке высокого уровня должен быть один и тот же, вне зависимости от уровня оптимизации, версии компилятора и прочее. Иначе или код содержит "неопределённое поведение" (UB) или есть проблемы в компиляторе, что менее вероятно, чем первое. Задача программиста писать код без UB и кроссплатформенные unit test'ы помогают в этом.
Пример полезности unit test'ов из моей практики. Пишу код для обмена сообщениями с "железкой" через UART. В данный момент времени у меня нет в наличии этой "железки". Код разделён на две части - протокол сообщений и собственно связь через UART. Код протокола написан, обвязан unit test'ами и протестирован на desktop компьютере с бытрой компиляцией и удобным отладчиком. И я могу быть с высокой доли уверенности сказать, что этот код заработает на целевом железе и останется оттестировать только UART код.
Плюсы:
1. есть ускорение времени разработки как из за быстрой компиляции на desktop компьютере, отсутствия загрузки скомпилированного кода в целевой микропроцессор, удобного отладчика, так из-за того, что не нужно ждать когда появится "железка";
2. Нет "боязни" изменения кода и изменения версии компилятора.
Если вас не затрунит, не могли бы вы провести модифицированный тест на С с вызовом
strlenдоclock_gettime.Спасибо автору за труд.
У меня буквально пару комментариев по поводу тестов, для которых приведены результаты в первых двух таблицах:
Тест на С измеряет "производительность" работы функции
strlen, что IMHO не есть корректно.В тесте на Rust принудительно выключена опция разбора Unicode строк. Для меня лично это выглядит как попытка мухлежа.
Есть подозрение, что компиляторы выкидывают цикл, в котором происходит вызов функции
testIcoSphere(строки 179-182). Это объясняет разницу времени исполнения между MSVC и остальными компиляторами (см. код функцииgetTimestamp).В начале статьи перепутаны понятия "шестерня" и "сцепление", например,
clutch - сцепление, engaged clutсh - включенное сцепление. В этом типе редукторов шесть сцеплений, максимум два из них могут быть включены одновременно, а шестеренок немного больше чем шесть.
IMHO, более вероятно, присутствие советской ПЗУ вместо оригинальной "говорит" о наличии в карте "прошитых" кириллических шрифтов, т.е. изменение функционала, а не о ремонте.
Спасибо, что не стали отрицать факт использования вами "перехода на личности".
Спасибо за разъяснения.
Зачем надо было переходить на личности?
или
Настораживает, использование слова "переменная", когда речь идет о константах или о константных выражениях.
Кстати про –ция и -tion. Я заметил, что в лексиконе людей "из телевизора" появился англицизм — имплементация, в основном в виде "имплементация соглашений". Что уже слов "реализация" и "выполнение" не хватает? Или у него другой смысл?
В статье на wiktionary про этимологию measure написано:
Во второй статье про этимологию messen написано:
В третьей статье про этимологию der Monat написано:
Исходя из вышеперечисленного, я не нахожу никаких соотношений между der Monat, measure и messen.
Можно поинтересоваться, каким источником вы пользовались для утверждения "der Monat/month заодно [соотносится] и с глаголом messen"? И зачем нужно сравнивать messen с measure?
Согласен, я недостоин называться потомком Пушкина, хотя мою ошибку можно назвать "авторской грамматикой". :)
Кстати, кто тут последний в потомки к Безосу? :)
Было бы интересно узнать, почему в немецком языке существует разница, по сравнению с другими языками, в написании двузначных чисел больше двадцати, т.е.
zweiundzwanzigvs.двадцать два.Я поставил вам минус за демагогию.
Это что получаеться, я потомок Рюриков, Романовых и Пушкина вместе взятых?
Интересное видео на тему "падежи в русском языке".
В статье автор обозначает две «ортогональных» дилеммы:
Если по первому пункту, лично у меня сомнений нет — работа из единого места есть лучший вариант, то второй пункт для меня не столь очевиден и я ожидал, что автор рассмотрит эту тему в своей статье, но этого не произошло. Честно говоря у меня возникло чувство легкого когнитивного диссонанса.
Предложный уважаемым автором способ доступа к настройкам, кроме уже выше перечисленных обладает еще парой недостатков:
В любом случае статья очень познавательна, особенно, в части особенностей С++17, например автор использует константы для значений по-умолчанию
вместо
, потому что по-другому в С++17 работать не будет, если поменять описание параметра с
const T& defaultValue, наT defaultValue, то компилятор выдаст ошибкуa non-type template parameter cannot have type 'float' before C++20. За это автору + за статью.Возможно заблуждение. Я писал только про свои наблюдения в том регионе где я жил и Википедия, с ссылкой на местный Гидрометцентр, согласна со мной.
И да, в Великобритании количество осадков зимой больше, чем летом.
Комментатор на видео говорит, что систему тестировали в основном осенью и зимой, когда по моим наблюдениям выпадает наибольшее количество осадков за единицу времени в году, а основными причинами неудачи были: листья деревьев летом и массовое распространение интернета — система поддерживала только голосовую связь. Из собственного опыта, в бытность жил в местности, где уровень сигнала в сотовом телефоне зимой был лучше, чем летом.