Почему гуру выбирают си

> Это ж капля по сравнению с потребностями в Оффтопике...

Да и хрен в почки этому оффтопику :) Мне он не интересен, а вся неинтересная информация, как известно, фильтруется на входе в мозг ;)

Кто за себя радеет, а не за абстрактно-эфемерную державу, работает там, где ему больше нравится.

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

ИМХО как раз наоборот: после некоторого предела, с возрастанием сложности проекта разница трудозатрат в зависимости от применяемого языка нивелируется (чего нельзя сказать о производительности получившейся в результате программы).

ЦеПП имеет встроенные возможности самодокументации (типа перегрузки операторов и ООП) и принудительного следования задуманному дизайну (типа инкапсуляции), что иногда весьма сильно влияет на производительность труда (особенно в команде). Просто сейчас студентов учат думать в терминах ООП, поэтому мало найдется людей, способных кодировать вне этой парадигмы. Лет 20 назад все было ровно наоборот -- впрочем, программирование тогда считалось математической дисциплиной, и студенты были умнее :). Примерно оттуда же идет высокая продуктивность языков сверхвысокого уровня...

> проектом может быть библиотека, которую требуется использовать в разных языках, в этом случае это вполне аргумент.

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

но то, что язык XYZ плохо биндится с C++ - это в первую очередь проблемы XYZ но никак не плюсов.

> Проблемы также могут возникнуть при использовании классов в динамических библиотеках.

примеры? желательно что-то отличное от "как скрестить MSVC и gcc".

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

что с того, что описание STL присутствует в стандарте на язык? assert() то-же входит в стандарты C и C++ - вы им часто пользуетесь?

"не делайте из еды культа" (c).. то, что STL входит в стандарт не делает её автоматически применимой на все случаи жизни. скорее наоборот, то, что зачастую действительно нужно в ней попросту отсутствует. банальный кеш объектов с задаваемой стратегией удаления/выделения объектов, стратегией поиска и тд. и тп.

// wbr

> проектом может быть библиотека, которую требуется использовать в разных языках, в этом случае это вполне аргумент.

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

но то, что язык XYZ плохо биндится с C++ - это в первую очередь проблемы XYZ но никак не плюсов.

> Проблемы также могут возникнуть при использовании классов в динамических библиотеках.

примеры? желательно что-то отличное от "как скрестить MSVC и gcc".

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

что с того, что описание STL присутствует в стандарте на язык? assert() то-же входит в стандарты C и C++ - вы им часто пользуетесь?

"не делайте из еды культа" (c).. то, что STL входит в стандарт не делает её автоматически применимой на все случаи жизни. скорее наоборот, то, что зачастую действительно нужно в ней попросту отсутствует. банальный кеш объектов с задаваемой стратегией удаления/выделения объектов, стратегией поиска и тд. и тп.

// wbr

>Кто за себя радеет, а не за абстрактно-эфемерную державу, работает там, где ему больше нравится.

Нет, не так. Там работают те, для кого держава и родина - понятия абстактные и эфемерные. ;)

>способных кодировать

Каким кодом?

> Каким кодом?

;)

Это уж от мозга зависит. Или даже уровнем ниже...

> но то, что язык XYZ плохо биндится с C++ - это в первую очередь проблемы XYZ но никак не плюсов.

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

> примеры? желательно что-то отличное от "как скрестить MSVC и gcc".

А почему отличное? Вот есть mozilla, в ней можно делать XPCOM-компоненты - DLL-ки, в которых используются классы. Т.к. обычно фаерфокс собирается MSVC++, другим компилятором эти XPCOM не собрать. По-моему вполне себе проблемы. Естественно при использовании одного компилятора ничего не проявится.

> assert() то-же входит в стандарты C и C++ - вы им часто пользуетесь?

Да, а что? Им удобно самодокументировать код - выделять контракты и инварианты.

> то, что STL входит в стандарт не делает её автоматически применимой на все случаи жизни

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

Кстати какая библиотека может предложить что то удобнее STL?

> Если бы у плюсов был бы бинарный стандарт, которого все компиляторы придерживались - проблем бы не возникало.

даже при отсутствии стандарта на ABI в подавляющем большинстве случаев проблем не возникает. варианты "как присобачить С++ к хреновине XYZ" явно в глубоком миноре и, боюсь, в силу хотя бы этого факта особого внимания не заслуживают. на уровне "ах если бы..!" но не более.

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

не понял этого замечания, поясните. если мне не изменяет память, ещё сегодня утром C++ умел оперировать указателями и имел поддержку указателей на функции. что-то поменялось?

>> примеры? желательно что-то отличное от "как скрестить MSVC и gcc".
> А почему отличное?

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

> Вот есть mozilla, в ней можно делать XPCOM-компоненты - DLL-ки, в которых используются классы. Т.к. обычно фаерфокс собирается MSVC++, другим компилятором эти XPCOM не собрать. По-моему вполне себе проблемы. Естественно при использовании одного компилятора ничего не проявится.

почему не собрать всё одним компилятором - и мастера и компоненты? все в ваших руках.

будут ещё примеры?

>> assert() то-же входит в стандарты C и C++ - вы им часто пользуетесь?
> Да, а что? Им удобно самодокументировать код - выделять контракты и инварианты.

--- cut ---
DESCRIPTION
If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all. Otherwise, the macro assert() prints an error message to standard error and terminates the program by calling abort() if expression is false (i.e., compares equal to zero).
--- cut ---

и того, поведения два:
а) ошибка игнорируется
б) программа вылетает в корку по abort()

скажите, я правильно понял что это ваш обычный метод обработки ошибочных ситуаций?

> Кстати какая библиотека может предложить что то удобнее STL?

что-то можно почерпнуть из boost, что-то из ACE, что-то из внутренних фреймворков типа [они всегда есть]. но более-менее сложные структуры данных с заданными характеристиками зачастую приходится делать руками бо универсальных решений на все случаи жизни просто не существует. впрочем, даже для среднего программиста, освоившего Кнута это не есть какая-то сверхзадача требующая массы сил и времени.

// wbr

> не понял этого замечания

Я имел в виду язык, из которого хочется юзать С++ библиотеку. D например.

> почему не собрать всё одним компилятором - и мастера и компоненты? все в ваших руках.

Потому что мастера собираю не я, а mozilla foundation. И указывать в требованиях для своего Extension-а "download firefox from vasya.pupkin.com/firefox/" не принято :)

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

Это один из способов. Им удобно пользоваться, когда ошибка не должна возникнуть по вине пользователя, т.е. она сигнализирует, что алгоритм программы некорректен. В managed средах потребность в assert-е меньше, т.к. там отслеживаются выходы за границы массива, разыменование null-а и т.д., но в С++ это всё undefined behaviour (а ля сегфолт или расстрел стека) и в этом случае assert помогает быстрее найти источник бага.

>Extension-а

Помогаю - "расширения" по-русски. ;)

> Я имел в виду язык, из которого хочется юзать С++ библиотеку. D например.

ну побрился D, c'est la vie. или делайте C wrapper если уж так необходимо их скрестить.

> Потому что мастера собираю не я, а mozilla foundation. И указывать в требованиях для своего Extension-а "download firefox from vasya.pupkin.com/firefox/" не принято :)

// wbr

> и в этом случае assert помогает быстрее найти источник бага.

Кстати, верно я понял, что удаленная отладка корки в gdb на данный момент невозможна?

> Я имел в виду язык, из которого хочется юзать С++ библиотеку. D например.

ну побрился D, c'est la vie. или делайте C wrapper если уж так необходимо их скрестить.

> Потому что мастера собираю не я, а mozilla foundation. И указывать в требованиях для своего Extension-а "download firefox from vasya.pupkin.com/firefox/" не принято :)

и что мешает собрать своё расширение тем-же инструментарием, которым собирается официальный FF?

> Это один из способов.

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

> Им удобно пользоваться, когда ошибка не должна возникнуть по вине пользователя, т.е. она сигнализирует, что алгоритм программы некорректен.

вы считаете, что отстрел всей системы в момент обнаружения ошибки *самой системой* - это правильно?

> В managed средах потребность в assert-е меньше, т.к. там отслеживаются выходы за границы массива, разыменование null-а и т.д., но в С++ это всё undefined behaviour (а ля сегфолт или расстрел стека) и в этом случае assert помогает быстрее найти источник бага.

культура проверять все данные которыми манипулирует система уже не в моде?

ps: да, я вдоволь насмотрелся на решения, где assert (его вариации) были в почёте. причём что они по-идее они должны работать 24x7. за такое нужно... не к ночи будет сказано :-/

// wbr

> вы видимо никогда не встречали серверного сетевого ПО, спокойно обрабатывающего миллионы весьма нетривиальных транзакций в минуту с требованиями 24x7x386.. :))) угадайте, на чем оно написано? явно не на C и не на Java...

Как же-с, встречали-с и на PL/1 изваянное, и на MACRO бывало-с. И на С встречается иногда-с.

Хе-хе, в двух местах, где я работал full-time разработчиком использовался Linux:) Причём проблемы найти работу у меня не было. А судить по рынку ПО по job.ru -это себя не уважать:)

>вы считаете, что отстрел всей системы в момент обнаружения ошибки *самой системой* - это правильно?

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

"вы видимо никогда не встречали серверного сетевого ПО, спокойно обрабатывающего миллионы весьма нетривиальных транзакций в минуту с требованиями 24x7x386.. :))) угадайте, на чем оно написано? явно не на C и не на Java..."

+1 солидарен

> вы видимо никогда не встречали серверного сетевого ПО, спокойно обрабатывающего миллионы весьма нетривиальных транзакций в минуту с требованиями 24x7x386.. :))) угадайте, на чем оно написано? явно не на C и не на Java...

А вот если бы писали на С или на Java, то в году у вас было бы правильное количество дней...

>А вот если бы писали на С или на Java, то в году у вас было бы правильное количество дней...

если бы оно было бы написано на яве, то даже core2duo не вытянул бы

> Если бы у плюсов был бы бинарный стандарт, которого все компиляторы придерживались

Стандарт есть. В Линуксе. насколько я знаю, его придерживаются все компиляторы. А проблемы Винды и Микрософта - это не проблемы языка.

Единственная реальная проблема Си++ - это его подавляющая сложность (вполне объяснимая историей развития языка). Но, поскольку Си++ имеет в себе весь Си (ОК, C89), я просто не вижу смысла писать на "чистом" Си (за исключением сильно специализированных задач типа ядра).

>Стандарт есть. В Линуксе. насколько я знаю, его придерживаются все компиляторы.

в Линуксе по факту только один си++ компилятор - g++, и врядли появится конкурент.

>> ..24x7x386..
> А вот если бы писали на С или на Java, то в году у вас было бы правильное количество дней...

khm... это видимо уже привычка ;) бывают года, в которых и по 486 и 586 и даже 686 дней...

// wbr

> Вообще говоря, мои рассуждения касались общего прикладного и системного софта (уж во всяком случае не программистов микроконтроллеров), и конкретно противопоставления Си и Си++. Про Жабку я вспомнил просто потому, что Жабкин путь -- это путь ЦеПП, доведенный до абсурда.

Непонятно противопоставление "профессионалов-системщиков, пишущих на C" и "всяких околоприкладников".

Для справки - "системный программист" - это человек, который пишет программные системы общего назначения (библиотеки, "фреймворки"), а не только разработчик ОС. А прикладной - который с помощью этих систем решает задачи предметной области. Т.е. авторы, скажем, Tomcat-а (это Java, если что) или даже Django (это вообще Python) или даже ваще Prototype (это аж JavaScript) - системные программисты, потому что они создают API. А, скажем, дровописатели и большинство программистов микроконтроллеров - скорее прикладные, потому что они используют API ядра для решения конкретной задачи с конкретным железом.

Да, а на C писать на самом деле сложные системы (ядро ОС - недостаточно сложная, выкиньте дрова - там останется не так уж много) нелегко. Уж точно не легче, чем на крест-крест.

> в Линуксе по факту только один си++ компилятор - g++

Вообще-то есть Intel C++, и Comeau еще используется. Но если g++ и в самом деле только один, это только упрощает ситуацию :)

> Непонятно противопоставление "профессионалов-системщиков, пишущих на C" и "всяких околоприкладников".

А что тут непонятного?

> Для справки - "системный программист" - это человек, который пишет программные системы общего назначения (библиотеки, "фреймворки"), а не только разработчик ОС. А прикладной - который с помощью этих систем решает задачи предметной области.

Совершенно верно.

> Т.е. авторы, скажем, Tomcat-а (это Java, если что) или даже Django (это вообще Python) или даже ваще Prototype (это аж JavaScript) - системные программисты, потому что они создают API.

Полностью согласен. Но Жабка идет своим путем, а я противопоставлял Це и Кресты.

> А, скажем, дровописатели ... - скорее прикладные, потому что они используют API ядра для решения конкретной задачи с конкретным железом.

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

Про программистов микроконтроллеров -- отдельная история; я вообще не стал бы делить их на системщиков и прикладников.

> ...на C писать на самом деле сложные системы (ядро ОС - недостаточно сложная, выкиньте дрова - там останется не так уж много) нелегко. Уж точно не легче, чем на крест-крест.

Я уже озвучивал свои мысли по этому поводу. На Крестах ДЕ ФАКТО писАть сложные программы легче просто потому, что последние 20 лет студентов учат именно этому (ООП). В общем случае разницы в трудности разработки сложных систем не будет.

> Я уже озвучивал свои мысли по этому поводу. На Крестах ДЕ ФАКТО писАть сложные программы легче просто потому, что последние 20 лет студентов учат именно этому (ООП). В общем случае разницы в трудности разработки сложных систем не будет.

все понятно, кроме пожалуй одного: мне то, как пользователю и C и C++ какое дело до того, чему учат студентов последние 20 лет? если честно, от того, что их возможно "этому ООП" лично мне не горячо ни холодно и как можно строить свое личное мнение о применимости инструмента к той или иной задачи мне не совсем понятно. в конце-концов применять его [или не применять] буду я а не какие-то абстрактные студенты которых кто-то где-то чему-то учит.

// wbr

> если подходить , учитывая реалии российского рынка труда ,

> то ситуация на 2007-й год складывается такая : если вы профи ,

> но знаете только це , работу вам будет найти нереально сложно

>почему ?потому что в россии не разрабатывают системный софт

Не совсем так. В России много аутсорса. Очень много проектов, которые отдают нам буржуи, как раз требуют знания С, Unix. Например, у нас в основном все пишется на чистейшем С.

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

> Не совсем так. В России много аутсорса. Очень много проектов, которые > отдают нам буржуи, как раз требуют знания С, Unix. Например, у нас в > > основном все пишется на чистейшем С.

тем более что я например не могу представить себе профессионального программиста, который действительно знает только C :) по крайней мере все, кого я могу назвать профи [>10..15лет опыта и десятки успешно завершённых сложных проектов] свободно владеют как минимум десятком различных инструментов, по ходу наработки опыта лишь увеличивая это число хотя это отнюдь не самоцель и C лишь один из них.

ну а "профи, который знает только C"... хм. такой вот профи, селяви :)

// wbr

> мне то, как пользователю и C и C++ какое дело до того, чему учат студентов последние 20 лет? если честно, от того, что их возможно "этому ООП" лично мне не горячо ни холодно и как можно строить свое личное мнение о применимости инструмента к той или иной задачи мне не совсем понятно. в конце-концов применять его [или не применять] буду я а не какие-то абстрактные студенты которых кто-то где-то чему-то учит.

1. Просто иллютрация возможных источников расхождений в жизненном опыте.

2. Сложные проекты обычно командой делаются. Сейчас трудно набрать команду, в которой каждый член не был бы привязан к конкретной парадигме (ООП, вебсервисы, интерпретаторы, лямбда, etc). В лучшем случае идет тотальная апелляция к DSL ("каждой (под)задаче -- свой язык"). Мыслить абстрактными категориями современные программисты увы, не умеют -- "не математики, чай; не в игрушки играем!".

> ...не могу представить себе профессионального программиста, который действительно знает только C :)

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

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

как всегда =)

> я например не могу представить себе профессионального программиста, который действительно знает только C.

Знать по книжкам одно, иметь профессиональный опыт - другое. Если нравится, можно долго и плодотворно писать на С - без работы не останешься :)

> Не совсем так. В России много аутсорса. Очень много проектов, которые отдают нам буржуи, как раз требуют знания С, Unix. Например, у нас в основном все пишется на чистейшем С.

ps: соглашусь, что и внешних проектов то-же более чем хватает. трудно сказать, что "мол у нас по *NIX ноль а у буржуев - море" и делать из этого глобальные [печальные] выводы о распространённости скажем Linux здесь и там. IMHO это неверная предпосылка хотя бы исходя из того простого факта, что объем работы в Силиконовой Долине (нет, не в Кремниевой) на порядки превышает всю работу на просторах РФ включая Москву. банальный объем давит :) так что грамотный программист с опытом работы, достаточно широким кругозором в силу п.1 и специализацией допустим на серверных решениях под *NIX на базе C/C++ (sic! оба!) с приемлемым знанием английского ещё очень долго будет желанным гостем на этом празднике жизни.

// wbr

> Стандарт есть. В Линуксе. насколько я знаю, его придерживаются все компиляторы. А проблемы Винды и Микрософта - это не проблемы языка.

Ну хорошо. А если взять *BSD, Solaris, AIX и много чего еще -- там тоже все придерживаются?

> Ну хорошо. А если взять *BSD, Solaris, AIX и много чего еще -- там тоже все придерживаются?

а чем отличаются компиляторы C++ в Linux и *BSD? ;)

// wbr

> > Непонятно противопоставление "профессионалов-системщиков, пишущих на C" и "всяких околоприкладников".

> А что тут непонятного?

Во-первых, это на 80% одни и те же люди; во-вторых, прикладные программы потенциально (а даже в реальности часто) сложнее (структурно, в первую очередь - ибо реальный мир) системных. Ну типа как Office (не важно, MS или Open) сложнее оконной системы, на которой они работают.

> > > А, скажем, дровописатели ... - скорее прикладные, потому что они используют API ядра для решения конкретной задачи с конкретным железом.

> > Абсолютно неверно. Конечным результатом их деятельности является предоставление АПИ для прикладников, так что они, все же, системщики. То, что они в свою очередь тоже опираются на АПИ -- следствие элементарного разделения на уровни.

Не в этом дело. Системщики - это те, кто _создает_ API. А у драйвера и "входное" и "выходное" API заранее фиксированы, его задача, на самом деле, - только с устройством общаться

> > ...на C писать на самом деле сложные системы (ядро ОС - недостаточно сложная, выкиньте дрова - там останется не так уж много) нелегко. Уж точно не легче, чем на крест-крест.

> Я уже озвучивал свои мысли по этому поводу. На Крестах ДЕ ФАКТО писАть сложные программы легче просто потому, что последние 20 лет студентов учат именно этому (ООП). В общем случае разницы в трудности разработки сложных систем не будет.

Ну возможно. Гном-гимп, кстати, тому живые примеры.

Баклан. Сравни С++ c Objective C сам всё поймеш.

Re: Почему гуру выбирают си >>и не смотреть на убогость ООП в с++? >Мухаха! Это пять! Автор болен. Автор не болен, ООП в С++ убог, сравни плюсы хотя бы с SmalTalk или Objective C (Скажем возможностей ООП в С++ уже нехватает что-бы писать библиотеки для GUI, MacOS X тому подтверждение, команда Apple пошла более правильным путем - в Objective C более грамотный ООП подход)

>>ООП - оно в мозгах, а не в языке. Полностью солидарен, обьектно ориентированным подходом можно практически на любом языке действовать, независимо есть ли в языке поддержка.

>>Но не могу понять почему, на книжных полках просто завал языков с++ и ужасно мало про "чистый" Си? Потому что С++ очень и очень сложный язык со многими тонкостями.

>Также, пусть тебя не вводит некоторое сходство в названих языков. Это >два _совершенно разных_ языка программирования. Не считая "бонуса", >что C являтеся почти-что подмножеством C++. С никогда не являлся подмножеством С++ (Даже тов. Страуструп приводит примеры кода на С который не укладываются в семантику С++ и не компилируются компилятором С++)

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

С уважением, vertur.