[sasamy 0]

Писали на нем что нибудь объемное?

 

Объемное - нет и не собираюсь.

http://sasamy.narod.ru/l4fiasco_at91.patch.gz

 

1) На ассемблере+фортране в своё время было написано столько («практически все ОС написаны на ассемблере», на С только одно вон то), что с Вашими аргументами С нужно было убить сразу.

 

Тут ключевое слово - было, на С и С++ пишут сейчас.

 

2) Сначала покажите хотя бы один пример, где С++ во многих случаях уступает ему (С) при этом.. «А то языком чесать...». Вы замахнулись на «объективную» оценку, тогда как малая распространённость С++ в МК, на мой взгляд, имеет в основе скорее субъективный фактор. Вот и докажите конкретным примером «уступания», что это таки объективные причины имеет.

 

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

[ReAl 0]

Тут ключевое слово - было, на С и С++ пишут сейчас.

Было время, когда в тогдашнее «сейчас» писали на асме и фортране, а С только появился. Тогда было «на асме, фортране и С пишут сейчас». И тогда было «большинство ОС написаны на асме, прикладного софта — на асме и фортране». С уже существовал. Вот тогда его и надо было Вашими аргументами убить.

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

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

мне достаточно того что С++ не имеет никаких преимуществ при этом очень сложен, чтобы стать хорошим программистом С++ нужен не год и не два.

могу только процитировать «и то, и другое я видел не раз — кого ты хотел удивитть?» (в смысле точно такой же аргумент, только без символов ++ и против С, а не за него, — я уже слышал).

 

Во многих случаях - это я хватанул конечно :)

Я прошу один, в котором язык С++ уступает. «он слишком сложен» — не катит. Хотя бы потому, что он уже применялся против С, а не за него. И потому, что многие пользующиеся С сейчас — так его толком и не знают (надо-то тоже «не год, и не два»).

А если ограничиться частью С++, то тоже не так и сложно. У меня же кое-что получается :-)

[toweroff 1]

sasamy,

вот у меня в соседней ветке конкретный вопрос

 

сам давно (очень) делал на плюсах, сейяас просто C, поэтому задал там вопрос

 

мой вопрос здесь, т.к. Вы можете подсказать решение и определиться мне - так или эдак

[sasamy 0]

могу только процитировать «и то, и другое я видел не раз — кого ты хотел удивитть?» (в смысле точно такой же аргумент, только без символов ++ и против С, а не за него, — я уже слышал).

 

Чего вы привязались к этому C++ ? Я естественно не авторитет в выборе языка и высказываю свое мнение, но если интересно - например не новичек в C/C++ и действительно авторитетный человек вот что говорит:

 

http://www.minix3.ru/articles/Tanenbaum_interview_en.html

Why is it C chosen as the language of development? Is transition to C++ or other object-oriented languages possible?

 

We started in C in 1987. C++ was not very widely used then. It is more legacy than ideology. If we transitioned, it would probably be to cyclone.

 

Язык программирования Cyclone

Изменено 22 декабря, 2011 пользователем sasamy

[ReAl 0]

Чего вы привязались к этому C++ ?

Это мы привязались? Прозвучало как «пошла ты нафиг со своим утюгом» из анекдота.

 

и высказываю свое мнение

«мнения» бывают разные. Одно дело «мне язык не нравится, какой-то он перенавороченный» — это оценочное суждение и, вопрос вкусовой.

Но

По сути С++ дублирует функционал С и во многих случаях уступает ему при этом.

это уже конкретное обвинение. Потрудитесь обосновать. Не переводя стрелки на Cyclone или, скажем, D, который мне импонирует.

 

не новичек в C/C++ и действительно авторитетный человек вот что говорит:

http://www.minix3.ru/articles/Tanenbaum_interview_en.html

Why is it C chosen as the language of development? Is transition to C++ or other object-oriented languages possible?

 

We started in C in 1987. C++ was not very widely used then. It is more legacy than ideology. If we transitioned, it would probably be to cyclone.

Он говорит, что С++ не был выбран потому, что тогда, в 1987, он еще не слишком широко использовался (от меня: да и был он тогда ещё без многих современных возможностей, хотя многое из ручной работы уже автоматизировал). И что это у него была больше дань традиции, чем идеологии. И что если он когда-то будет куда-то переходить, то это будет С-клон. Т.е. конкртеное решение конкретного человека в конкретных условиях. И ни слова не сказал о том, что ему не нравится С++ чем-то конкретным. «It is more legacy than ideology»

 

Теперь передвинем этот текст на пол-периода в прошлое, другие люди и другой проект. И получим что-то в духе

 

— Почему как язык разработки был выбран Фортран? Собираетесь ли вы переходить на другой язык, например, С?

— Мы начинали в 1975. С ещё мало был тогда распространён. Если мы когда-то перейдем, то, возможно, на ADA

Было бы это аргументом против С в 1985 году?

 

А если я теперь против Cyclone применю ваш аргумент?

«Приведите мне примеры ОС, для микроконтроллеров и малых микропроцессоров, написанные на С-клоне. А вот на С++ больше написано»

Вы сможете защитить С-клон?

 

С++ хоть и давно существует, но в embedded-области еще новичок. Как бы «только-что появился», так как процессоры, применяемые в этой области, только стали подтягиваться к достаточному уровню.

 

Ситуация очень похожа на положение С в embedded 15-20 лет назад. К тому моменту С уже давно существовал и прочно сидел в области «больших» процессоров. Но для «мелочи» частично не пролазил по объёмам ОЗУ/ПЗУ, частично — по (не)привычке, инерции и «неосвоенности». И когда уже разобравшиеся с ним за него агитировали — против С звучало всё то же, что тут прозвучало против С++. И до крайностей в духе

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

 

И звучало, даже с линками на зачаточные компиляторы, такое:

— вот если бы Модула, или хотя бы Паскаль нормальный, вот это да...

 

Так и где сейчас в нашей области модула с паскалем? Насколько много осталось ассемблера? А где С?

Вот доживём, посмотрим на С-клона в сравнении с С++.

Если микро-дот-нет не задавит обоих :-)

 

p.s. Когда почти 15 лет назад в упомянутой RU.EMBEDDED dxp уже начинал говорить о С++ — я тоже слушал недоверчиво :-)

 

[sasamy 0]

Это мы привязались? Прозвучало как «пошла ты нафиг со своим утюгом» из анекдота.

 

Под "привязались" я имел ввиду что вы уцепились за С++ как за панацею и явно ожидаете что в ближнем будущем все будут писать на С++ как сейчас на С.

 

Потрудитесь обосновать.

 

Скажем макросы - мощнейший инструмент кодогенерации в С и головная боль в С++

 

Он говорит...И ни слова не сказал о том, что ему не нравится С++ чем-то конкретным. «It is more legacy than ideology»

 

На вполне конкретный вопрос про С++ он ответил что сегодня если бы и стал переходить то на cyclon - я специально ссылку дал - это все тот же старый добый С но который реально решает проблемы безопасности кода и С++ там даже близко не пахнет так как он ни одной этой проблемы не решает.

 

[Сергей Борщ 141]

Скажем макросы - мощнейший инструмент кодогенерации в С и головная боль в С++

Потрудитесь развернуть свою мысль. В чем именно головная боль?

[sasamy 0]

Потрудитесь развернуть свою мысль. В чем именно головная боль?

 

Потрудитесь книжки почитать

http://www.programmer-lib.ru/cstandart_page.php?id=9

[neiver 0]

Макросы в голом Си настолько-же опасны как и в С++, но в последнем есть возможность их много реже использовать:

- типизированные константы;

- inline функции;

- шаблонные функции;

- шаблоны классов.

Эти возможности успешно заменяют макросы и превосходят их в 99% случаев.

Но в 1% макросы нужны и в С++, поэтому они в нем есть.

[GenaSPB 11]

Это был Василевский. :)

Вот эта часть цитаты

При написании больших программ на ассемблере рано или поздно приходится делать некие соглашения о вызовах, распределении регистров

автор - я.

[dxp 65]

Потрудитесь книжки почитать

http://www.programmer-lib.ru/cstandart_page.php?id=9

По ходу, автор ссылки сам текст по ней не читал, ибо там чётко и конкретно сказано:

Макрос — самый неприятный инструмент С и C++, оборотень, скрывающийся под личиной функции, кот, гуляющий сам по себе и не обращающий никакого внимания на границы ваших областей видимости. Берегитесь его!

<...>

Мне не нравится большинство видов препроцессоров и макросов. Одна из целей C++ — сделать препроцессор C излишним (§4.4, §18), поскольку я считаю его большой ошибкой.

 

Макросы почти никогда не являются необходимыми в C++. Используйте const (§5.4) или enum (§4.8) для определения явных констант [см. рекомендацию 15], inline (§7.1.1) для того, чтобы избежать накладных расходов на вызов функции [но см. рекомендацию 8], template (глава 13) для определения семейств функций и типов [см. рекомендации с 64 по 67], и namespace (§8.2) для того, чтобы избежать конфликтов имен

 

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

Т.е. опять всё наоборот: заявлено, что в С макросы - могущество, а в С++ - геморрой (хотя и там, и там макросы - суть одно и то же, потому и могущество с геморроем несут одинаковое), а по ссылке чётко и конкретно сказано, что как раз-таки в С++ проблема с макросами решена на 99% именно средствами языка.

 

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

[ViKo 1]

А за сайтик http://www.programmer-lib.ru - спасибо!

[sasamy 0]

Эти возможности успешно заменяют макросы и превосходят их в 99% случаев.

 

Эти возможности вообще нихрена не могут в кодогенерации по сравнению с макросами

 

#define CMDLINE_DEVICE_CHOOSE(name, dev1, dev2)                 \
        static char *cmdline_device_##name;                     \
        static int cmdline_device_##name##_setup(char *dev)     \
        {                                                       \
                cmdline_device_##name = dev + 1;                \
                return 0;                                       \
        }                                                       \
        __setup(#name, cmdline_device_##name##_setup);          \
        void mx23_init_##name(void)                             \
        {                                                       \
                if (!cmdline_device_##name ||                   \
                        !strcmp(cmdline_device_##name, #dev1))  \
                                mx23_init_##dev1();             \
                else if (!strcmp(cmdline_device_##name, #dev2)) \
                                mx23_init_##dev2();             \
                else                                            \
                        pr_err("Unknown %s assignment '%s'.\n", \
                                #name, cmdline_device_##name);  \
        }

CMDLINE_DEVICE_CHOOSE(ssp1, mmc, spi1)

 

Т.е. опять всё наоборот: заявлено, что в С макросы - могущество, а в С++ - геморрой

 

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

Изменено 22 декабря, 2011 пользователем sasamy

[syv 0]

....

ПМСМ, разногласия С-филов и С++-филов не отражают ничего, кроме разницы в характерах самих оппонентов.

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

С++ характерен тем, что гораздо более полно отражает кактусы, пустившие корни в голове программиста.

И если кто-то классифицирует (в смысле С++) объект так-то и так-то, то другой может и не разобрать то, что наворотил первый.

Поскольку имеет свои представления об этом же объекте.

В корне отличающиеся от представлений первого.

Чтобы не быть голословным, попрошу уважаемое сообщество создать класс "машины электрические".

А там посмотрим - у кого что выйдет...

 

[dxp 65]

ПМСМ, разногласия С-филов и С++-филов не отражают ничего, кроме разницы в характерах самих оппонентов.

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

Это вряд ли. Скорее это зависит соотношения "сложность задач/доступные ресурсы (время/трудоёмкость). Попробуйте, например, GUI написать на С и С++, разницу поймёте сразу.

 

С++ характерен тем, что гораздо более полно отражает кактусы, пустившие корни в голове программиста.

И если кто-то классифицирует (в смысле С++) объект так-то и так-то, то другой может и не разобрать то, что наворотил первый.

Поскольку имеет свои представления об этом же объекте.

В корне отличающиеся от представлений первого.

Тут уместно другое сравнение. Вот в С структуры уместно использовать? Ну, чтобы вместо использования пачки связанных по контексту задачи переменных упаковать их в структуру. Упрощает работу с данными - согласитесь, что работать с таким агрегатным объектом много удобнее - вместо нескольких мелких сущностей получаем одну более крупную. Когда подобных объектов в программе набирается с полдюжины, то структуры вообще начинают рулить (на любом языке, кстати - вон в SystemVerilog есть поддержка структур, так они очень сильно облегчают работу по сравнению с классическим Verilog'ом).

 

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

 

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

 

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

 

Чтобы не быть голословным, попрошу уважаемое сообщество создать класс "машины электрические".

А там посмотрим - у кого что выйдет...

Вы слишком общо задали условия. Уточните, что должны делать оные "электрические машины", какие общие и частные свойства иметь, как применяться?