Re[10]: Программирование в доменной области embedded - какое - О работе

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

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

AG>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>А что по embedded?

В моем отделе разработка идет под Linux на C++, используем Boost, собираем CMake. Разработчиков ищу сильных, так как система сложная, из нескольких независимых модулей: обработка данных, архивирование, передача на верхний уровень и т.д., поддержка апдейтов на лету, разного железа. Кроме этого человек должен знать на базовом уровне электротехнику, читать несложные схемы, уметь пользоваться осцилографом, тестером, паяльником. Есть ребята которые программируют микроконтроллеры, так у них как правило все сводиться к "получил байт — послал байт", пишут они на С, программы довольно простые, умение программировать слабенькое, это даже скорее электронщики с опцией программирования. Обстановка как у меня на фотографии в профиле — куча железок кругом, проводов, все это глючит и горит периодически. Делаем мы комплексы мониторинга, чего не суть. Про зарплату не знаю — не сравнивал, на жизнь хватает, но тут все индивидуально.

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

AG>А что по embedded?

Типично есть плохого качества (ошибки в компиляторе которые приходится ловить и исключать самостоятельно) C-компилятор кое-как поддержививающий "ANSI-C", не более того. C++ может быть, а может нет, скорей нет. В комплекте компилятора есть неполноценная C-библиотека, некоторые функции приходится дописывать самостоятельно. Готовых библиотек зачастую нет или их использовать невозможно, за редкими исключениями. Но и те исключения чаще платные, а работодатель не стремится раскошелиться, украсть сложно
и чревато проблемами (из-за поддержки) -- проще не использовать. Да, компилятор, средства отладки и т.п. -- чаще всё ворованное
(ни разу не видел купленного). Покупается обычно самый дешёвый программатор, с которым отлаживать исключительно неудобно. Собственно отладчик часто сам "неотлаженный" и рассматривание дампа памяти с листигами компилятора (вместо того, чтоб это всё видеть в отладчике) -- нормальная практика. Соответственно разбираться на самом низком "уровне ассемблера" -- необходимо.
Другие языки программирования -- скорей нонсенс. Если мы говорим не о готовой "аппаратной платформе", а о программировании голого микроконтроллера или микропроцессора. ОС может быть, а может не быть, в зависимости от задачи. Если что не микропроцессор с очень большой внешней памятью, то никакой это не linux, а скорей специфическая ограниченная ОС, все функции которой заключаются в переключении между потоками и примитивах синхронизации.
В любом случае всё аппаратно-зависимое приходится писать самостоятельно -- от обработки исключений и прерываний процессора, частично модифицировать C-стартап, до собственно работы с железом. Последнее включает в себя в том числе практически всегда
внешние по отношению к микроконтроллеру или микропроцессору устройства, часто со сложными алгоритмами управления -- собственно ради них всё и затевается часто. В некоторых задачах может быть натуральный realtime, там брейкпоинт не поставишь и мышой по экрану не поелозишь, алгоритм частично можно "моделировать" на PC на тестовых данных, а потом переносить на железо.

Отдельно стоит сказать о том, что в российских фирмах часто болт кладут на программиста и при проектировании собственно железа производительность и объёмы памяти доступные микропроцессору берутся "от балды" без консультации с программистом. Результат соответствующий... В иностранных журнальчиках проскакивала методика, когда вначале всё-таки проектируется ПО, делается какой-то "макет программы", на основе чего расчитываются уже необходимые ресурсы (память, производительность микроконтроллера). Но этим в NASA занимаются, а не в ООО.

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

AG>А что по embedded?

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

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

Речь об embedded.

AK>>Зп имхо чуть ниже по рынку.
AG>Ниже- это насколько, и в каком городе?

С Санкт-Петербурге. Процентов на 20 ниже.

AG> Как культура (дресс-код, формальности), общий интерес к работе?
AG> Какой обычный набор скиллов нужен разработчику?

Забыл ещё. В этой области "чистые программисты" существовать не могут. Надо всё же иногда и за осциллограф подержаться и понимать какие процессы там происходят. Разбираться кое-как в современной электронике и электронике вообще. BGA паять уметь не надо... Формальности -- вовремя на работу приходить заставляют.

AG> В случае мелких устройств наверно только C и ассемблер,

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

AG> но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?

Да какая разница на чём. Что лучше подходит для задачи или что лучше знает тот, кто будет писать сервер. Хотя для тех задач, что возможен LOR-эффект -- я бы предпочёл не видеть там ни Java, ни Python. Скорей perl или голый C(++). Но боюсь, опять же, что и C++ уметь надо, и "большинство крутых C++ программистов" язык знают, а программировать нормально не умеют... Потом Java со своими серверами требующими гигабайт памяти плохо совместима с реальными условиями, где гигабайты стоят денег, если это не единственый сервер на столе у разработчика.

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

O>добавлю что продвинутость фирмы можно оценить по используемым микроконтроллерам: любые 8-мибитные контроллеры говорят о "железной" направленности продутов,

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

O> значит придется много возиться с разводкой плат, отладкой "в железе".

Разводкой плат приходится заниматься всегда отдельно взятому человеку.
А "отладкой в железе" придётся заниматься всегда и для 32-битных MCU всё только сложней будет.

O> 32-битные контроллеры (ARM etc) говорят о том что придется возиться с уже готовым железом и софт в них крутится сложнее, скорее всего придется полностью посвятить себя отладке софта на Си++)

И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.

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

AG>>А что по embedded?
Ytz> Есть ребята которые программируют микроконтроллеры, так у них как правило все сводиться к "получил байт — послал байт", пишут они на С, программы довольно простые, умение программировать слабенькое, это даже скорее электронщики с опцией программирования.

Не совсем так, но очень близко к истине. На счёт "послал байт" -- мне нравится формулировка.

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

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

AG>>Ниже- это насколько, и в каком городе? Как культура (дресс-код, формальности), общий интерес к работе? Какой обычный набор скиллов нужен разработчику? В случае мелких устройств наверно только C и ассемблер, но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?
O>эмбеддед это железки, платы, компорты, провода, осциллографы, программаторы, асм, Си, монтажники, наладчики, суровые заказчики в Сибири — дресс-код и формальности отсутствуют как класс, ибо там нужно как правило уметь паять и держать отвертку. Зарплата ниже (пережитки НИИшной специфики) компенсируется интересностью, общением со множеством разных людей, халтурой и уважением гуманитариев)

Железки и провода- это мне интересно. На самом деле в интересующей меня вакансии роль как раз подразумевает умение писать/читать C, C++, Java и Python, а сама компания не российская. Вот интересно, насколько отличается на западе зп в embedded от зп в инвест. банке? Я знаю, тут на форуме есть товарищи из заграниц.

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

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

fk0> И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.

Всё зависти от возможности железяки и задач. Встречались проекты, где использовался и boost и STL.

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

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

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

Общее, наверное, то, что в мире embedded нет общепринятого mainstream'ового подхода. Поэтому в соседних конторах к решению одной и той же задачи будут подходить совершенно по-разному.

И второе. Поскольку на embedded рынке меньше спрос и меньше предложение рабочей силы, то разброс в условиях будет заметно больше. Т.е., есть шанс как столкнуться с заметно лучшими предложениями, чем на "обычном" рынке, так и с заметно худшими.

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

П>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

Ну, справедливости ради, использование классов не является признаком великой квалификации, а их неиспользование не является признаком ее отсутствия.

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

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

П>>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

Pzz>Ну, справедливости ради, использование классов не является признаком великой квалификации, а их неиспользование не является признаком ее отсутствия.
Решение задачи более простым способом является признаком большей квалификации, чем решение этой же задачи более сложным способом с эквивалентным результатом.

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

Pzz>>Ну, справедливости ради, использование классов не является признаком великой квалификации, а их неиспользование не является признаком ее отсутствия.
П>Решение задачи более простым способом является признаком большей квалификации, чем решение этой же задачи более сложным способом с эквивалентным результатом.

Осталось только доказать, что решение задачи с помощью классов однозначно является более простым, чем без них (ура! намечается холовар Си vs C++

)

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

Pzz>>Ну, справедливости ради, использование классов не является признаком великой квалификации, а их неиспользование не является признаком ее отсутствия.
П>Решение задачи более простым способом является признаком большей квалификации, чем решение этой же задачи более сложным способом с эквивалентным результатом.

А, и да, забыл спросить. Признаком какой квалификации является догматическое мышление?

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

fk0>> И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.
AK>Всё зависти от возможности железяки и задач. Встречались проекты, где использовался и boost и STL.

Это когда под embedded понимается встраивание практически ibm-pc. Для однокристалльных решений -- скорей таки забыть.

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

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

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

AG>>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>>А что по embedded?

П>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...
Это просто предосторожность, чтобы не ипаться с причудами различных компиляторов.

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

Pzz>А, и да, забыл спросить. Признаком какой квалификации является догматическое мышление?

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

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

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

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

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

AG>>>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>>>А что по embedded?

П>>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...
D>Это просто предосторожность, чтобы не ипаться с причудами различных компиляторов.
Ну если кому-то нравится работать докомпилятором за полставки, то это его проблемы

Лично я предпочитаю творческий подход, а рутину за меня пусть G++ делает...

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

П>Лично я предпочитаю творческий подход, а рутину за меня пусть G++ делает...
У него примерно такие же проблемы. Можно "натворить" кучу, так что потом долго искать, в чем же проблема. (в формально нормальном коде)

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

AG>Вот интересно, насколько отличается на западе зп в embedded от зп в инвест. банке?
Зарплата в embedded в среднем не выше и не ниже обычных зарплат.
Так что можно говорить, что по сравнению с финансовыми структурами — на двоичный порядок ниже.

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

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

П>>Лично я предпочитаю творческий подход, а рутину за меня пусть G++ делает...
DM>У него примерно такие же проблемы. Можно "натворить" кучу, так что потом долго искать, в чем же проблема. (в формально нормальном коде)
Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.

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

П>Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.
Речь о правильном коде. И речь о 4.x, а именно даже о 4.3/4.4.

П>Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.
Скажем даже так:
Если не считать "Я Вася Пупкин — мегагуру, пишу формально правильный код, а чо там за компилятор внизу, мне мох и не мои проблемы", а вместо этого понимать, КАК работает G++ и представлять (и проверять зачастую), во что скомпилируется каждая конкретная строчка — то можно здорово экономить время при разработке. Если есть желание экономить время. Если желания ускорять процесс разработки нет (мотивация в ряде компаний этому не способствеут), смысла использовать С++ нет.

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

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

П>>Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.
DM>Речь о правильном коде. И речь о 4.x, а именно даже о 4.3/4.4.
Приведите пример тогда. Я, кстати, выше написал, что понимаю под "думать головой". "Правильный код" бывает разный.

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

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

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

П>>>Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.
DM>>Речь о правильном коде. И речь о 4.x, а именно даже о 4.3/4.4.
П>Приведите пример тогда. Я, кстати, выше написал, что понимаю под "думать головой". "Правильный код" бывает разный.
Самый обычный "C с классами".
Вот пример.
http://qt.gitorious.org/qt-creator/qt-creator/commit/5871f2bb8181b39357cffa5677a75424151ca494?diffmode=sidebyside
Вкратце — странная проблема с параметрами вида namespaceA::namespaceInternal::className, пришлось из-за этого все вносить внутрь namespace (и отказываться от общих operator== etc).

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

П>а вместо этого понимать, КАК работает G++ и представлять (и проверять зачастую), во что скомпилируется каждая конкретная строчка
Это может быть правилом только в общем смысле.
Как раз говорю о том, что это часто бессмысленно и даже вредно (даже не в плане кроссплатформенной разработки, а просто при минимальной смене версии). Нельзя привязываться к конкретному компилятору (и его багам).
"во что скомпилируется конкретная строчка" — те же SSSE3 / NEON и т.д.

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

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

AG>>Вот интересно, насколько отличается на западе зп в embedded от зп в инвест. банке?
DM>Зарплата в embedded в среднем не выше и не ниже обычных зарплат.
DM>Так что можно говорить, что по сравнению с финансовыми структурами — на двоичный порядок ниже.

Хмм. Странно. У нас сейчас набирали старшего embedded разработчика. Взяли нашего парня за 5.9, Хельсинки. Для разных там базоводов или Вебов зарплата около 5т, т.е. выгода заниматься embedded очевидна.

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

AG>Windows C#.

Об этом можно забыть. MS слилал разработку для мобил.

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

S>Хмм. Странно. У нас сейчас набирали старшего embedded разработчика. Взяли нашего парня за 5.9, Хельсинки. Для разных там базоводов или Вебов зарплата около 5т, т.е. выгода заниматься embedded очевидна.
В Финляндии? В Финляндии нет как раз нет смысла заниматься не embedded. Зато никаких "финансовых банков" и т.д. просто в принципе нет.

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

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

S>>Хмм. Странно. У нас сейчас набирали старшего embedded разработчика. Взяли нашего парня за 5.9, Хельсинки. Для разных там базоводов или Вебов зарплата около 5т, т.е. выгода заниматься embedded очевидна.
DM>В Финляндии? В Финляндии нет как раз нет смысла заниматься не embedded. Зато никаких "финансовых банков" и т.д. просто в принципе нет.

Не понял коммент. В Финляндии занимаются embedded потому что тут Nokia, хоть и сливает она рельно. Да, пока здесь есть работа, платят хорошо, см. мой пост выше, но не понятно сколько это все продерится. Кроме embedded есть и другие области. К примеру, в банковской на Nordea пашут наши парни из Reksoft. В других команиях, assenture, идет активный набор на базоводство и веб технологии. Здесь оплата несколько ниже, но главное что работа есть. Вообще хорошо, что нет кризиса и все набирают активно. Последнее время заплата у 4.5 уже не кашерно или должны иметь сильные бенефиты. Вообшем жить хорошо и жизнь хороша!

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

П>... то можно здорово экономить время при разработке. Если есть желание экономить время. Если желания ускорять процесс разработки нет (мотивация в ряде компаний этому не способствеут), смысла использовать С++ нет.

Для ембеда это не настолько критично: там нет насущной необходимости клепания форм тыщами и написания мега-крутых абстракций. Вплоть до того, что каждая отдельная разработка использует уже готовые наработки именно методом копи-паста и последующего дотачивания по месту, а не созданием мега-универсальной библиотеки и последующей ее настройки под другую задачу. Сильно большого смысла использовать си++ в понимании именно "полновесный набор современного си++" действительно нет — это в лучшем случае. В худшем — это таки чревато. По банальной причине отсутствия необходимости в мега-гуру си++, который будет знать во что именно скомпилируется его мега-шаблон при изменении пары внешних параметров, вместо того чтобы использовать для той же задачи с тем же успехом простого инженера си-шника.

ЗЫ: Речь о программах для мобильных телефонов, ай-падов, и виндоус мобайл не идет.

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

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

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

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

П>>>>Если не думать головой при "сотворении" — да. Иначе, все там нормально, серьезно. В ветке 3.x были косяки, но начиная с 4.0 их пофиксили.
DM>>>Речь о правильном коде. И речь о 4.x, а именно даже о 4.3/4.4.
П>>Приведите пример тогда. Я, кстати, выше написал, что понимаю под "думать головой". "Правильный код" бывает разный.
DM>Самый обычный "C с классами".
DM>Вот пример.
DM>http://qt.gitorious.org/qt-creator/qt-creator/commit/5871f2bb8181b39357cffa5677a75424151ca494?diffmode=sidebyside
DM>Вкратце — странная проблема с параметрами вида namespaceA::namespaceInternal::className, пришлось из-за этого все вносить внутрь namespace (и отказываться от общих operator== etc).
И? Один "правильный код" переделали в немного другой "правильный код" (оба варианта синтаксически корректны). Вы полагаете, что 100 раз писать руками my_compare_function(&obj1, &obj2); вместо того, чтобы ОДИН раз разобраться, почему не работает operator==, это оптимальное решение? Да, это баг компилятора, но он не мешает пользоваться преимуществами C++.

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

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

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

AG>инвестиционные- юникс Java или C++
Плюс C#, ASP.NET

investment bank c# — 213 results
investment bank java — 331 results
investment bank c++ — 142 results

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

AG>>>Ниже- это насколько, и в каком городе? Как культура (дресс-код, формальности), общий интерес к работе? Какой обычный набор скиллов нужен разработчику? В случае мелких устройств наверно только C и ассемблер, но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?
O>>эмбеддед это железки, платы, компорты, провода, осциллографы, программаторы, асм, Си, монтажники, наладчики, суровые заказчики в Сибири — дресс-код и формальности отсутствуют как класс, ибо там нужно как правило уметь паять и держать отвертку. Зарплата ниже (пережитки НИИшной специфики) компенсируется интересностью, общением со множеством разных людей, халтурой и уважением гуманитариев)

AG>Железки и провода- это мне интересно. На самом деле в интересующей меня вакансии роль как раз подразумевает умение писать/читать C, C++, Java и Python, а сама компания не российская. Вот интересно, насколько отличается на западе зп в embedded от зп в инвест. банке? Я знаю, тут на форуме есть товарищи из заграниц.

Я могу немного рассказать о Канаде и Америке, где embedded довольно развит.Зарплаты в основном или средние, или немного выше, чем например разработка на С#. Есть правда исключение.Это в основном-military.Например в Maryland в основном IT позиции это разработки embedded systems.Встречал зарплаты под 200К.Зарплаты как в Silicon Value, но жилье гораздо дешевле.Климат и природа в Maryland мне очень нравится.Недостаток-надо быть US citizen.
Теперь по финансам.Зарплаты в финансовом могут сильно отличаться даже в одном банке.В целом у них зарплаты в основном средние по стране.Но есть области где зарплаты как минимум в 2 раза выше.Это в основном High frequency trading (HFT) где требуется специальный skills. HFT влючает две области -математическое обеспечение и оптимизация вычислений и минимизация по времени сетевых данных.Со второй частью работает много людей кто пришел в финансы с embedded.Русскоязычный программист, фамилия которого по моему Олейников, точно не помню,и с которым год назад был скандал что он при уволнении украл ценную информацию с банка, пришел в Goldman Sachs с embedded.

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

Меня тоже ужасно интересуют доменные области, софтверные программы, хардверное оборудование и прочий маслянистый ойл.

Спасибо за низкоквалифицированых кодеров (около 10ти лет занимался embedded, писал в основном на plain C).
Дело в том, что MyClass(a).func(b) действительно работает медленнее (иногда МНОГО медленнее). Например если таблица виртуальных функций лягла не в ту память, или если MyClass распределен на хипе (а хип соответственно лег не в ту память). Именно из-за сложностей с упревлением размещений в embedded (точнее в той его части где производительность супер-важна) используют С а не ++. А my_struct я могу (как правило) положить туда куда надо. В общем embedded гораздо интереснее — сейчас скучаю. Это порой как складывать интереснейший пазл.

П>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

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

Отмазки какие то странные.

H> Например если таблица виртуальных функций лягла не в ту память
Если она вообще есть. Использование класса совершенно не обязывает к использованию vtbl.

H> или если MyClass распределен на хипе (а хип соответственно лег не в ту память).
А если структура распределена на хипе тогда что? И что мешает положить класс в ту же память, куда складывают структуры?

H> Именно из-за сложностей с упревлением размещений в embedded (точнее в той его части где производительность супер-важна) используют С а не ++.
H> А my_struct я могу (как правило) положить туда куда надо.
Что мешает положить класс туда, куда хочется?
Класс жеж по сути развитая структура.

В общем не убедительно совсем.
Я ещё могу поверить в говёное качество С++ компиляторов под embedded, которые генерят хреновый код.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

H>Спасибо за низкоквалифицированых кодеров (около 10ти лет занимался embedded, писал в основном на plain C).
H>Дело в том, что MyClass(a).func(b) действительно работает медленнее (иногда МНОГО медленнее). Например если таблица виртуальных функций лягла не в ту память,
Решается правкой linker script-ов.
Н>или если MyClass распределен на хипе (а хип соответственно лег не в ту память). Именно из-за сложностей с упревлением размещений в embedded (точнее в той его части где производительность супер-важна) используют С а не ++. А my_struct я могу (как правило) положить туда куда надо. В общем embedded гораздо интереснее — сейчас скучаю. Это порой как складывать интереснейший пазл.
Пишется customный operator new().

В обоих случаях нужно ОДИН раз разобраться с новой примочкой (а-ля linker script), после чего вся последующая сложность разработки сократится пропорционально. Ну, или не разбираться и "размазывать" сложность по всему циклу разработки... Примерно как "купить квартиру" vs. "снять квартиру".

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

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

H>>Спасибо за низкоквалифицированых кодеров (около 10ти лет занимался embedded, писал в основном на plain C).
H>>Дело в том, что MyClass(a).func(b) действительно работает медленнее (иногда МНОГО медленнее). Например если таблица виртуальных функций лягла не в ту память,
П>Решается правкой linker script-ов.
Н>>или если MyClass распределен на хипе (а хип соответственно лег не в ту память). Именно из-за сложностей с упревлением размещений в embedded (точнее в той его части где производительность супер-важна) используют С а не ++. А my_struct я могу (как правило) положить туда куда надо. В общем embedded гораздо интереснее — сейчас скучаю. Это порой как складывать интереснейший пазл.
П>Пишется customный operator new().

П>В обоих случаях нужно ОДИН раз разобраться с новой примочкой (а-ля linker script), после чего вся последующая сложность разработки сократится пропорционально. Ну, или не разбираться и "размазывать" сложность по всему циклу разработки... Примерно как "купить квартиру" vs. "снять квартиру".

а зачем разбираться с правкой линкер скриптов и писать кастомный оператор если этого можно не делать ?

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

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

CC>Отмазки какие то странные.

H>> Например если таблица виртуальных функций лягла не в ту память
CC>Если она вообще есть. Использование класса совершенно не обязывает к использованию vtbl.

Интересно, а на фига вообще тогда "использовать классы", если не пользоваться основным преимуществом ООП?

H>>Спасибо за низкоквалифицированых кодеров (около 10ти лет занимался embedded, писал в основном на plain C).
H>>Дело в том, что MyClass(a).func(b) действительно работает медленнее (иногда МНОГО медленнее). Например если таблица виртуальных функций лягла не в ту память,
П>Решается правкой linker script-ов.
Н>>или если MyClass распределен на хипе (а хип соответственно лег не в ту память). Именно из-за сложностей с упревлением размещений в embedded (точнее в той его части где производительность супер-важна) используют С а не ++. А my_struct я могу (как правило) положить туда куда надо. В общем embedded гораздо интереснее — сейчас скучаю. Это порой как складывать интереснейший пазл.
П>Пишется customный operator new().
В каком-то частном случае наверное можно. В общем — быстрой памяти как правило мало и постоянно не хватает. То есть применительно к правке линкер скриптов — их все равно надо будет править каждый раз с добавлением класса. И в общем-то просто ну нету в большинстве задач которые я решал в embedded (я занимался сжатием видео) нормального места для ООП (то есть не на уровне "класс — это продвинутая структура"). Не нужно мне там было сложных абстракций. Там и других сложностей хватало. И, кстати, насколько я понимаю в этой области (сжатие видео на embedded платформах) так думает подавляющее большинство.

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

H>В каком-то частном случае наверное можно. В общем — быстрой памяти как правило мало и постоянно не хватает. То есть применительно к правке линкер скриптов — их все равно надо будет править каждый раз с добавлением класса.
Нет. Один раз при портировании на платформу.
H>И в общем-то просто ну нету в большинстве задач которые я решал в embedded (я занимался сжатием видео) нормального места для ООП (то есть не на уровне "класс — это продвинутая структура"). Не нужно мне там было сложных абстракций. Там и других сложностей хватало. И, кстати, насколько я понимаю в этой области (сжатие видео на embedded платформах) так думает подавляющее большинство.

90% "сложностей" решается абстрагированием от железа и проверкой (отладкой) алгоритмов на Win32/Visual Studio. Потом ТОТ ЖЕ код пересобираем хоть под AVR. Template + inline позволяет делать это без runtime overhead. Если писать на plain C, да, будет много сложностей...

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

CC>>Отмазки какие то странные.

H>>> Например если таблица виртуальных функций лягла не в ту память
CC>>Если она вообще есть. Использование класса совершенно не обязывает к использованию vtbl.

H>Интересно, а на фига вообще тогда "использовать классы", если не пользоваться основным преимуществом ООП?
Хех, я слышал этот аргумент лет 5 назад в одной небольшой конторе; назовем ее, скажем, стаут-кард. VTBL, сцуко, медленно работает. А если юзать С++, то надо юзать VTBL. Иначе, какой это С++...
Вы часто в embedded используете function pointers? Виртуальные функции — это не более чем удобное и красивое решение для юзкейсов, где в C будут использоваться указатели на функции.
Из тонны написанного под embedded C++-кода virtual мне не приходилось использовать нигде! Хитрые шаблоны и объектные обертки вокруг оборудования — да. Иерархии policy-классов — да. Типизированные статические пулы — да. Даже объектно-ориентированный task scheduler с синхронизацией писал в свое время... И то, для совместимости с C-шными приложениями, там function pointer был (единственное место, где это вообще понадобилось).

Ничего личного, но "а на фига вообще тогда "использовать классы", если не пользоваться основным преимуществом ООП?" это как раз аргумент низкоквалифицированного кодера, не понимающего что такое С++ и как его эффективно использовать. Александреску почитайте, что ли...

Вот вот. Так всегда кажется — сейчас под Win32 отладим, а потом пересоберем "хоть под AVR". Как низкоквалифицированый кодер скажу что так не работает никогда и ни у кого. _Все_ вещи связанные с кодированием и декодированием видео перенесенные на embedded платформы (т.е. там где производительность критична) были написаны на С и оптимизированы вначале именно на С под конкретную платформу. Перенос этого на другую платформу как правило требует архитектурных изменений кода.
Повторюсь, так делают практически все (я работал с кодом таких "брендов" как Analog Devices, Intel, TI, KORG, etc.). Видимо у них ни у кого не было времени почитать александреску (ничего личного)

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

H>Вот вот. Так всегда кажется — сейчас под Win32 отладим, а потом пересоберем "хоть под AVR". Как низкоквалифицированый кодер скажу что так не работает никогда и ни у кого. _Все_ вещи связанные с кодированием и декодированием видео перенесенные на embedded платформы (т.е. там где производительность критична) были написаны на С и оптимизированы вначале именно на С под конкретную платформу. Перенос этого на другую платформу как правило требует архитектурных изменений кода.
Я не говорю "спроектировать и написать чисто на Win32, а потом перекомпилять". Я утверждаю, что можно изначально спроектировать систему так, что отладка "бизнес-логики" пройдет на Win32, а под железом останутся вопросы оптимизации и отладки 10% аппаратно-зависимого кода. Приведу пример. Однажды разрабатывал я местячковый такой фреймворк для распределенных вычислений. Среди железных платформ были AVR, AT91SAM7 и т.п. И "изюминкой" проекта был хитрый самосинхронизирующийся протокол обмена данными между контроллерами. На самом начальном этапе проектирования было принято решение сделать самый нижний уровень переключаемым: заменяем BusDriver<AVR::UART1> на BusDriver<Simulator::UART<GlobalUART_A>> и собираем Win32-версию а-ля по потоку на симулируемое ядро. Вот только малая доля багов, обнаруженных в реализации протокола:
Забытый вызов функции синхронизации времени
Ошибки в последовательности вызова обработчиков транзакций
Забытый case в обработчике прерываний от UART

Писалось бы все на чистом С и сразу под AVR, каждое из перечисленного приводило бы к ситуации "упс, чаво-то плата зависла, понять бы, какой из контроллеров виноват". В Студии же все баги находились и исправлялись на лету, ибо отладчик с визуализацией типов и всякие перки а-ля отображение timestamp-а в debug name потока упрощают отладку в разы.
Подобную абстракцию можно было бы реализовать и на C, но это были бы тонны копипасты и find-and-replace... В "плюсах" же все решается заменой аргумента шаблона...

H>Повторюсь, так делают практически все (я работал с кодом таких "брендов" как Analog Devices, Intel, TI, KORG, etc.). Видимо у них ни у кого не было времени почитать александреску (ничего личного)

10 лет назад не было GCC 4.x и существующие оптимизаторы действительно не позволяли делать хорошее абстрагирование, не принося в жертву производительность. "Бренды" зачастую очень консервативны, так что это не показатель. Многие "бренды" до сих пор используют ПО управления конвейерами, написанное под DOS. Это не значит, что писать современный код под DOS удобнее, чем под современые ОС.

H>>Вот вот. Так всегда кажется — сейчас под Win32 отладим, а потом пересоберем "хоть под AVR". Как низкоквалифицированый кодер скажу что так не работает никогда и ни у кого. _Все_ вещи связанные с кодированием и декодированием видео перенесенные на embedded платформы (т.е. там где производительность критична) были написаны на С и оптимизированы вначале именно на С под конкретную платформу. Перенос этого на другую платформу как правило требует архитектурных изменений кода.
П>Я не говорю "спроектировать и написать чисто на Win32, а потом перекомпилять". Я утверждаю, что можно изначально спроектировать систему так, что отладка "бизнес-логики" пройдет на Win32, а под железом останутся вопросы оптимизации и отладки 10% аппаратно-зависимого кода. Приведу пример. Однажды разрабатывал я местячковый такой фреймворк для распределенных вычислений. Среди железных платформ были AVR, AT91SAM7 и т.п. И "изюминкой" проекта был хитрый самосинхронизирующийся протокол обмена данными между контроллерами. На самом начальном этапе проектирования было принято решение сделать самый нижний уровень переключаемым: заменяем BusDriver<AVR::UART1> на BusDriver<Simulator::UART<GlobalUART_A>> и собираем Win32-версию а-ля по потоку на симулируемое ядро. Вот только малая доля багов, обнаруженных в реализации протокола:
П>Забытый вызов функции синхронизации времени
П>Ошибки в последовательности вызова обработчиков транзакций
П>Забытый case в обработчике прерываний от UART

П>Писалось бы все на чистом С и сразу под AVR, каждое из перечисленного приводило бы к ситуации "упс, чаво-то плата зависла, понять бы, какой из контроллеров виноват". В Студии же все баги находились и исправлялись на лету, ибо отладчик с визуализацией типов и всякие перки а-ля отображение timestamp-а в debug name потока упрощают отладку в разы.
П>Подобную абстракцию можно было бы реализовать и на C, но это были бы тонны копипасты и find-and-replace... В "плюсах" же все решается заменой аргумента шаблона...
Да, в общем-то на С делается две библиотеки — одна AVR_UART, другая Simulator_UART. все отлаживается, переносится и т.д. Но не в том суть. Наверное надо сказать, что embedded конечно бывает разное. Например если надо написать хм... браузер или там RSS ридер под S60, то очевидно надо использовать всю мощщььь ООП

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

H>>Повторюсь, так делают практически все (я работал с кодом таких "брендов" как Analog Devices, Intel, TI, KORG, etc.). Видимо у них ни у кого не было времени почитать александреску (ничего личного)

П>10 лет назад не было GCC 4.x и существующие оптимизаторы действительно не позволяли делать хорошее абстрагирование, не принося в жертву производительность. "Бренды" зачастую очень консервативны, так что это не показатель. Многие "бренды" до сих пор используют ПО управления конвейерами, написанное под DOS. Это не значит, что писать современный код под DOS удобнее, чем под современые ОС.
Ну про брендов — это я в ответ на Александреску.

Сейчас как мне кажется вообще нет проблемы с фронт-эндом — GCC/LLVM можно приспособить для любой платформы, а с кодогенератором проблема будет что с С что с С++ если платформа более менее сложная (например не видел ни разу такого компилятора ни для одной из VLIW платформ, чтобы не приходилось руками код на асме писать)..

В общем embedded она разное, ага.

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

Pzz>Осталось только доказать, что решение задачи с помощью классов однозначно является более простым, чем без них (ура! намечается холовар Си vs C++

)

В приведенном выше примере есть неявные зависимости внутреннего состояния объектов. В варианте с C++ их нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

Pzz>>Осталось только доказать, что решение задачи с помощью классов однозначно является более простым, чем без них (ура! намечается холовар Си vs C++

)

M>В приведенном выше примере есть неявные зависимости внутреннего состояния объектов. В варианте с C++ их нет.

Из существования плохого кода на Си и хорошего на C++ не следует, что Си — плохой язык, а C++ — хороший. Hint: чтобы доказать утверждение о преимуществе C++, опираясь на качество кода, следовало бы доказать, что хорошего кода на Си не бывает, в отличии от. Что, очевидно, является неправильным утверждением.

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

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

H>>Вот вот. Так всегда кажется — сейчас под Win32 отладим, а потом пересоберем "хоть под AVR". Как низкоквалифицированый кодер скажу что так не работает никогда и ни у кого. _Все_ вещи связанные с кодированием и декодированием видео перенесенные на embedded платформы (т.е. там где производительность критична) были написаны на С и оптимизированы вначале именно на С под конкретную платформу. Перенос этого на другую платформу как правило требует архитектурных изменений кода.
П>Я не говорю "спроектировать и написать чисто на Win32, а потом перекомпилять". Я утверждаю, что можно изначально спроектировать систему так, что отладка "бизнес-логики" пройдет на Win32, а под железом останутся вопросы оптимизации и отладки 10% аппаратно-зависимого кода. Приведу пример. Однажды разрабатывал я местячковый такой фреймворк для распределенных вычислений. Среди железных платформ были AVR, AT91SAM7 и т.п. И "изюминкой" проекта был хитрый самосинхронизирующийся протокол обмена данными между контроллерами. На самом начальном этапе проектирования было принято решение сделать самый нижний уровень переключаемым: заменяем BusDriver<AVR::UART1> на BusDriver<Simulator::UART<GlobalUART_A>> и собираем Win32-версию а-ля по потоку на симулируемое ядро. Вот только малая доля багов, обнаруженных в реализации протокола:
П>Забытый вызов функции синхронизации времени
П>Ошибки в последовательности вызова обработчиков транзакций
П>Забытый case в обработчике прерываний от UART

П>Писалось бы все на чистом С и сразу под AVR, каждое из перечисленного приводило бы к ситуации "упс, чаво-то плата зависла, понять бы, какой из контроллеров виноват". В Студии же все баги находились и исправлялись на лету, ибо отладчик с визуализацией типов и всякие перки а-ля отображение timestamp-а в debug name потока упрощают отладку в разы.
П>Подобную абстракцию можно было бы реализовать и на C, но это были бы тонны копипасты и find-and-replace... В "плюсах" же все решается заменой аргумента шаблона...

откуда инфа про тонны копипаста ? обычно так и делается — пишется референсная "заглушка", с ней отлаживается вся архитектура, а потом для каждой конкретной платформы делается оптимизированная версия этой заглушки. и меняется все одним аргументом в функции, который говорит про тип платформы.

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

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

Пример: тонна кода, содержащего вызовы а-ля UART1::ReceiveByte(), UART1::Configure() и т.п. Производительность критична, т.е. передавать номер UART-а аргументом в делать run-time switch-case низзя. pointer call тоже низзя. Надо, чтобы каждый вызов UART1::SendByte(somevar) компилировался в out UDR1, rXX. В C++ объявляем _BusUART шаблонным параметром и вперёд. В Си можно сделать промежуточные #define или inline-функции а-ля BusUART_Send(x) {UDR1 = x;}, но будет 2 проблемы:
1. Надо делать (и менять потом) по функции на метод.
2. Если экземпляров драйвера много (в целях производительности надо физически иметь 2 функции, одну с "out UDR1, rXX" внутри, и вторую с "out UDR2, rYY"), надо делать копипаст руками. В C++ компилятор сам создаст по экземпляру на комбинацию шаблонных аргументов. Если несколько экземпляров не нужно, используем параметры функций вместо шаблонных параметров, код будет меньше, но медленнее.

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

H>Да, в общем-то на С делается две библиотеки — одна AVR_UART, другая Simulator_UART. все отлаживается, переносится и т.д. Но не в том суть.
Тогда будет один глобальный namespace, где одни функции будут от симулятора, другие внутренние (портируемые). Разобраться что где через год после написания можно будет или по именам/комментариям, или смотря, что где объявлено. В C++ это делается средствами языка (один класс для методов симулятора, другой — для UART-а, все обращения явные). Одного взгляда на объявление BusImplementation<Simulator, TransactionInfo> понятно, какие функции берутся от симулятора, и как передается информация о транзакциях. В Си эта информация была бы "размазана" по исходникам и была бы менее явной.

H>Наверное надо сказать, что embedded конечно бывает разное. Например если надо написать хм... браузер или там RSS ридер под S60, то очевидно надо использовать всю мощщььь ООП

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

H>В общем embedded она разное, ага.

Таки да. Каждому подходу ниша найдется

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

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, кстати, знаком не понаслышке. Ну а если начальство как в этом треде типа консервативно и требует, чтобы все собиралось на 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).
Хорошо, я вот в этом посте привел пример, где С++ позволяет без каких-либо потерь писать более компактный и менее подверженный ошибкам код. Ваше мнение по поводу таких ситуаций? Руками КАЖДЫЙ РАЗ писать объявление + 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 задарма не нужен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

П>>- Сообщения об ошибках будут указывать на строку, где этот #define использовался. Понять, где именно косяк, будет нереально без метода тыка.
fk0> Реально для профессионалов, умеющих программировать на C. А не для "мы в институте C++ изучали".
fk0>Для этого есть cc -E или его аналоги.
Реально всё. Можно еще чтобы совсем "для профессионалов" номера строк с ошибками в двоичной системе выводить, "чтобы ламеры не догадались". Только зачем искуственно создавать себе трудности?

П>>- Намного хуже поддержка со стороны IDE в плане code completion при наборе кода этого #define.
fk0> Ты не видел какие "в доменной области" IDE. Лучше б их вообще не было.
Пофиг. 10-строчный скрипт на PERL и чуть-чуть XML-магии и вуаля: Visual Studio дружит с любым портом GCC, как с родным. Уметь надо

П>>- При чем-то нетривиальном вы утонете в генеренных именах а-ля #define
fk0> Ниасилил смысл сказанного.
Ну когда вместо класса с шаблоном пишется один оченьМНОГОстрочный #define, определяющий десяток специализированных функций.

fk0> Не надо сказок. Если при портировании GCC на конкретную платформу забили болт на C++, то его там и не будет.
Будет там C++. Не будет исключений и STL (от которых в embedded толку мало). Все остальное будет. Проверялось лично (на экспериментальном порте GCC, создатели которого забили на C++). Приводи контрпример — скажу command line, решающую проблему.

П>> Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd. в 1987 году и портирован студентом-анонимусом на MS-DOS,
fk0> В том числе и так. И наличие АЦП и нужного числа ножек в нужном корпусе зачастую может оказаться существеннее какого-то там C++.
Поставить второй контроллер, или внешний АЦП: + k$ к себестоимости чипа
Трахаться с неработающим компилятором: +n человеко-месяцев к разработке
Неравенство, думаю, составишь сам.

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

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

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

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

fk0> 2) совершенно не нужно программирование подвышенной сложности, просто потому, что это в итоге оказывается дороже.
Сложность бывает разная. C++, как раз, переносит рутинную сложность с разработчика на компилятор.

Здравствуйте, ПblЩЬХ, Вы писали:

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

П>>>- Намного хуже поддержка со стороны IDE в плане code completion при наборе кода этого #define.
fk0>> Ты не видел какие "в доменной области" IDE. Лучше б их вообще не было.
ПЩЬ>Пофиг. 10-строчный скрипт на PERL и чуть-чуть XML-магии и вуаля: Visual Studio дружит с любым портом GCC, как с родным. Уметь надо

А зачем это надо? Когда тот же eclipse дружит с gcc прямо из коробки. И для работы с микроконтроллерами там готовые аддоны есть. А code complition и source navigation там сделаны на порядок лучше чем в VS.

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

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

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

S>>>Хмм. Странно. У нас сейчас набирали старшего embedded разработчика. Взяли нашего парня за 5.9, Хельсинки. Для разных там базоводов или Вебов зарплата около 5т, т.е. выгода заниматься embedded очевидна.
DM>>В Финляндии? В Финляндии нет как раз нет смысла заниматься не embedded. Зато никаких "финансовых банков" и т.д. просто в принципе нет.
AG>Хочу уточнить: изначально я имел в виду не абстрактно "финансовые банки" а инвестиционные банки и компании, в Москве это Deutsche Bank и UBS.

Московский UBS/DB (это небось Люкс?) — причмокивает у швейцарского UBS во всём, не нагибаясь.

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

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

M>Просветите пожалуйста, каким образом обычно происходит подобный странный переход? Неужели достаточно просто отправить резюме и пройти собеседование? Или всё-таки бывшие эмбедщики получают второе образование? А то в наших Рассеях на меня зачастую косо поглядывают из-за моего эмбедского прошлого...
Есть в финасах области, например high frequency trading, где в первую очередь требуется умение решать нестандартные задачи по оптимизации операционной системы.Или говоря простым языком, делать обработку данных немного быстрей чем у конкурентов.Ну и понятно почему программисты с опытом в embedded наиболее подходят для такой работы.Есть также много и hardware accelerators.Знания в финасах желательно, но в основном эту работу делают другие специальности программистов.Попасть туда очень трудно так, как рынок небольшой, а зарплаты высокие.

Здравствуйте, ПblЩЬХ, Вы писали:

fk0>> Реально для профессионалов, умеющих программировать на C. А не для "мы в институте C++ изучали".
fk0>>Для этого есть cc -E или его аналоги.
ПЩЬ>Реально всё. Можно еще чтобы совсем "для профессионалов" номера строк с ошибками в двоичной системе выводить, "чтобы ламеры не догадались".

Надумано. Есть типовые средства, несколько более классические и не такие модные как eclipse или MSVC. Просто говнокодеры о них не знают, вот и вся правда.

П>>>- Намного хуже поддержка со стороны IDE в плане code completion при наборе кода этого #define.
fk0>> Ты не видел какие "в доменной области" IDE. Лучше б их вообще не было.
ПЩЬ>Пофиг. 10-строчный скрипт на PERL и чуть-чуть XML-магии и вуаля: Visual Studio дружит с любым портом GCC, как с родным.

Чушь. Отлаживать-то в чём? А текст писать можно и в wordpad. Опять же, если школота не умеет -- не показатель.

П>>>- При чем-то нетривиальном вы утонете в генеренных именах а-ля #define
fk0>> Ниасилил смысл сказанного.
ПЩЬ>Ну когда вместо класса с шаблоном пишется один оченьМНОГОстрочный #define, определяющий десяток специализированных функций.

Не нужно так делать. Нормальный define должен быть не более десятка строчек. Равно как и нормальная функция должна влезать если не в экран, то хотя бы в лист бумаги (т.е. где-то 80x65). Если не влезает -- либо очень нужно зачем-то, либо, что скорее, говнокод.

fk0>> Не надо сказок. Если при портировании GCC на конкретную платформу забили болт на C++, то его там и не будет.
ПЩЬ>Будет там C++. Не будет исключений и STL (от которых в embedded толку мало). Все остальное будет. Проверялось лично (на экспериментальном порте GCC, создатели которого забили на C++). Приводи контрпример — скажу command line, решающую проблему.

Microchip C30. Как сделать C++ ? Исходники и т.п. есть, GCC из них пересобран и используется.

Без исключений уже пол-библиотеки скорей не заработает. Вот и получается -- "C с объектами".
Какая связь STL или другой библиотеки с компилятором -- ниасилил.

П>>> Если вы выбрали левую платформу, под которую компилятор написан Changhui ltd. в 1987 году и портирован студентом-анонимусом на MS-DOS,
fk0>> В том числе и так. И наличие АЦП и нужного числа ножек в нужном корпусе зачастую может оказаться существеннее какого-то там C++.
ПЩЬ>Поставить второй контроллер, или внешний АЦП: + k$ к себестоимости чипа
ПЩЬ>Трахаться с неработающим компилятором: +n человеко-месяцев к разработке
ПЩЬ>Неравенство, думаю, составишь сам.

Ага. Поставить второй контроллер -- это другая плата, другой корпус за $$$. Это геморой с софтом, это проблемы со стабильностью работы, это необходимость тестирования пол-года... Наконец это уже закупленные комплектующие на 3 года вперёд и т.п. Хотя я в общем-то согласен, "нанотехнологии" здесь приводят к fail'у IMHO и отсутствие GCC -- показательный критерий. Так что не спорю. Но не всегда возможно тем не менее. И актуально для более-менее больших проектов.

fk0>> 90% так называемых глюков -- квалификация программистов ниже плинтуса. Хотя и глюки бывают замечательные конечно.
ПЩЬ>Ну конечно, хорошие программисты ошибок не делают и пишут сразу в машинных кодах, ага.

Нет, не в кодах. Но ошибок делают на пару порядок меньше.

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

Выложи. И, интересно, почему этот C++ никому поперёк горла обычно не стоит. Некоторые (google CSS C compiler) умудряются продавать нечто вовсе не являющееся языком C и вполне успешно...

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

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

В очень новомодных технологиях есть очень новомодные "аппаратные особенности", такие что враз рисковать расхочется.
Я бы ставил на опробованные другими уже как-минимум в течении года.

fk0>> 2) совершенно не нужно программирование подвышенной сложности, просто потому, что это в итоге оказывается дороже.
ПЩЬ>Сложность бывает разная. C++, как раз, переносит рутинную сложность с разработчика на компилятор.

Лично я не вижу, что он переносит. Если на C++ писать как на C -- никакого переноса нет. Есть только более надёжная проверка типов и некоторый другой улучшайзинг. Качественные изменения начинаются, если на C++ писать не как на C, а как на C++. Но это невозможно в вакууме без библиотек и в урезанном "C с объектами". А если и становится возможно, то очень резко начнёт упираться в аппаратные ограничения: сейчас System On the Chip с более 512КБайт программной памяти -- редкость. Helloworld в linux весит, -static конечно, около мегабайта. Не наводит на размышления? Я могу привести и такие данные: что у новомодных ARM имеем ближе к 8 байт на строку кода (в THUMB, ага GCC), и такой-же показатель у некоторых 8-битных или 16-битных гораздо лучше, чуть ли не в 2 раза (конкретно у microchip C30 для pic24 -- около 5-и байт на строку). И хоть и убогая libc, но зато просто на порядок более лёгкая, чем newlib, особенно для небольших проектов -- весьма существенно. Про boost и в страшном сне не подумать (а вообще неплохо бы в тех 512КБайт ещё приличный кусок и для пользовательских данных оставить...) С оперативной памятью ни разу не лучше -- десятки килобайт. Если писать "как на C++", то тоже не разбежишься. И это -- заметно большие требования C++ программ к памяти -- известный факт. В том числе и поэтому linux и т.п. -- на C.

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

От:	ArtemGorikov	жж
Дата:	04.09.10 06:23
Оценка:

	От:	ArtK
	Дата:	04.09.10 06:33
	Оценка:

От:	ArtemGorikov	жж
Дата:	04.09.10 06:46
Оценка:

	От:	Octothorp
	Дата:	04.09.10 07:45
	Оценка:	+1

	От:	Octothorp
	Дата:	04.09.10 08:00
	Оценка:

От:	Ytz	https://github.com/mtrempoltsev
Дата:	04.09.10 08:01
Оценка:

От:	fk0	https://fk0.name
Дата:	04.09.10 08:47
Оценка:	+1

От:	Pzz	https://github.com/alexpevzner
Дата:	04.09.10 16:30
Оценка:	+2

От:	пыщьх	http://rsdn_user.livejournal.com
Дата:	04.09.10 16:48
Оценка:	+3 -1

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	04.09.10 18:21
Оценка:	+1

От:	Denis Mingulov	http://denis.mingulov.com
Дата:	05.09.10 05:43
Оценка:	+1

	От:	justinian
	Дата:	08.09.10 06:14
	Оценка:	1 (1) -1