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

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

П>Хорошо, я вот в этом посте

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

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

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

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

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

П>>Хорошо, я вот в этом посте

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

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

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

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

Вы совершенны правы, это относится как то к примеру который рассматривался ?

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

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

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

fk0> Без исключений уже пол-библиотеки скорей не заработает. Вот и получается -- "C с объектами".
Шаблоны и RAII прекрасно работают без исключений. Ну а С с классами уже позволяет больше чем просто С.

fk0> Лично я не вижу, что он переносит. Если на C++ писать как на C -- никакого переноса нет. Есть только более надёжная проверка типов и некоторый другой улучшайзинг. Качественные изменения начинаются, если на C++ писать не как на C, а как на C++.
Ясно. Ещё один, который под "писать на С++" понимает исключительно как использование сразу всего, что позволяет язык.
Это крайне неправильное представление.
Писать на С++ означает использование только того функционала языка С++, который реально полезен и уместен для решения конкретной задачи.