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

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

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

Здравствуйте, 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, которые генерят хреновый код.

Здравствуйте, 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.). Видимо у них ни у кого не было времени почитать александреску (ничего личного)

П>90% "сложностей" решается абстрагированием от железа и проверкой (отладкой) алгоритмов на Win32/Visual Studio. Потом ТОТ ЖЕ код пересобираем хоть под AVR. Template + inline позволяет делать это без runtime overhead. Если писать на plain 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... В "плюсах" же все решается заменой аргумента шаблона...

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++ их нет.

Здравствуйте, 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 она разное, ага.
Таки да. Каждому подходу ниша найдется