Как стать автором
Обновить
9
0

Пользователь

Отправить сообщение
Спасибо, порадовали. Честное слово, именно на этот эффект я очень надеялся. Первая пена прошла, рабочая неделя закончилась и настало время для вдумчивого прочтения-осознания.
По поводу типизации спорить не буду, она конечно же статическая, она же и строгая, в конце концов говорим мы здесь о C++ и упоминаем C. От кастинга enum-ов лично я бы воздержался, но удерживать кого-либо еще, не в праве. А вот по поводу причины отчего это все выглядит а-ля 2008. Причина видимо та же, что и у ребят, имена которых вы видите в списке литературы. Портируемость или как минимум стремление к ней. На моей рабочей машинке до сих пор живет win XP с 2008-й студией, там я бываю редко, а если и бываю, то лишь с одной целью — собрать какой-нибудь очередной кусок кода, который должен быть исполнен/продемонстрирован за пределами моего рабочего пространства.
Так что придирайтесь конечно, как бы мы ни старались, всегда еще остается над чем работать.
А за теплое слово спасибо, действительно приятно.
Очень правильное замечание. Должен признаться, мне пришлось одновременно работать над двумя версиями данной статьи. Русскоязычная версия находится перед вами, англоязычная, при благоприятном стечении обстоятельств, скоро тоже может стать доступной.
Говоря «производительность» (что у нас обычно воспринимается как скорость исполнения), я имею в виду значение слова «performance», которое имеет несколько более широкий смысл и в данном случае разумнее было бы применить слово «эффективность».
Спасибо Вам, видимо имеет смысл внести соответствующее исправление.
Что касается читабельности, зачастую код, в котором используются шаблоны, оказывается более читабельным. Разработка шаблонного кода штука действительно не простая, приходится иметь дело с очень недружелюбным синтаксисом, а вот для использования больших усилий не требуется, STL — хороший пример.
Еще раз спасибо за Вашу внимательность.
В принципе, если следовать этой логике, то как только мы обратились к volatile, мы уже нарушили семантику. Тогда уже при смене честной функции print на пустую и обратно семантика не меняется. А вот последующее комментирование (или исключение любым способом) функции исключает и обращение к переменной, что как раз семантику нарушает.
Идеальных вещей в мире не существует и приходится всегда помнить об ограничениях используемого инструмента.
В любом случае, спасибо Вам за важное замечание, к сожалению, без соответствующего тестирования и анализа я не готов обсуждать этот вопрос.
Стало быть правильно я Вас понял. Не возьму на себя смелость быть категоричным, однако мне все-таки кажется, что если внутри функции аргумент (каким бы он ни был) не используется, то это семантику не меняет.
По крайней мере примерно на таком утверждении основываются всяческие оптимизации компиляторов.
В прилагаемом коде (в хидере avr_misc) для этой цели объявлен шаблон вроде:
template
<
    unsigned bitnum,
    typename ValueType = uint8_t
>
struct bit
{
    static const ValueType value; // по факту value = (ValueType(1) << bitnum);
};

При использовании мы и получаем требуемое
    bit<0>::value
    ...
    bit<7>::value

Ну и конечно вместо целочисленного смещения бита можно использовать соответствующие мнемоники из Atmel-овских хидеров.
Как утверждают классики-программисты, такое определение имеет преимущество перед макросами. Действительно, компилятор сообщит вам если вы случайно сдвинули бит за пределы размера заданного типа.
Я все-таки предположу, что пустая функция типа
void inline debug(const char*, type_of_somevar)
{
}

которая игнорирует аргументы, таки же будет удалена. Здесь print наверное имелся в виду, а не debug.
Однако ничто не мешает это проверить.
Или возможно я не понял Вашего вопроса?
Вероятно Вы имеете в виду пункт 11? Вначале он появился как шутка, потом я решил оставить его в качестве маркера прочитали / не прочитали.
Вы первый, поздравляю!
Откровенно говоря начал было волноваться, когда увидел цикл в функции записи в порт. Когда дочитал до списков типов, успокоился, да это действительно соответствует теме моей статьи. Аналогичная проблема имеет место с ЖКИ тачскринами, при использовании покупного дисплея контакты шины данных устройства также оказываются раскидаными по разным битам разных портов. При использовании стратегий мы могли бы получить примерно следующий интерфейс:
template
<
    class pin_ctrl,
    class device = LCD_C505,
    class orient = tftcd::ORIENTATION<PORTRAIT,240,320>,
    ...
    class dbg = NO_DEBUG
>
struct TFT_LCD;

Шаблонный параметр device скрывает все детали, специфические для конкретной модели дисплея, их существует множество и для каждой определен особый порядок инициализации как минимум. Параметр orient определяет ориентацию дисплея и позволяет существенно оптимизировать функции, связанные с расчетом координат.
А вот единственная вещь, которая является платформенно зависимой, это pin_ctrl — стратегия, которая скрывает всю механику работы с шиной данных устройства. На роль именно этой стратегии годится шаблон описанный в приведенной Вами статье.
Главный же класс TFT_LCD занимается собственно отрисовкой линий, окружностей и шрифтов.
Позволю себе предположить, что данные аббревиатуры не инициатива разработчиков программного инструментария, а следование именованию, предложенному разработчиками железа. Наверное было бы странно видеть что-то типа Sleep_Mode_Control_Register в названии регистра, который у схемотехников называется просто SMCR.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность