Здравствуйте, пыщьх, Вы писали:

H>>И в общем-то просто ну нету в большинстве задач которые я решал в embedded (я занимался сжатием видео) нормального места для ООП (то есть не на уровне "класс — это продвинутая структура"). Не нужно мне там было сложных абстракций. Там и других сложностей хватало. И, кстати, насколько я понимаю в этой области (сжатие видео на embedded платформах) так думает подавляющее большинство.
П>90% "сложностей" решается абстрагированием от железа и проверкой (отладкой) алгоритмов на Win32/Visual Studio. Потом ТОТ ЖЕ код пересобираем хоть под AVR. Template + inline позволяет делать это без runtime overhead. Если писать на plain C, да, будет много сложностей...

Не вижу, чем бы мне помог C++. Даже "C с объектами" не очень-то и нужен. inline есть и в C. Да и оверхед этот не столь страшен как его малюют. Где критично -- многострочный define -- вот и весь "темплейт".

А если на C++ писать нормально, а не как на "C с объектами" -- совсем другие ресурсы нужны, не выгодно это. Вот и вся правда.
Да и C++ под многие ембеддед-платформы нет.

Здравствуйте, пыщьх, Вы писали:


П>Фишка в том, что многие "шаблонные дебри" резловятся при компиляции и получаемый код ни на байт не хуже чисто-сишного.

ты реально сравнивал или так предполагаешь ?

Здравствуйте, Ytz, Вы писали:
Ytz>Есть ребята которые программируют микроконтроллеры, так у них как правило все сводиться к "получил байт — послал байт", пишут они на С, программы довольно простые, умение программировать слабенькое, это даже скорее электронщики с опцией программирования.
Ша абижусь.
Все очень сильно зависит от того, для каких задач микроконтроллер используется. Очень может статься, что математику придется вьючить будь здоров. Бывает, что с памятью не размахнешся, ибо есть ограничения по стоимости микроконтроллера (оптимизация, т. к. серия и конкуренция), энергопотребление и т. п. и т. д.. На С тоже далеко не всегда можно, а если и можно, то еще надо проверить его выхлоп. Близость с "железу", а у него свои тараканы и совсем иного плана. Работа в команде со схемотехниками — свои особенности общения. После этого С++ с Boost могут детской песочницей показаться. Вобщем я туда больше не хочу, хотя и интересно: когда груда железа начинает жить своей осмысленной жизнью — аж дух захватывает.

Здравствуйте, jakor, Вы писали:

J>Здравствуйте, пыщьх, Вы писали:


П>>Фишка в том, что многие "шаблонные дебри" резловятся при компиляции и получаемый код ни на байт не хуже чисто-сишного.

J>ты реально сравнивал или так предполагаешь ?
это в динамических языках где все в рантайме резолвится — и тип обьекта и иногда даже наличие в нем определ метода. а С++ такой язык что там самый жуткий шаблон может свернуться в примитивный С-код, точно такой же, как если писать руками

Здравствуйте, jakor, Вы писали:

J>Здравствуйте, пыщьх, Вы писали:


П>>Фишка в том, что многие "шаблонные дебри" резловятся при компиляции и получаемый код ни на байт не хуже чисто-сишного.

J>ты реально сравнивал или так предполагаешь ?
Я реально сравнивал. GCC 4.4. AVR, ARM, x86 и еще пара платформ. Сделал хренову тучу коммерческих проектов на этом.
Для тех кто в танке: GCC работает по принципу "front end + back end" плюсовый код а-ля void func() {object a; something();} будет представлен в виде void func() {struct a; a_constructor(&a); something() a_destructor(&a);}. Соответственно, если конструктор/деструктор инлайновый, можно всякие частоиспользуемые микрооперации так оборачивать. А-ля:

class InterruptHolder
{
private:
   char m_SavedSREG;

public:
   InterruptHolder()
   {
      m_SavedSREG = __READ_SREG();
      _disable_interrupts();
   }

   ~InterruptHolder()
   {
      __WRITE_SREG(m_SavedSREG);
   }
}

Всё, теперь atomic-операции делаются добавлением одной строчки:

{
  InterruptHolder holder;
  //Atomic operation body
}

В чистом Си пришлось бы руками объявлять в начале хранилище для старого SREG и руками его считывать/записывать. Плюс, межплатформенность такому коду бы и не снилась без кучи #define. Плюс, необходимость делать руками release() перед каждым return. В плюсах компилятор это сделает за вас с тем же конечным результатом.
НО если ОДИН раз не подумать и вместо char m_SavedSREG объявить int m_SavedSREG, то int будет использоваться везде, где используется InterruptHolder и этого будет явно не видно (например, вим-куны люто-бешенно неневидят go to definition/class visualization, т.к. их нет в уютненьком виме). Какой подход выбрать: думать прежде чем писать, или кодить все каждый раз вручную, чтобы больше писать и меньше думать — каждый решает сам...

Здравствуйте, fk0, Вы писали:

fk0>Здравствуйте, пыщьх, Вы писали:

H>>>И в общем-то просто ну нету в большинстве задач которые я решал в embedded (я занимался сжатием видео) нормального места для ООП (то есть не на уровне "класс — это продвинутая структура"). Не нужно мне там было сложных абстракций. Там и других сложностей хватало. И, кстати, насколько я понимаю в этой области (сжатие видео на embedded платформах) так думает подавляющее большинство.
П>>90% "сложностей" решается абстрагированием от железа и проверкой (отладкой) алгоритмов на Win32/Visual Studio. Потом ТОТ ЖЕ код пересобираем хоть под AVR. Template + inline позволяет делать это без runtime overhead. Если писать на plain C, да, будет много сложностей...

fk0> Не вижу, чем бы мне помог C++. Даже "C с объектами" не очень-то и нужен. inline есть и в C. Да и оверхед этот не столь страшен как его малюют. Где критично -- многострочный define -- вот и весь "темплейт".
У многострочного дефайна есть целый букет косяков:
— Сообщения об ошибках будут указывать на строку, где этот #define использовался. Понять, где именно косяк, будет нереально без метода тыка.
— Нет жесткой типизации, сложнее читать код, проще пролезть ошибкам.
— Намного хуже поддержка со стороны IDE в плане code completion при наборе кода этого #define.
— При чем-то нетривиальном вы утонете в генеренных именах а-ля #define

fk0> А если на C++ писать нормально, а не как на "C с объектами" -- совсем другие ресурсы нужны, не выгодно это. Вот и вся правда.
fk0>Да и C++ под многие ембеддед-платформы нет.
GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure. Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd. в 1987 году и портирован студентом-анонимусом на MS-DOS, это уже ваш выбор и вы и без С++ там натрахаетесь (в свое время из-за глюков в IAR-е народ битовые поля руками реализовывал через сдвиги и маски, хе-хе). Тем более, портировать туда GCC будет быстрее и проще, чем кастрировать свой код, чтобы его скомпилировал changhui. С портированием GCC, кстати, знаком не понаслышке. Ну а если начальство как в этом треде

Автор: Andrii_Avramenko
Дата: 15.01.10

типа консервативно и требует, чтобы все собиралось на Visual C 5.0, то это не ко мне, а к другому врачу. Меняйте начальство, в конце концов, они бы еще на запорожце 80-го года выпуска ездить заставляли...

Здравствуйте, пыщьх, Вы писали:

П>Здравствуйте, fk0, Вы писали:


П>GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure. Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd.
Найди не поделочный GCC по TI MSP430 и их же DSP С5000.

П>>GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure. Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd.
D>Найди не поделочный GCC по TI MSP430 и их же DSP С5000.

Оп! Отличный вопрос!

Здравствуйте, denisko, Вы писали:

П>>GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure. Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd.
D>Найди не поделочный GCC по TI MSP430 и их же DSP С5000.
А чем не устраивает мой MSPGCC4? С серьезным проектом, использующим 2 разных RTOS он справляется без проблем. Или Вам шашечки нужны?

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, denisko, Вы писали:

П>>>GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure. Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd.
D>>Найди не поделочный GCC по TI MSP430 и их же DSP С5000.
B>А чем не устраивает мой MSPGCC4? С серьезным проектом, использующим 2 разных RTOS он справляется без проблем. Или Вам шашечки нужны?
При всем уважении, основным условием было "не поделочный". А так не знаю, надо сказать ребятам, пусть посмотрят.

Здравствуйте, пыщьх, Вы писали:

Не соглашусь с Вашей точкой зрения что C++ нужно пихать везде и всегда- для низкого уровня есть C. На C есть поставляемые прозиводителями чипов компиляторы, т.к. это стандарт. А бизнес-логику лучше делать на OOP, на платформе с OS — неважно, десктопе или embedded, ARM или x86, на чем-то высокоуровневом- Java/Scala, Python и других. C++ тоже для полноценной платформы, там где важно не допускать задержек (например из-за работы GC в JVM).

Здравствуйте, denisko, Вы писали:

D>При всем уважении, основным условием было "не поделочный". А так не знаю, надо сказать ребятам, пусть посмотрят.
Стоп. Что значит "не поделочный"?
Написанный 50 индусами, а не одним русским?
Написанный индусами, сидевшими в офисе, имеющем логотип TI?
Просто имеющий логотип TI?
Имеющий (бес)платную поддержку а-ля "помочь ничем не можем, но посочувствуем" (как это и бывает в больших корпорациях)?
Повторюсь, компилятор портирован в рамках большого европейского исследовательского проекта, проверен в нем + получил поддержку коммьюнити (я из этого проекта давно ушел, но компилятор продолжают допиливать). Если все, лежащее не на сайте TI — это "поделочное", то спрашивайте у support@ti.com, а не здесь.

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, denisko, Вы писали:

D>>При всем уважении, основным условием было "не поделочный". А так не знаю, надо сказать ребятам, пусть посмотрят.
B>Стоп. Что значит "не поделочный"?
Возможность после покупки продукта е*ать поддержку в неограниченных количествах без отговорок аля"но это же бесплатный продукт, допиливай сам".
B>Повторюсь, компилятор портирован в рамках большого европейского исследовательского проекта, проверен в нем + получил поддержку коммьюнити
Какого именно сообщества?
B>Если все, лежащее не на сайте TI — это "поделочное", то спрашивайте у support@ti.com, а не здесь.
Заметь, я не у тебя спрашивал и не для того, чтобы получить GCC для MSP.

Здравствуйте, denisko, Вы писали:

D>Возможность после покупки продукта е*ать поддержку в неограниченных количествах без отговорок аля"но это же бесплатный продукт, допиливай сам".
Ты сам-то пробовал е*ать поддержку коммерческих компиляторов а-ля IAR? Они скорее тебе е*альник откусят, чем хоть строчку в свои исходники добавят, ибо "оно каким-то чудом работает и продается, мы чо, враги себе, в ЭТОМ копаться?". Там весь диалог идет в примерно так (было давно в каком-то древнем IAR под Motorola MCS12x):
— Глючит double на таком-то чипе.
— Точно-точно глючит? А вы точно double используете, а не #define double факмоймоск?
— Точно-точно.
(еще примерно неделя переписки)
— Упс, а у нас действительно баг с double на этом контроллере. Ну ладно, не пользуйтесь там double.

TI вообще известны тем, что errata составляет чуть ли не большую часть финальных datasheetов. Так что, твое дело, что за компилятор использовать, но, ИМХО, считать коробочность продукта стопроцентной гарантией против геморроя как-то неумно...

D>Какого именно сообщества?
WSN хотя бы. google://mspgcc4 в помощь.

B>>Если все, лежащее не на сайте TI — это "поделочное", то спрашивайте у support@ti.com, а не здесь.
D>Заметь, я не у тебя спрашивал и не для того, чтобы получить GCC для MSP.
Ну если фраза "Найди не поделочный GCC по TI MSP430", написанная на форуме, а не на e-mail автору сообщения не означает "ау, кто знает качественный порт GCC для TI MSP430?", то я умываю руки...

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, denisko, Вы писали:

D>>Возможность после покупки продукта е*ать поддержку в неограниченных количествах без отговорок аля"но это же бесплатный продукт, допиливай сам".
Естественно пробовал. Все мои проблемы так или иначе решались

B>Ну если фраза "Найди не поделочный GCC по TI MSP430", написанная на форуме, а не на e-mail автору сообщения не означает "ау, кто знает качественный порт GCC для TI MSP430?", то я умываю руки...
Скажи здравствуй мылу пушистому и полотенцу душистому. Ты не истери, а прочти сообщение, в ответ на которое я спросил у автора о существовании GCC для MSP.

Здравствуйте, ArtemGorikov, Вы писали:

AG>Здравствуйте, пыщьх, Вы писали:

AG>Не соглашусь с Вашей точкой зрения что C++ нужно пихать везде и всегда- для низкого уровня есть C. На C есть поставляемые прозиводителями чипов компиляторы, т.к. это стандарт. А бизнес-логику лучше делать на OOP, на платформе с OS — неважно, десктопе или embedded, ARM или x86, на чем-то высокоуровневом- Java/Scala, Python и других. C++ тоже для полноценной платформы, там где важно не допускать задержек (например из-за работы GC в JVM).
Хорошо, я вот в этом посте

Автор: пыщьх
Дата: 14.09.10

привел пример, где С++ позволяет без каких-либо потерь писать более компактный и менее подверженный ошибкам код. Ваше мнение по поводу таких ситуаций? Руками КАЖДЫЙ РАЗ писать объявление + 2 вызова вместо одной строчки на C++?

Здравствуйте, Denis Mingulov, Вы писали:

DM>Здравствуйте, пыщьх, Вы писали:

П>>Вы полагаете, что 100 раз писать руками my_compare_function(&obj1, &obj2); вместо того, чтобы ОДИН раз разобраться, почему не работает operator==, это оптимальное решение? Да, это баг компилятора, но он не мешает пользоваться преимуществами C++.
DM>Если вы приписываете посторонним свои неосознанные желания — пожалуйста, делайте это с цитатами.
DM>Очень жду подтверждения.

Я делал несколько фрилансерских проектов на embedded (AVR). Столкнулся с тем, что сишный код компилится более предсказуемо. Да и компеиляторы для эмбеддед платформ очень ограничено поддерживают С++. Основная сложность была с размером кода. На микроконтроллере где всего 4кб Флэш и 512байт ОЗУ За каждый байт приходится трястись. Так вот, в солучае сишного кода после некоторой привычки можно не лезть после каждой компиляции в ассеблер и искать где-бы еще выиграть пару байт.

Здравствуйте, denisko, Вы писали:

D>Здравствуйте, bazis1, Вы писали:

B>>Здравствуйте, denisko, Вы писали:

D>>>Возможность после покупки продукта е*ать поддержку в неограниченных количествах без отговорок аля"но это же бесплатный продукт, допиливай сам".
D>Естественно пробовал. Все мои проблемы так или иначе решались

B>>Ну если фраза "Найди не поделочный GCC по TI MSP430", написанная на форуме, а не на e-mail автору сообщения не означает "ау, кто знает качественный порт GCC для TI MSP430?", то я умываю руки...
D>Скажи здравствуй мылу пушистому и полотенцу душистому.
Я предложил решение проблемы. Нужна поддержка, я могу за €5K в месяц организовать неплохую поддержку для MSPGCC4. Люди, которые сейчас допиливают порт, будут этому только рады.
Ну а если нужна пиратка энтерпрайзного компилятора, шоб на форумах у народа за баги поспрошать, то это на митинский рынок, а не сюда.
D> Ты не истери, а прочти сообщение, в ответ на которое я спросил у автора о существовании GCC для MSP.
Я не истерю. Сообщение утверждает "GCC сейчас под все есть". Ты привел контрпример. Я твой контрпример опроверг.

Здравствуйте, пыщьх, Вы писали:

fk0>> Не вижу, чем бы мне помог C++. Даже "C с объектами" не очень-то и нужен. inline есть и в C. Да и оверхед этот не столь страшен как его малюют. Где критично -- многострочный define -- вот и весь "темплейт".
П>У многострочного дефайна есть целый букет косяков:

Жить вредно -- от этого умирают (C)

П>- Сообщения об ошибках будут указывать на строку, где этот #define использовался. Понять, где именно косяк, будет нереально без метода тыка.

Реально для профессионалов, умеющих программировать на C. А не для "мы в институте C++ изучали".
Для этого есть cc -E или его аналоги.

П>- Нет жесткой типизации, сложнее читать код, проще пролезть ошибкам.

Единственный недостаток...

П>- Намного хуже поддержка со стороны IDE в плане code completion при наборе кода этого #define.

Ты не видел какие "в доменной области" IDE. Лучше б их вообще не было.

П>- При чем-то нетривиальном вы утонете в генеренных именах а-ля #define

Ниасилил смысл сказанного.

fk0>> А если на C++ писать нормально, а не как на "C с объектами" -- совсем другие ресурсы нужны, не выгодно это. Вот и вся правда.
fk0>>Да и C++ под многие ембеддед-платформы нет.
П>GCC сейчас под все есть. А где есть gcc, есть g++. Собирается добавлением одного ключа в configure.

Не надо сказок. Если при портировании GCC на конкретную платформу забили болт на C++, то его там и не будет.

П> Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd. в 1987 году и портирован студентом-анонимусом на MS-DOS,

В том числе и так. И наличие АЦП и нужного числа ножек в нужном корпусе зачастую может оказаться существеннее какого-то там C++.

П> это уже ваш выбор и вы и без С++ там натрахаетесь (в свое время из-за глюков в IAR-е народ битовые поля руками реализовывал через сдвиги и маски, хе-хе).

90% так называемых глюков -- квалификация программистов ниже плинтуса. Хотя и глюки бывают замечательные конечно.

П> Тем более, портировать туда GCC будет быстрее и проще, чем кастрировать свой код, чтобы его скомпилировал changhui.

Вопрос качественного портирования GCC вполне стоит $$$. Но воз почему-то и ныне там.
А портированием занимаются, ага, эти самые, китайцы за одну зряплату. Не знаю почему так... Мне кажется, объяснение вполне простое -- трудозатраты там исчисляются, в действительности, в человеко-годах и сказки про configure лучше оставить красноглазым студентам.

П> С портированием GCC, кстати, знаком не понаслышке.

А я хотя бы одним глазом заглядывал в dragon book, чтоб теперь понимать, что в действительности всё не так сказочно. Без адекватного кодогенератора gcc задарма не нужен.

П> Ну а если начальство как в этом треде

Автор: Andrii_Avramenko
Дата: 15.01.10

типа консервативно и требует, чтобы все собиралось на Visual C 5.0, то это не ко мне, а к другому врачу. Меняйте начальство, в конце концов, они бы еще на запорожце 80-го года выпуска ездить заставляли...

Я как-то зряплату выбираю, а не начальство. GCC и опенсоурс это здорово и замечательно, но надо где-то и на что-то жить. И если надо будет завтра писать в Visual C дореволюционной версии -- заплюю весь монитор, но потом в общем привыкну. Другое дело, что это может вовсе не консерватизм, а понимание двух простых вещей:

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

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

Возможно, пункт 2 -- это действительно повод искать другое начальство. Потому что рано или поздно придётся.

E>Теперь по финансам.Зарплаты в финансовом могут сильно отличаться даже в одном банке.В целом у них зарплаты в основном средние по стране.Но есть области где зарплаты как минимум в 2 раза выше.Это в основном High frequency trading (HFT) где требуется специальный skills. HFT влючает две области -математическое обеспечение и оптимизация вычислений и минимизация по времени сетевых данных.Со второй частью работает много людей кто пришел в финансы с embedded.Русскоязычный программист, фамилия которого по моему Олейников, точно не помню,и с которым год назад был скандал что он при уволнении украл ценную информацию с банка, пришел в Goldman Sachs с embedded.

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