[dimka76 42]

1 hour ago, Leka said:

Кому нужно? Писанины меньше не станет.

— Теперь вот такое предложение: а что, если
— Не стоит.
— Ясно. Тогда, может быть, нужно
— Не нужно.
— Понятно. Разрешите хотя бы
— А вот это попробуйте. 

[Leka 0]

Я предлагаю не забывать о рефакторинге, и анализировать с этой точки зрения новые концепции программирования.

[Forger 17]

7 minutes ago, Leka said:

Про ООП не буду,

Как раз про ООП и надо, а вот разводить холивар C vs C++ это уже моветон 

[one_eight_seven 3]

53 minutes ago, Leka said:

Я предлагаю не забывать о рефакторинге, и анализировать с этой точки зрения новые концепции программирования.

А теперь то же самое, но осмысленно, пожалуйста.

На моей памяти любое упоминание рефакторинга без конкретного указания, что именно предлагается делать, это либо вот это:

либо во это:

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.

Особенно интересно, как в вашем понимании рефакторинг конфликтует со столь новой и юной парадигмой, как ООП.

[Leka 0]

1 hour ago, Leka said:

с целью в разы сократить объем кода

 

Обычно раза в 3. Последовательное изменение работающего кода, без изменения функциональности, позволяет вовремя обнаружить привнесенные ошибки, чем повторное написание с нуля. Но конечный результат - как при написании с нуля, с учетом накопленного опыта. В этом смысл рефакторинга, подготовить платформу добавления/изменения функциональности.

[dxp 34]

Из книг для начального освоения хорош С.Липпман.

[Arlleex 131]

2 часа назад, dxp сказал:

Из книг для начального освоения хорош С. Липпман.

Скачал, глянул пока что наискосок.

Самое интересное, что в большинстве просматриваемых мною книг, где > 500 страниц, самому C++ отдается не более 300-400. Все остальное - это описание либо каких-то стандартных алгоритмов, либо (в большинстве случаев) - описание библиотек (stl, что ли...). Открыл сам стандарт C++11, там на сам язык отдано ~400 страничек, все остальные ~600 - это описание стандартных библиотек. Теперь вот что интересно: насколько широко применяются эти самые библиотеки при программировании МК? Все эти итераторы, векторы и т.д. Оно выглядит модно, но я не могу оценить их применимость в мире МК в плане быстроты и эффективности.

[jcxz 184]

16 часов назад, Leka сказал:

Последовательное изменение работающего кода, без изменения функциональности, позволяет вовремя обнаружить привнесенные ошибки

......или привнести новые.  

 

12 минут назад, Arlleex сказал:

насколько широко применяются эти самые библиотеки при программировании МК? Все эти итераторы, векторы и т.д. Оно выглядит модно, но я не могу оценить их применимость в мире МК в плане быстроты и эффективности.

Я думаю - тут всё сильно индивидуально.

[Arlleex 131]

7 минут назад, jcxz сказал:

или привнести новые...

Не знаю, чего уж такого люди пишут на МК, что приходится все рефакторить, сокращая код в 3 раза. Мой опыт подсказывает, что лучше озаботиться структуризацией и (возможно) оптимизацией кода сразу, т.к. многие устройства на МК реализуют какой-то вполне детерминированный, на бумаге прописанный (в ТЗ), функционал. Ну не бывает же такого, что из контроллера теплицы просят сделать роутер. Как правило, изменения, вносимые после написания основного кода, не такие значительные, чтобы поломать логику программы настолько, чтобы ее пришлось писать с нуля. А вот если для поддержки какой-нибудь микросхемы по SPI (допустим, аппаратно все заложено и МК по ресурсам позволяет) требуется уже кардинально что-то менять в прошивке - то это следствие костыльного подхода к решению фундаментальных функций девайса. Могут, конечно, поменяться какие-то каналы DMA, или, например, перераспределиться таймеры, но это не тот случай, когда все приходится с нуля переделывать. ИМХО.

[dxp 34]

Стандартная библиотека — сила. Но в первую очередь там, где нет проблем алокацией памяти. На совсем мелких МК ей делать нечего. А средних вполне можно использовать контейнеры ограниченно — например, избегать ситуаций, где может возникать алокация и освобождение памяти. Использовать только функционал. Например, при старте программы создать, скажем, список на заведомо достаточное количество элементов и работать с ним. Из плюсов: не надо писать свой список под элементы нужного типа. Я так делал, проблем не было. Итераторы проблем не создают, даже наоборот.

[Xenia 35]

Переименовываешь расширение имени файла с *.c на *.cpp - вот и весь переход :).

[Aner 3]

2 минуты назад, Xenia сказал:

Переименовываешь расширение имени файла с *.c на *.cpp - вот и весь переход :).

а с dll_ками что делать?

[Arlleex 131]

1 минуту назад, Xenia сказал:

Переименовываешь расширение имени файла с *.c на *.cpp - вот и весь переход :).

Ну нет Такое C++ не скушал

void hw_SetRTC(sRTCInfo *inf)
{
  u8 reg[] =
  {
     Dec2BCD(inf->sec)  & 0x7F,
     Dec2BCD(inf->min)  & 0x7F,
     Dec2BCD(inf->hrs)  & 0x3F,
     Dec2BCD(inf->wday) & 0x7,
     Dec2BCD(inf->mday) & 0x3F,
    (Dec2BCD(inf->mon)  & 0x1F) | B7,
     Dec2BCD(inf->year)
  };
  
  hw_AddRTCTxTrf(0x80, reg, 7);
}

[jcxz 184]

2 минуты назад, Arlleex сказал:

А вот если для поддержки какой-нибудь микросхемы по SPI (допустим, аппаратно все заложено и МК по ресурсам позволяет) требуется уже кардинально что-то менять в прошивке - то это следствие костыльного подхода к решению фундаментальных функций девайса. Могут, конечно, поменяться какие-то каналы DMA, или, например, перераспределиться таймеры, но это не тот случай, когда все приходится с нуля переделывать. ИМХО.

Насчёт SPI я бы как раз возразил. Простой пример: на SPI висит один чип (например SPI-flash). Соответственно - драйвер будет простой (не важно - с DMA или без). Так как канал (SPI) принадлежит только этому драйверу, то он совмещает функции как собственно драйвера флешь так и драйвера канала (SPI).

А потом вдруг появляется необходимость повесить на этот SPI ещё один чип. Совсем другой, со своим драйвером. И отсюда возникает необходимость в арбитраже доступа к SPI от двух разных драйверов.

Т.е. - вместо одного простого драйвера имеем: 2 драйвера + арбитр SPI (драйвер SPI).

А потом ещё возникает необходимость например быстрого доступа по чтению к флешь с малой латентностью доступа (при том что другие задачи пишут/стирают SPI-флешь) и высоким приоритетом. И добавляются другие приоритетные доступы к флешь. И поэтому добавляется ещё один чип SPI-флешь, а драйвер SPI-флешь дополняется функцией периодической инжекции транзакций чтения статуса SPI-флешей (завершения операции записи/стирания для разных SPI-флешь-чипов) между транзакциями к другим чипам.

Или другой случай - на эту SPI решили добавить чип, про протоколу обмена конфликтующий с существующими драйверами SPI-устройств.

Вот в таких случаях и появляется необходимость в кардинальной переделке.

[Xenia 35]

8 минут назад, Aner сказал:

а с dll_ками что делать?

На МК нет dll-лек.