во первых, Юникс вей все таки тяготеет к простым решениям. Компилятор Си++ реализовать гораздо нетривиальнее чем Си.
во вторых, Юникс вей тяготеет к четкому выделению слоев везде где их можно выделить. Четко выделяется два слоя -- портабельный ассемблер, и слой сверху -- средства метапрограммирования поверх него -- например препроцессор. Иметь четко выделенный слой портабельного ассемблера очень хорошо -- например если нужно делать какую-нибудь работу с кодом на метауровне. Например инструментировать его как-то, или исследовать поведение кода на машине с разными параметрами кэша и т.п. Инструментировать Си++ код это каторга.
Не пойму к чему ты клонишь. Си++ есть надмножество Си. За исключением некоторых нюансов, полностью совместим с его синтаксисом. Си++ унаследовал от Си все низкоуровневые возможности. Плюс классы, гибкие средства определения новых типов, абстракция данных, а также более логичный синтаксис.
Если правильно использовать все преимущества Си++, получаются более компактные, легко сопровождаемые программы. В частности если речь идёт об абстракции.
> во первых, Юникс вей все таки тяготеет к простым решениям. Компилятор Си++ реализовать гораздо нетривиальнее чем Си.
А интерпретатор бейсика сделать проще, чем компилятор С и ...?
> во вторых, Юникс вей тяготеет к четкому выделению слоев везде где их можно выделить. Четко выделяется два слоя -- портабельный ассемблер, и слой сверху -- средства метапрограммирования поверх него -- например препроцессор. Иметь четко выделенный слой портабельного ассемблера очень хорошо -- например если нужно делать какую-нибудь работу с кодом на метауровне. Например инструментировать его как-то, или исследовать поведение кода на машине с разными параметрами кэша и т.п. Инструментировать Си++ код это каторга.
С++ лучше "выделяет слоя", чем С. В С у вас, по сути, одно глобальное пространство имен, которое со временем превращается в кашу (static не сильно спасает).
С++ добавляет слои "классы" и слои "пространства имен".
Так что, С++ - это более "Юникс вей", чем С.
>В большистве случаев я со столлменом не согласен(хотя конечно уважаю и
его и его точки зрения), но тут он сделал совершенно правильно ..
Настолько, что пишешь его имя с маленькой буквы? ;)
Мне не нравится, что он смешивает "политику" и личные пристрастия.
Половина GNU-софта написана на C++. Покажите хоть один браузер, написанный на С?
Так что недооценивает он С++.
> Настолько, что пишешь его имя с маленькой буквы? ;)
:) ну да ладно придиратся ..
> Мне не нравится, что он смешивает "политику" и личные пристрастия.
> Половина GNU-софта написана на C++. Покажите хоть один браузер,
> написанный на С? Так что недооценивает он С++.
dillo, w3m (который я и пользую), .. да малоли еще, C не предназначен
для таких вещей .. вообще gui на C писать это изврат ..
был случай когда библиотеки для моделирования кое-чего переписывались на C (это еще в Досе и OS/2). Как сказал один из программеров (сейчас он за бугром - после защиты диссертаци свалил), причина того, что они так поступили в том, что если в программе, написанной на C++ слетит базовый класс, то накрывается вся программа (я ни хрена из этой фразы не понял, надеюсь тут присутствующие анонимусы разъяснят подробнее). Программы у них обычно считали месяца по три без остановки.
очень просто. Юникс это не богатая система. Юникс в некоторых вещах предпочитает быть убогим но "правильным".
Общепринято что ОС и языки это параллельно-перпендикулярные сущности. То что система написана на Си не существенно. Ассемблер в системе это все равно машинный ассемблер. Но в Юниксе, во всяком случае по задумке, ассемблером должен являться Си. В Юникс, просто по дизайну должен быть портабельный ассемблер. Во первых плюсов тогда не было. Во вторых плюсы все равно не годятся на роль ассемблера.
"Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."
>"Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."
Самый лучший способ повысить затраты на сопровождение проекта - написать его на нескольких языках.
> "Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."
если это противопоставлялось тому что я написал, то это неправильно.
Я сам пишу на Си++ и на шелле. Наличие и четкое выделение портабельного ассемблера не означает что на нем нужно непосредственно писать. Все профессиональные программисты делают свои языки для своих проектов -- например набор макросов, и библиотек это и есть свой язык. Естественно что поверх ассемблера ты выстраиваешь скриптовую надстройку.
>очень просто. Юникс это не богатая система. Юникс в некоторых вещах предпочитает быть убогим но "правильным".
Unix - богатая система. Убогой ее делает такое стремление к призрачной "правильности".
>Общепринято что ОС и языки это параллельно-перпендикулярные сущности. То что система написана на Си не существенно. Ассемблер в системе это все равно машинный ассемблер. Но в Юниксе, во всяком случае по задумке, ассемблером должен являться Си. В Юникс, просто по дизайну должен быть портабельный ассемблер. Во первых плюсов тогда не было. Во вторых плюсы все равно не годятся на роль ассемблера.
Я знаю, что по задумке ассемблером для юниксов должен быть С.
И также знаю, где все эти юниксы сейчас.
Линукс будет там же, если захочет быть "правильным".
Выводы делайте сами.
>Все профессиональные программисты делают свои языки для своих проектов -- например набор макросов, и библиотек это и есть свой язык. Естественно что поверх ассемблера ты выстраиваешь скриптовую надстройку.
Ужас.
Не хотел бы я ваш проект потом сопровождать :)
Помоему вопрос глуп изначально. В Linux половна всего, особенно гуевый приложений, написана C++. Я тоже пишу таким образом. Нет, я не буду в программе hello world плодить полсотни классов, туеву хучу итераторов и пару шаблонов. Я стараюсь не перебарщивать с ООП, использую его только когда этоо удобнее. Это мое мнение. С++ удобен, если научится использовать его так как себе удобнее. Я читал Бьерна, он продвигет немного другой способ использования С++. Это звучит глупо. но я пишу немного по другому. ИМХО Бьерн сует свое детище слишком много куда. Он из серии тех, кто программу для сложения двух чисел непримернно напишет с использование классов, шаблонов и пр.
Теперь по теме. ИМХО в Linux никто не презирает или как-то не одобряет использование С++ вместо С. Ибо С++ - по большей части тот же С, просто добавлением ООП. А почему это спрашивается я не могу использовать дополненную версию языка? Я программирую на том, на чем Я хочу, и ПНХ все, кто мне тут будет указывать. Кроме того, для программирования на С++ в UNIX есть все условия: есть компилер, есть либы, есть хелп. Что еще нжно для щастья? Мне больше ничего. А то что возможно некоторый никсоиды будут вякать что "С++ - это не UNIX way и от лукавого" - так пошли они все на три веселых буквы. Я сам решаю на чем писать, хоть на QBasic :), и на то, что об этом скажут другие мне абсолютно похуй. Например я пишу большинство моих приложений под винды на Дельфе. Некоторые вякают что это предательство по отношению к С/С++. А мне пох. Некоторые программы проще писать на Дельфях. А под UNIX лучше на С/С++. Короче я все сказал, жду хора анонимусов, которые щаз будут меня обсирать :) Обсирайте, ребятки, мне пох :)
>Например я пишу большинство моих приложений под винды на Дельфе. >Некоторые вякают что это предательство по отношению к С/С++. А мне пох. >Некоторые программы проще писать на Дельфях. А под UNIX лучше на С/С++.
Полностью соглсен.
Глупо писать программу по работе с базами данных на asm, для этого есть delphi.
Я вспоминаю времена когда еще небыло даже win95, тоесть был DOS. Я студеном писал на Turbo C. И построение интерфейса было самым тяжким делом. Хотя были всякие процедурные либы для выведения окошек, менюшек, кнопочек,... но это был гимор. И тут появился Turbo Vision. Это было просто круто, именно с него я понял насколько гибкая и мощная штука ООП.
Я многих знаю кто не любит ООП, а еще я знаю что, все они его знают по наслышке. Вспоминая себя как я его учил, я понимаю чего они знаю о нем по наслышке, там мало выучить идеологию и синтаксис. Его нужно уметь применять.
Есть куча языков (bash, c/c++, sql, pascal, perl, php, python, ...) и куждого своя есть своя специализация, в которой он ас. Поэтому для разных задач нужно выбирать правильный инструмент.
Никто не собирается тебя обсирать... Твоя точка зрения мне ясна -- тебе всё по х... и это твой выбор :)
Просто хочу понять, почему Линукс-сообщество недолюбливает C++. GUI, а также всякие там прикладные проги не в счёт. Меня интересует системный софт, работающий на низком уровне. Даже ядро разрабатывается на Си. Хотя при всей его сложности программировать на С++ было бы легче. Почему они не включают в ядро код на Си++ ? Вопросы совместимости ? Квалифицированных программистов на Си больше ? ЧТО ?
Ну вопервых там некуда приложить мощь ООП.
Так-как в C++ ООП есть понятие наследование и перегрузка методов то это замедляет работу потому что, адреса функций вычисляются по таблице виртуальных методов.
> Хотя при всей его сложности программировать на С++ было бы легче. Почему они не включают в ядро код на Си++ ?
Компиляторы С++ медленее собирают, код получается менее эффективным (по разным оценкам он работает до 20% медленее), ООП программы требуют больше памяти для работы (ну это логично какими бы компактными не были объекты, под них нужна память). Ну и зачем нам тормозное ядро? Только затем, чтобы разработчикам было удобнее на кнопки давить?
Кто проводил измерения и на каких язаках? PHP c ассемблером?
Объекты занимают столько памяти, сколько в них переменных, а переменных столько, сколько тебе надо данных хранить и от ООП не зависит. А struct это вообще во всех языках есть, даже совершенно не ООП.
Виртуальные и абстрактные методы тормозят, но и без них можно обойтись. Будет не трехногий ООП, а двуногий!
Насчет нелюбви - так, а Pistochio на что!
А, вообще, смысла нет ядро писать на Си++ (хотя-бы частично): далеко не все люди это приветствуют, и это просто разобьёт команду разработчиков - Си, как-бы , связывает разнородные массы в команду. А то я буду писать Линукс на Асме, другой на Си, третий на Си++ - бардак получится. В таких вещах должно быть единство, гораздо проще разбить проект на множество модулей, чем множество классов, да и компиляция проходит быстрее.
А тем кто хочет ООП - альтернативные решения - это тоже идеология Столлмана - множество ядер для GNU.
Насчет того, что приветствеут Столлман, а что нет. Не знаю и спор вести не хочу, но он, скажем так, много странностей имеет...
Ну и самое главное не сказал - не язык должен быть главным, а алгортм. Если человек не может написать программу на Модула-2, зная Java вместе с документацией естественно по синтаксису - это печально.
ООП в Си++ -это надстройка, усовершенствование, шаг вперед по сравнению с Си. Но многие, по не известным мне причинам, видят в этом идеологию, а не инструмент воплощения своих алгоритмов. Когда люди дерутся из-за языков программирования - значит они просто ничего не смыслят в этой области.
Еще раз повторюсь: язык - это инструмент для реализации алгоритмов.
Язык C прост. Как 3 копейки. Первый компилятор был объёмом 20КБ. Соответственно, простой язык, простой (сейчас уже только относительно) компилятор - меньше ошибок, более качественная оптимизация.
Я как-то читал историю одного кренделя (сейчас уже не вспомню чью и где), который участвовал (как один из основных разработчиков) в написании компилятора C++. Стандартом на C++ убить можно, если по голове стукнуть, соответственно, в нём куча разночтений, которые естественно, по закону Мерфи, читаются всеми возможными способами, что приводит к несовместимостям или необходимости помнить "zillions" подводных камней при написании портабельных прог. Кроме того, частенько вылазят противоречия в стандарте, которые непонятно как разрешать и, соответственно, разрешаются кому как бог на душу положил, что тоже не улучшает ситуации с совместимостью.
Язык раздут до невозможности, так что оптимизация становится, мягко говоря, нетривиальной задачей, а грубо - полный пиздец. Соответственно, оптимизирующий код громоздок, сложен и, как следствие, глючит постоянно. Хорошо, если ещё на этапе компиляции какой-нить "internal error", а то будешь целый день искать глюк в своём коде, пока до дизассемблирования не доберёшься, а там - мать моя женщина!
Новые возможности прилеплены неудобно. Если ими интенсивно пользоваться, то очень сложно подобрать соглашения о кодировании, которые бы в подавляющем большинстве случаев давали единообразно оформленный и хорошо читаемый код.
Я допускаю, что C++ может быть хорош в каких-то областях, но сам предпочитаю методику "glue language". Из языков - Python. Все задачи, которые решались когда-то мной на C++, очень хорошо и красиво решаются этим способом. Хотя и это, естественно, не панацея.
P.S. В написании этого сообщения использовался собственный опыт разработок, а не просто чьи-то статейки. Поэтому список недостатков ограничивается лишь теми, с которыми пришлось столкнуться мне самому.
>Просто хочу понять, почему Линукс-сообщество недолюбливает C++. GUI,
> а также всякие там прикладные проги не в счёт. Меня интересует >системный софт, работающий на низком уровне.
>Даже ядро разрабатывается на Си. Хотя при всей его сложности >программировать на С++ было бы легче. Почему они не включают в ядро код
> на Си++ ? Вопросы совместимости ? Квалифицированных программистов на
>Си больше ? ЧТО ?
Почему ты решил что С++ недолюбливают? и так легко сбрасываеш со счетов прикладной софт? Вам его религия писать запрещает? Да часть прикладных програм в линуксе написана на С, хотя использование С++ в них было бы логичнее, но это уже проблема их авторов, им проше писать на том, что они уже знают чем учить нечто новое. Но ты делаеш большую ошибку противопоставляя С и С++. Это инструменты а не религии. Если кто-то заявляет что С намного круче чем С++ то этот чудак скорее всего просто не понимает что такое ООП и для чего оно нужно. Ядро линукса проще делать на С языке который первоночально и задумывался как переносимый ассемблер, то же относится и к библиотекам типа glibc(незабывай что они используются не только из С и С++ но и из других языков, а у С++ есть обыкновение манглить имена функций в библиотеках, и нету стандарта на эту фичу). Но если писать прикладные програмы без использования ООП то разработка займет слишком много времене и денег.
А вообще странные люди на ЛОР ходят, ява существует уже больше 7 лет, мелкософт собирается сделать системный АPI обьектно ориентированым, а тут многие непонимают елементарые вещи судя по их постам. Надеюсь эти люди свободный софт не пишут, а то он скоро будет в Ж%%% из-за таких девелоперов.