[Сергей Борщ 119]

Все пять обработчиков и не являются статическими членами класса Timer. У Timer есть только функция регистрации прерывания. Обработчик прерывания необходимо зарегистрировать после создания объекта.

Ну да. И в моем ISR() не является членом, но вам это почему-то не понравилось:

В таком исполнении ISR() нельзя сделать членом какого-то класса

 

Тут не понял иронию, что не так в моей реализации? Всё работает и , по-идее, нет никаких противоречий. Можно и унаследовать если есть желание.

Никакой иронии. У каждого свои детали реализации.

 

[kolobok0 0]

Спасибо за методику... Основной недостаток - продолжительное время разработки. ..."на своей шкуре" испытать плюсы и минусы С++.

И плюс, про который все твердят - он помогает использовать старый код вновь гораздо легче, чем просто Си....

 

объектно ориентированый подход и есть методика. как применять - тут увы и ах кол-во специалистов очень мало. причина - не используют

(как правило) опыт ранее накопленный. или по другому - не понимают нафига вообще всё это...

 

лучше всего как применять - описано у Гради Буча.

и идут по шагам.

1) анализ

2) дизайн

3) программирование

 

т.е. из вышесказанного можно сразу увидеть - если перескочить через 2 пункта и начать с третьего - то нифига это уже не ОО(а, д, п)... это будет уже

написание программы на си плас плас в стиле азм... что собственно встречается так часто, как наверное и упоминание о том, что ОО это фигня...

 

надо понимать, что это инструмент. и если его юзать по неназначению, то и результат будет такой-же... нужно понимать, что печка (при любом раскладе)

это ничто иное как бизнес задача(она-же поставленная задача, она же цель всего предприятия касаемое программирования, она же фундамент для

дальнейших построений)... т.е. глупо говорить об абстрактном , типа что лучше, наследование или агрегация... это глупость..т.к. автоматически выпадает из ОО,

и спор превращается программирование ради программирования. Отсюда и понятно, что написание библиотек впрок - такое-же сомнительное занятие.

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

 

т.е. первична задача. вторично как и какими средствами.

на самом деле пока Вы один на один с задачей - то проблемы собственно и нет. все кто "умеет" - невольно быстро в уме проигрывают первые два пункта. кто-то

честно. кто-то пытается натягивать на свои знания технические решения или ещё хуже - подгонять задачу под свои решения(обычно такие люди ноют что

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

в жизни, потому как программа не получается...и т.д.). когда собирается команда 2 и более человек - вот тогда все ослинные уши восприятия и вылазят

на ружу.

 

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

 

[A. Fig Lee 0]

На маленьких задачах преимущества C++ не очевидны.

Нет особого смысла. Борьба с мельницами.

Ежели есть много объектов с похожими свойствами, но кое чем разным, то да, C++.

А если SPI, memory и mems датчик, то нет особого смысла.

Гдето так..

[yanvasilij 0]

megajohn doom13 andrewlekar Сергей Борщ msalov Спасибо! Очень полезные дебаты состоялись, есть о чем подумать.

 

объектно ориентированый подход и есть методика. как применять - тут увы и ах кол-во специалистов очень мало. причина - не используют

(как правило) опыт ранее накопленный. или по другому - не понимают нафига вообще всё это...

 

 

На маленьких задачах преимущества C++ не очевидны.

...

 

Я не спорю, что С++ для маленьких задач это, как использовать трактор для вскапывания земли в горшке с цветком. Просто у меня действительно начали вырисовываться большие задачи, поэтому я начал всерьез задумываться о подходе к программированию. Дело в том, что после десятка проектов и после значительного усложнения реашаемых задач пришел к выводу, что нужно хорошо подумать, хорошо по-проектировать прежде чем хвататься за клавиатуру. Нужно проработать концепцию, нужен этап еще до алгоритмов. Когда мыслишь процедурно, а не объектно, нет инструмента и нет какой то методики позволяющей разбить решаемую задачу на логические куски. Когда программисты пишут на Сях, каждый простите "др...ет как хочет". А когда люди пишут на ООП, они проектируют вполне конкретными методиками, тот же uml или idef. Я не говорю, что это лекарство в моем случае. Я просто хочу проверить поможет ли это мне на этапе проектирования. Конечно та задача, которую я озвучил выше мелковата для ООП, возникают вполне обоснованные вопросы типа "Нафига тут ООП?!". Но я бы замучался расписывать задачу скажем распознавания лиц с видеопотока, а уже если бы мне начали помогать ее разбивать на классы тут...

[yanvasilij 0]

-

[juvf 10]

смешали всё.

 

Ну во первых в avr-gcc от winavr нет операторов new и delete. Кто хочет с++ от winavr - должен это учесть.

Во 2-ых: C++ != ООП

 

я пишу всё исключительно на с++. где нужно - делаю классы, где нужно наследование, где нужно - динамику и контейнеры. А где не нужно - всё равно на с++, пусть даже и выглядит прога в стиле си. Зачем мне помнить на каком языке написана та или иная программа? Или тот или иной файл? Потом понадобится кусок кода из одного проекта использовать в другом - а они на разных языках. Пиши обёртки.... зачем это нужно?

 

И совет новичкам: хотите си - учите си. Хотите с++ - учите с++. (я бы советовал всёже с++). Не нужно писать на си, если нет ооп, и на с++ если есть ооп. Зачем учить 2 языка? Лучше углубитесь в изучение с++, при этом можно писать и без классов, и без стл, и без динамики, без ооп. По мере развития изучайте/добавляйте всякие няшки, которые отличают с++ от си. Даже без ооп с++ стоить юзать только за bool и ссылки, спэйсы..... Также в с++ удобно, что переменную можно объявить непосредственно перед использованием, в всяких форах.

 

Я не спорю, что С++ для маленьких задач это, как использовать трактор для вскапывания земли в горшке с цветком.

Несогласен полностью. такой код/гаршок

int main ()
{
printf("Hello world!")
for(;;);
return 0;
}

Где тут пахата трактором? компилируй компилятором с++, тот же хекс получится.

есть канечно "учителя" по с++ которые дают такие уроки.

 

и сделаем из нее программу на C++:

#include <iostream>  
#include <stdexcept>  
class App  
{
public:
    int Run()  
    {  
        std::cout << "Здраствуй Мир!!!\n";  
        throw std::runtime_error("Что-то плохое в нашей программе случилось.");  
        return 0;  
    }  
    ~App()  
    {  
        std::cout << "До свиданья.\n";  
    }  
};

int main(void)  
{
    try
    {
        App().Run();
    }
    catch(...)
    {
        throw;
    }
    return 0;
}

Чистой воды оверинженеринг (да ещё с ошибками). Такой перегруз можно и на си устроить и на асме.

[andrewlekar 0]

В C99 тоже можно переменную непосредственно перед использованием объявлять. Тоже есть bool. Ссылки полностью перекрываются указателями. Более-менее ценно в C++ - перегрузка функций и неймспейсы.

[juvf 10]

Ссылки полностью перекрываются указателями

не перекрываются. указатель может указывать куда угодно, например на 0.

 

безопасный код.

void f(MyType& i)
{
i = 100;
}

тоже безопасный код, но с указателем

void f(MyType *i)
{
if(i != 0 )
   *i = 100;
}

Но и это не 100% безопасно.

[Мур 1]

On 5/22/2014 at 3:22 AM, juvf said:

смешали всё.

Тут упоминали Гради Буча вскользь. Между тем не вижу я последователей его среди программистов микроконтроллеров, чтобы одним взглядом на UML-диаграмму понять весь дизайн ПО (для стороннего наблюдателя).  Да и технология генерации ПО по диаграммам(как заготовку для заполнения) тоже не практикуют.  Но ведь впечатляет!

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

Никто не пробовал UML применительно к микроконтроллерам?  Вот бы глянуть глазом!

[Мур 1]

Появилось много интересного в  тырнете..

https://pcnews.ru/blogs/osobennosti_ispolzovania_i_testirovania_koda_s_na_mikrokontrollerah-682518.html

http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na-si.html

https://habr.com/ru/post/347980/  

НО про UML тишина...

Хотя словак лихо развернулся.  Теперь его среда стоит 100Евро(под Новый год бывают акции в пол цены) Я года 3 назад пробовал(цена была 30Е), но нашли ему ошибку в генерации кода...

https://www.twirpx.com/file/1324589/

http://bookfi.net/book/549142

[Мур 1]

https://www.softwareideas.net/en/purchase    инструментарий достойный.