[dxp 34]

Но пока мы даже скриншоты вашего эпического GUI не видели.

Если C++ такой мощный, то и GUI видать должно превосходить по изобразительным возможностям какую-нибудь uC/GUI многократно?

Похоже, что GUI для вас - это набор картинок. Поздравляю.

 

Вот он! Голос народа!

 

"обожаю, но" .. "стараюсь его избегать" - лучше не скажешь.

Предположу что это интуиция наработанная годами.

Интуиция нужна там, где не хватает информации. Что касается С++, то информации по нему море, нужно только пойти и взять. Сколько уже ломали копий на тему плюсов, ни разу никто из оппонентов не показал проигрыш С++ по сравнению с С. Только общие заклинания и слоганы, не подтверждаемые практикой. Как с вашим предыдущим постом о якобы увеличении писанины.

 

У меня давно уже есть наблюдение, что активно ругают С++ люди, которые его не знают как следует даже на начальном уровне. Извините, но при всём уважении к вам, как квалифицированному специалисту во многих технических областях, вас я отношу именно в эту категорию. Пока что ваши посты на тему С++ доказывают это, а не обратное. Мне, собственно, без разницы, как вы там видите С++ в своей профессиональной деятельности, но ваши публичные замечания на эту тему, давя авторитетом, формируют неверное представление о предмете у тех, кто пока только приступает к изучению темы, что не в последнюю очередь создаёт "интуицию, наработанную годами".

 

Я бы сказал C++ отторгается всей embedded экосистемой.

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

 

Проникся, вдохновлен и нацелен на использование C++ в микроконтроллерах, спасибо dxp!

Только не соображу, как на объекты программу делить? Обычно, где-то передается, где-то принимается. Куда задвигать функцию пересылки (приема)?

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

 

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

[AlexandrY 3]

Проникся, вдохновлен и нацелен на использование C++ в микроконтроллерах, спасибо dxp!

Только не соображу, как на объекты программу делить? Обычно, где-то передается, где-то принимается. Куда задвигать функцию пересылки (приема)?

 

Браво!

Все расплакались от умиления. :crying:

 

Так мнимое превосходство "знающих" C++ как раз в этой магии "как на объекты программу делить". Еще есть такая магия - "паттерны"

 

Но ответ будет всегда один - вы просто "неопытный" (читай - лох ), несмотря на ваш огромный опыт в embedded.

В крайнем случае не можете общее отделить от специфичного. Или вообще не знаете мир в его связях и смыслах.

 

[becopt 0]

А ведь можно писать под МК на плюсах и в процедурном стиле ;-) Объектный подход не всегда нужен, хотя я вот без него уже не могу :(

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

Плюсы дают возможность писать код куда удобней и понятней, жаль не все это понимают. Но и не все знают Си на хорошем уровне, ведь многие - электронщики, программисты по-совместительству, которым само программирование не так и интересно :)

ООП можно использовать и в Си, например книга Object-Oriented Programming With ANSI-C. Конечно, когда есть компиляторы плюсов для МК, лучше пользоваться ими, но понять как оно реализовано в С++ (то, что спрятано), эта книга очень поможет.

Да и спор-то бессмысленный. Куда лучше смотреть на грамотный, оптимизированный код на любом из языков, чем на говнокод :) Архитектура программного обеспечения > язык программирования.

 

[juvf 10]

А С++ ее не сократил, а даже снова раздул. Это уже деградация, декаданс.

пруф или трепло?

 

Сколько уже ломали копий на тему плюсов, ни разу никто из оппонентов не показал проигрыш С++ по сравнению с С. Только общие заклинания и слоганы, не подтверждаемые практикой.

+1.

 

Сама я C++ обожаю, но при программировании МК стараюсь его избегать - отпугивает излишний "динамизм", когда многое неявным образом заводится в куче. А я привыкла к спартанским ресурсам, когда под кучу памяти жалко, и хотелось бы всё по максимуму держать в статике.

И зря. Боишся динамики может и не зря, но ++ это не динамика. В компиляторе с++ для авр нету new/delete. Тем не менее на с++ даже без динамики удобней писать. Пиши по спартански, но на с++.

 

Я бы сказал C++ отторгается всей embedded экосистемой.

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

 

[Major 0]

Кому интересно (стр. 4).

А то с STL мы тут уже разобрались - http://electronix.ru/forum/index.php?showt...6&hl=median

Ничего впечатляющего. Слезы.

 

Вот ссылка на мой код: https://bitbucket.org/Glavny/medest/src

В Keil MDK-Lite 5.11 он работает в два раза быстрее чем код klen (в репозитории его нет. но если надо, могу выложить здесь).

В MSVC на окне 64 в 5 раз быстрее.

Если компилировать для контейнера container_std_array_t, то даже std::vector не зацепится.

 

 

[kolobok0 0]

...как на объекты программу делить? ..где-то передается, где-то принимается. ..функцию пересылки (приема)?

 

Открою большой секрет:

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

Более того - практически нет контор которые грамотно делают эти шаги: OOA, OOD, OOP.

Более того, для снижения порога вхождения в тему, и в угоду лени шагнули от ОО и явили на свет патерны (бизнес задач не бывает

двух одинаковых в природе вообще. посему попытка натянуть жизнь на узкий шаблон - не есть ОО подход и побольшому счёту сие ЗЛО).

 

как делить на объекты. Это вопрос вопросов на самом деле. Лучше конечно же обратиться к истокам - одному из прародителей ОО

Гради Бучу. В своей книге он попытался разжевать этот момент. Многие за маленькими квантиками инфы не увидели ребёнка и...

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

 

Одна из мыслей от старика Буча, которая тут уже прозвучала - идти от бизнес сущностей. Т.е. это то, что будет статично на ВСЁМ ПРОТЯЖЕНИИ

ЖИЗНИ ПРОЕКТА!!! Это и понятно - если бизнес по торговле шинами, то выращивать пшеницу явно не будут - либо это уже другой бизнес и

соответственно другие задачи, в том числе и программерские. Это один из больших плюсов данного подхода в решении задач.

 

Почему не всё так гладко на этом поприще. Потому, как инструментов много. Достаточно мощные они. Один из инструментов - наша голова.

В мыслях мы зачастую убегаем далеко вперёд, пытаясь воплощать в код очевидные и понятные для нас вещи (тут вот и появляется одна

из засад - мы то не идеальны. и то что предпологаем - это не всегда истина). И отходим(искушение ох как велико) от основных принципов ОО.

Тут и приходит большой, толстый и пушистый зверёк... Второй, по частоте встречаемых проблем - это коллектив. Когда одна голова = OOA,OOD

пролетает в миг (в зависимости от опыта), когда два и больше человека = то тут уже нужно общение. Причём вектора опыта в решении

подобных задач должны складываться и дополнять друг друга а не вычитаться. За частую процесс обсуждения и поиска сводят на нет. Либо

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

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

чтоб коллектив единомышленников начал друг друга только СЛЫШАТЬ - проходит около ДВУХ МЕСЯЦЕВ общения, по часу в день где то как минимум... это

о порядках и величинах...)

 

Для первых шагов - рекомендую почитать Буча. Как вариант спросить про декомпозицию конкретной Вашей задачи на форуме.

Путь не быстрый и сварливый, но мысли даст для размышлений - что не мало и важно :)

Изменено 6 сентября, 2014 пользователем kolobok0

[dxp 34]

Вот ссылка на мой код: https://bitbucket.org/Glavny/medest/src

Очень красивый код. Чувствуется опыт и зрелость, в общем, уровень! Я до такого (надеюсь пока :) ) не дорос.

 

P.S. Готов биться об заклад, оппонент не оценит: и не сможет, и не захочет.

 

Для первых шагов - рекомендую почитать Буча.

За Г.Буча +1.

[Xenia 35]

Очень красивый код. Чувствуется опыт и зрелость, в общем, уровень! Я до такого (надеюсь пока :) ) не дорос.

 

P.S. Готов биться об заклад, оппонент не оценит: и не сможет, и не захочет.

 

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

 

template<typename tobj_t>
auto test_2(tobj_t& tobj, size_t tn) -> decltype(tobj(0))
{
    auto result = tobj(0);
    decltype(result) input[] = { 8, 9, 10, 8, 10, 11, 0, 1, 2 };

    for (auto& v : input){
        result = tobj(v);
        v = result; // write-back
    }
    return result;
}

 

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

[halfdoom 0]

Сугубо практический взгляд со стороны. Этим летом мы сдавали с подрядчиком контроллер техпроцесса (все x86+Linux, порядка 10 отдельных контроллеров). Наши ребята писали все на чистом C++ с Qt (лицензия на последний принадлежит заказчику) - это 7 контроллеров. Подрядчик писал на Java (остальные контроллеры). До выезда на объект было написано множество тестэ-кейсов, вопросы взаимодействия были более или менее отлажены.

 

Запуск линии прошел на ура, а проблемы начались на 3й день работы. После разбора полета выяснилось, что контроллеры на Java не успевали отрабатывать все события, причем простой перезапуск системы полностью восстанавливал работоспособность. Их ребята выяснили, что 2ГБ на процесс им мало. Причем ничего навороченного там нет, математика на уровне 3го курса. Одноплатные компьютеры у заказчика специфические, поэтому нарастить память возможности нет. В итоге, что-то они там крутили в параметрах Java-машины и все пришло в норму. Это стоило нам лишней недели командировки, но теперь мы единственный исполнитель на следующую линию, что можно отнести к несомненным плюсам Java технологий.

 

С другой стороны, у меня есть возможность оценивать работу программистов пишущих на C++/Qt и FreePascal/Lazarus. UI последние однозначно пишут быстрее, но кривость LCL периодически вылазит на кросс-платформенных приложениях. Так-же, подключение сторонних C/C++ библиотек на Паскале не так прозрачно как на C++. Совершенно отвратительно выглядят интерфейсы к C++ библиотекам, а некоторые части сильно завязанные на шаблоны вообще невозможно использовать. И о шаблонах - сам я в них не большой специалист, и иногда вообще не могу понять код изобилующий ключевым словом template... Но это уже моя проблема, т.к. все компилируется и работает :).

 

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

[Xenia 35]

Сугубо практический взгляд со стороны. Этим летом мы сдавали с подрядчиком контроллер техпроцесса (все x86+Linux, порядка 10 отдельных контроллеров). Наши ребята писали все на чистом C++ с Qt (лицензия на последний принадлежит заказчику) - это 7 контроллеров. Подрядчик писал на Java (остальные контроллеры). До выезда на объект было написано множество тестэ-кейсов, вопросы взаимодействия были более или менее отлажены.

 

В тех случаях, когда на контроллере операционка стоит, то это уже "взрослый" контроллер, которому C++ не будет в тягость. А уж про Qt и вопрос не стоит - без C++ там никак нельзя. Да и вообще, если есть 1 МБ памяти, то отказываться от C++ просто глупо.

 

Я же избегаю (как выразилась ранеее) С++ на МК гарвардской архитектуры с объемом flash до 128 КБ (AVR почти все такие). В последнем случае "повторяемость" не достигает такого уровня, на котором деление классы и объекты давало бы ощутимую выгоду. В самом деле, нужно ли заводить класс, если его будет использовать только один единственный объект?

 

Но и в тех же случаях, когда "повторяемость" имеет место, организовать универсальный класс бывает слишком сложно. Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! :) Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.

 

В том же случае, когда препоны такого рода все-таки удалось успешно преодолеть, оказывается, что время было потрачено на борьбу с языком C++, чтобы уломать его сделать очевидные вещи через ухо. :)

[dxp 34]

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

Дык это "5-й этаж" С++, кто заставляет туда лезть? Я вот сам обитаю в пределах "первых 3-х этажей", до пятого не дорос (но красоту и уровень уже оценить могу). Вам же предлагается зайти для начала на первый и походить там. Понравится, поднимайтесь на второй. Фишка плюсов в том, что средства, которые неуместны в той или иной задаче и/или не понимаются/не принимаются программистом, к использованию не обязательны. Что освоили, то и используем. И такой подход даёт безусловно выигрыш без побочных эффектов. Надо всегда это помнить и иметь в виду. Простое правило: "Не увлекаться, использовать только то, что освоено и есть чёткое понимание, что это, для чего и как применять".

 

 

В самом деле, нужно ли заводить класс, если его будет использовать только один единственный объект?

Имеет ли смысл заводить структуру, если она будет в единственном экземпляре? Имеет, т.к. это позволяет логически объединить данные, что упрощает оперирование с программными сущностями без оверхеда.

 

С классом всё ровно то же самое. Только профит ещё больше, т.к. класс сам по себе позволяет делать объекты более законченными.

 

 

Но и в тех же случаях, когда "повторяемость" имеет место, организовать универсальный класс бывает слишком сложно. Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! :) Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.

У вас возникла проблема от недостатка опыта и понимания средств языка. Именно этот случай с UART'ами давно успешно решён, решение предлагалось на этом форуме - точно не помню, кто, кто-то из наших парней приводил (Сергей Борщ или AHTOXA, или оба :) ).

[A. Fig Lee 0]

Я же избегаю (как выразилась ранеее) С++ на МК гарвардской архитектуры с объемом flash до 128 КБ (AVR почти все такие). В последнем случае "повторяемость" не достигает такого уровня, на котором деление классы и объекты давало бы ощутимую выгоду. В самом деле, нужно ли заводить класс, если его будет использовать только один единственный объект?

Угу. На С++ бОльшая абстракция. Меньше контроль ресурсов, С более подходит для мелких.

 

[Xenia 35]

Дык это "5-й этаж" С++, кто заставляет туда лезть? Я вот сам обитаю в пределах "первых 3-х этажей", до пятого не дорос (но красоту и уровень уже оценить могу). Вам же предлагается зайти для начала на первый и походить там. Понравится, поднимайтесь на второй.

А я и на 5-ом этаже обитать могу :), но с существенной оговоркой - когда этот этаж МОЙ! Т.е. когда я сама его придумала и реализовала. Причем, не ради выпендрежа, а лишь только потому, что 4-х этажей для реализации идеи не хватило. Обычно 5-ти этажные конструкции не на конкретный проект бывают рассчитаны, а являются "заделом на будущее", и оттого имеют максимально абстрактный характер. А прошивка МК всегда конкретна, и именно поэтому едва ли стимулирует подниматься на высокие этажи.

 

У вас возникла проблема от недостатка опыта и понимания средств языка. Именно этот случай с UART'ами давно успешно решён, решение предлагалось на этом форуме - точно не помню, кто, кто-то из наших парней приводил (Сергей Борщ или AHTOXA, или оба :) ).

Если возникает проблема, которую среди всего форума решили только два человека, то этот факт уже настораживает. Настораживает тем, что некое средство требует для своего использования определенных сверхспособностей, отсутствующих у большинства. Т.е. имеем случай, когда сама задача много проще, чем средства, которыми она решается. А оптимальной является ситуация, когда средства решения и сложность задачи примерно одного порядка.

[Major 0]

Но и в тех же случаях, когда "повторяемость" имеет место, организовать универсальный класс бывает слишком сложно. Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! sm.gif Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.

Именно так и сделано у меня. Через классы и объекты.

Есть просто кольцевые буферы с использованием CLREX/STREXW (cortex-m3, STM32) для синхронизации. Получается семантика acqure/release.

Есть конечные автоматы для протоколов. Все сделано на шаблонах.

Авто генерация векторов прерываний через контеканацию строк (конфигурация в три строки). Уверяю, что все само, и не тормозит.

Этот код выложить не могу. Надо с заказчиком согласовывать, или переписать так чтобы код был отчуждаем.

 

А про "template<typename tobj_t> auto test_2(tobj_t& tobj, size_t tn) -> decltype(tobj(0))"

Это вы зря. В этой функции все равно что подается на вход, лишь бы callable. И ей не важно что будет на выходе, тип выводится автоматом.

Сначала написал код для C++11, где все само. Потом переделывал под C++98 для кейла.

 

Надеюсь это поможет кому-то принять верное решение (к C или C++).

По проектированию: Буч хорошо, но мало. Если дизайн, то Эванс (OOD). Но и этого мало. Только попо-часы и желательно в команде.

 

 

[Kopa 0]

Надеюсь это поможет кому-то принять верное решение (к C или C++).

Для МК знать и применять ASM не возбраняется :) (раз уж даже для PC есть ОС разрабатываемая на нём)

а мне лично Форта (Forth) за глаза хватает.

Изменено 6 сентября, 2014 пользователем Kopa