LINUX.ORG.RU

нет, это на ЛОРе не принято, а остальная (прогрессивная) часть сообщества вовсю использует объектно-ориентированные технологии

anonymous
()

ибо С есть истиный путь, очищающий душу и просветляющий разум, а с++ от лукавого :-)

human0id ★★★
()
Ответ на: комментарий от telinit

> А аргументировать можешь ?

во первых, Юникс вей все таки тяготеет к простым решениям. Компилятор Си++ реализовать гораздо нетривиальнее чем Си.

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

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

Мощно закрутил :)

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

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

telinit
() автор топика
Ответ на: комментарий от anonymous

> а остальная (прогрессивная) часть сообщества вовсю использует объектно-ориентированные технологии

GTK вот под Си, куча других тулкитов тоже под Си. QT и GTKmm не предлагать, хотя последний я в глаза не видел.

anonymous
()

Так вот и интересно, почему так сложилось.

Только, возможно, из-за традиций :)

telinit
() автор топика
Ответ на: комментарий от anonymous

C++ это не ООП-технологии. Это BloatWare-технологии. И вообще ООП - гавно, ТОП рулит.

anonymous
()

ответ прост. им влом или мосгоф не хватает выучить cpp.

Sveta_F
()

часчет чая - http://zadorno.com/archives/004907.html

а то что не используют C++ ибо он говно(сколько раз уже мусолили на LOR), а страуструп дебил ..

lg ★★
()

Вообще я в этом упрекнул бы Столлмана (при всем моем к нему уважении).
Именно он в свое время настраивал GNU-сообщество против С++.

ANDI ★★
()
Ответ на: комментарий от ANDI

> Вообще я в этом упрекнул бы Столлмана (при всем моем к нему уважении).
> Именно он в свое время настраивал GNU-сообщество против С++.

В большистве случаев я со столлменом не согласен(хотя конечно уважаю и
его и его точки зрения), но тут он сделал совершенно правильно ..

lg ★★
()
Ответ на: комментарий от ANDI

Вопрос а зачем С++?
Мне хватает Це за глаза...

Все нужное БОГ сделал простым, а все сложное не нужным...

anonymous
()
Ответ на: комментарий от dilmah

> во первых, Юникс вей все таки тяготеет к простым решениям. Компилятор Си++ реализовать гораздо нетривиальнее чем Си.

А интерпретатор бейсика сделать проще, чем компилятор С и ...?

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

С++ лучше "выделяет слоя", чем С. В С у вас, по сути, одно глобальное пространство имен, которое со временем превращается в кашу (static не сильно спасает).
С++ добавляет слои "классы" и слои "пространства имен".
Так что, С++ - это более "Юникс вей", чем С.




ANDI ★★
()
Ответ на: комментарий от lg

>В большистве случаев я со столлменом не согласен(хотя конечно уважаю и
его и его точки зрения), но тут он сделал совершенно правильно ..

Настолько, что пишешь его имя с маленькой буквы? ;)

Мне не нравится, что он смешивает "политику" и личные пристрастия.
Половина GNU-софта написана на C++. Покажите хоть один браузер, написанный на С?
Так что недооценивает он С++.

ANDI ★★
()
Ответ на: комментарий от ANDI

> Настолько, что пишешь его имя с маленькой буквы? ;)

:) ну да ладно придиратся ..

> Мне не нравится, что он смешивает "политику" и личные пристрастия.
> Половина GNU-софта написана на C++. Покажите хоть один браузер,
> написанный на С? Так что недооценивает он С++.

dillo, w3m (который я и пользую), .. да малоли еще, C не предназначен
для таких вещей .. вообще gui на C писать это изврат ..

NOTE: это не спор C vs C++

lg ★★
()
Ответ на: комментарий от anonymous

>Вопрос а зачем С++? Мне хватает Це за глаза...

Можно вопрос ?

Каков _средний_ размер проекта для которого "хватает Це за глаза" ?

sS ★★★★★
()

Системные вещи пишут на C, прикладные - на C++.

был случай когда библиотеки для моделирования кое-чего переписывались на C (это еще в Досе и OS/2). Как сказал один из программеров (сейчас он за бугром - после защиты диссертаци свалил), причина того, что они так поступили в том, что если в программе, написанной на C++ слетит базовый класс, то накрывается вся программа (я ни хрена из этой фразы не понял, надеюсь тут присутствующие анонимусы разъяснят подробнее). Программы у них обычно считали месяца по три без остановки.

anonymous
()
Ответ на: комментарий от lg

>dillo, w3m (который я и пользую), .. да малоли еще, C не предназначен
для таких вещей .. вообще gui на C писать это изврат ..

Это ты про Gnome? Я просто сочувствую этим ребятам.
dillo и w3m - без комментариев.

>NOTE: это не спор C vs C++

Вопрос изначально был провокационный. Если по топику, то мой ответ - из-за Столлмана.
Хотя если бы не он, то, может, не было бы и GPL Qt.

ANDI ★★
()
Ответ на: комментарий от theSoul

очень просто. Юникс это не богатая система. Юникс в некоторых вещах предпочитает быть убогим но "правильным".

Общепринято что ОС и языки это параллельно-перпендикулярные сущности. То что система написана на Си не существенно. Ассемблер в системе это все равно машинный ассемблер. Но в Юниксе, во всяком случае по задумке, ассемблером должен являться Си. В Юникс, просто по дизайну должен быть портабельный ассемблер. Во первых плюсов тогда не было. Во вторых плюсы все равно не годятся на роль ассемблера.

dilmah ★★★★★
()

Вот еще одно мнение: http://www.nixp.ru/rlfaq/rulinux.faq-2.html#ss2.16

"Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."

anonymous
()
Ответ на: комментарий от anonymous

>"Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."

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




ANDI ★★
()
Ответ на: комментарий от anonymous

> "Потому что те, кто более-менее разбирается в идеологии *nix прекрасно понимают, что практически любой проект надо разрабоатывать не на одном языке, а на нескольких разного уровня (критические по скорости части - на C, интерфейс - на perl/tcl/python/slang, работу с данными на SQL и так далее)."

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

dilmah ★★★★★
()
Ответ на: комментарий от anonymous

> И еще одно мнение: http://www.getinfo.ru/article40.html

стоит прочесть:):

И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может сидеть парень, которому придет в голову сделать это...

C. Hо не после того, как он прочитает это интервью.

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

>очень просто. Юникс это не богатая система. Юникс в некоторых вещах предпочитает быть убогим но "правильным".

Unix - богатая система. Убогой ее делает такое стремление к призрачной "правильности".

>Общепринято что ОС и языки это параллельно-перпендикулярные сущности. То что система написана на Си не существенно. Ассемблер в системе это все равно машинный ассемблер. Но в Юниксе, во всяком случае по задумке, ассемблером должен являться Си. В Юникс, просто по дизайну должен быть портабельный ассемблер. Во первых плюсов тогда не было. Во вторых плюсы все равно не годятся на роль ассемблера.

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


ANDI ★★
()
Ответ на: комментарий от dilmah

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

Ужас.
Не хотел бы я ваш проект потом сопровождать :)

ANDI ★★
()
Ответ на: комментарий от ANDI

> Ужас. Не хотел бы я ваш проект потом сопровождать :)

меня на работе стараются держать в jail, чтобы не навредил:)

dilmah ★★★★★
()

Вопрос - просто супер! Сижу вот и программирую себе под Линуксом на С++. И не считаю себя ущербным.

Flogger_d
()
Ответ на: комментарий от Flogger_d

Помоему вопрос глуп изначально. В Linux половна всего, особенно гуевый приложений, написана C++. Я тоже пишу таким образом. Нет, я не буду в программе hello world плодить полсотни классов, туеву хучу итераторов и пару шаблонов. Я стараюсь не перебарщивать с ООП, использую его только когда этоо удобнее. Это мое мнение. С++ удобен, если научится использовать его так как себе удобнее. Я читал Бьерна, он продвигет немного другой способ использования С++. Это звучит глупо. но я пишу немного по другому. ИМХО Бьерн сует свое детище слишком много куда. Он из серии тех, кто программу для сложения двух чисел непримернно напишет с использование классов, шаблонов и пр. Теперь по теме. ИМХО в Linux никто не презирает или как-то не одобряет использование С++ вместо С. Ибо С++ - по большей части тот же С, просто добавлением ООП. А почему это спрашивается я не могу использовать дополненную версию языка? Я программирую на том, на чем Я хочу, и ПНХ все, кто мне тут будет указывать. Кроме того, для программирования на С++ в UNIX есть все условия: есть компилер, есть либы, есть хелп. Что еще нжно для щастья? Мне больше ничего. А то что возможно некоторый никсоиды будут вякать что "С++ - это не UNIX way и от лукавого" - так пошли они все на три веселых буквы. Я сам решаю на чем писать, хоть на QBasic :), и на то, что об этом скажут другие мне абсолютно похуй. Например я пишу большинство моих приложений под винды на Дельфе. Некоторые вякают что это предательство по отношению к С/С++. А мне пох. Некоторые программы проще писать на Дельфях. А под UNIX лучше на С/С++. Короче я все сказал, жду хора анонимусов, которые щаз будут меня обсирать :) Обсирайте, ребятки, мне пох :)

LONGOBARD
()
Ответ на: комментарий от LONGOBARD

>Например я пишу большинство моих приложений под винды на Дельфе. >Некоторые вякают что это предательство по отношению к С/С++. А мне пох. >Некоторые программы проще писать на Дельфях. А под UNIX лучше на С/С++.

Полностью соглсен. Глупо писать программу по работе с базами данных на asm, для этого есть delphi.

Я вспоминаю времена когда еще небыло даже win95, тоесть был DOS. Я студеном писал на Turbo C. И построение интерфейса было самым тяжким делом. Хотя были всякие процедурные либы для выведения окошек, менюшек, кнопочек,... но это был гимор. И тут появился Turbo Vision. Это было просто круто, именно с него я понял насколько гибкая и мощная штука ООП.

Я многих знаю кто не любит ООП, а еще я знаю что, все они его знают по наслышке. Вспоминая себя как я его учил, я понимаю чего они знаю о нем по наслышке, там мало выучить идеологию и синтаксис. Его нужно уметь применять.

Есть куча языков (bash, c/c++, sql, pascal, perl, php, python, ...) и куждого своя есть своя специализация, в которой он ас. Поэтому для разных задач нужно выбирать правильный инструмент.

anonymous
()
Ответ на: комментарий от LONGOBARD

Никто не собирается тебя обсирать... Твоя точка зрения мне ясна -- тебе всё по х... и это твой выбор :)

Просто хочу понять, почему Линукс-сообщество недолюбливает C++. GUI, а также всякие там прикладные проги не в счёт. Меня интересует системный софт, работающий на низком уровне. Даже ядро разрабатывается на Си. Хотя при всей его сложности программировать на С++ было бы легче. Почему они не включают в ядро код на Си++ ? Вопросы совместимости ? Квалифицированных программистов на Си больше ? ЧТО ?

telinit
() автор топика
Ответ на: комментарий от anonymous

Вот оно... Инструмент !

Почему не используют лучший инструмент, работа с которым легче и эффективней ?

telinit
() автор топика
Ответ на: комментарий от telinit

>Почему они не включают в ядро код на Си++ ?

Ну вопервых там некуда приложить мощь ООП. Так-как в C++ ООП есть понятие наследование и перегрузка методов то это замедляет работу потому что, адреса функций вычисляются по таблице виртуальных методов.

Хотя была в свое время OS/2 полность ОО ОС.

anonymous
()
Ответ на: комментарий от anonymous

С++ немного медленней Си, а если для приложений эта разница несущественна,то для ядра она критична. Кроме того там нету смысла применять ООП.

LONGOBARD
()
Ответ на: комментарий от telinit

> Хотя при всей его сложности программировать на С++ было бы легче. Почему они не включают в ядро код на Си++ ?

Компиляторы С++ медленее собирают, код получается менее эффективным (по разным оценкам он работает до 20% медленее), ООП программы требуют больше памяти для работы (ну это логично какими бы компактными не были объекты, под них нужна память). Ну и зачем нам тормозное ядро? Только затем, чтобы разработчикам было удобнее на кнопки давить?

anonymous
()
Ответ на: комментарий от anonymous

нет ты баклан. ОО не вяжется с моделью event-driven, а GUI по определению event-driven. учи tcl/tk дурак позорный.

anonymous
()
Ответ на: комментарий от anonymous

>медленнее собираются

Так, причем намного

>Код получается менее эффективным (аж 20%)

Кто проводил измерения и на каких язаках? PHP c ассемблером? Объекты занимают столько памяти, сколько в них переменных, а переменных столько, сколько тебе надо данных хранить и от ООП не зависит. А struct это вообще во всех языках есть, даже совершенно не ООП.

Виртуальные и абстрактные методы тормозят, но и без них можно обойтись. Будет не трехногий ООП, а двуногий!

Насчет нелюбви - так, а Pistochio на что!

А, вообще, смысла нет ядро писать на Си++ (хотя-бы частично): далеко не все люди это приветствуют, и это просто разобьёт команду разработчиков - Си, как-бы , связывает разнородные массы в команду. А то я буду писать Линукс на Асме, другой на Си, третий на Си++ - бардак получится. В таких вещах должно быть единство, гораздо проще разбить проект на множество модулей, чем множество классов, да и компиляция проходит быстрее.

А тем кто хочет ООП - альтернативные решения - это тоже идеология Столлмана - множество ядер для GNU.

Насчет того, что приветствеут Столлман, а что нет. Не знаю и спор вести не хочу, но он, скажем так, много странностей имеет...

wieker ★★
()
Ответ на: комментарий от wieker

Ну и самое главное не сказал - не язык должен быть главным, а алгортм. Если человек не может написать программу на Модула-2, зная Java вместе с документацией естественно по синтаксису - это печально.

ООП в Си++ -это надстройка, усовершенствование, шаг вперед по сравнению с Си. Но многие, по не известным мне причинам, видят в этом идеологию, а не инструмент воплощения своих алгоритмов. Когда люди дерутся из-за языков программирования - значит они просто ничего не смыслят в этой области.

Еще раз повторюсь: язык - это инструмент для реализации алгоритмов.

wieker ★★
()

Язык C прост. Как 3 копейки. Первый компилятор был объёмом 20КБ. Соответственно, простой язык, простой (сейчас уже только относительно) компилятор - меньше ошибок, более качественная оптимизация.

Я как-то читал историю одного кренделя (сейчас уже не вспомню чью и где), который участвовал (как один из основных разработчиков) в написании компилятора C++. Стандартом на C++ убить можно, если по голове стукнуть, соответственно, в нём куча разночтений, которые естественно, по закону Мерфи, читаются всеми возможными способами, что приводит к несовместимостям или необходимости помнить "zillions" подводных камней при написании портабельных прог. Кроме того, частенько вылазят противоречия в стандарте, которые непонятно как разрешать и, соответственно, разрешаются кому как бог на душу положил, что тоже не улучшает ситуации с совместимостью.

Язык раздут до невозможности, так что оптимизация становится, мягко говоря, нетривиальной задачей, а грубо - полный пиздец. Соответственно, оптимизирующий код громоздок, сложен и, как следствие, глючит постоянно. Хорошо, если ещё на этапе компиляции какой-нить "internal error", а то будешь целый день искать глюк в своём коде, пока до дизассемблирования не доберёшься, а там - мать моя женщина!

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

Я допускаю, что C++ может быть хорош в каких-то областях, но сам предпочитаю методику "glue language". Из языков - Python. Все задачи, которые решались когда-то мной на C++, очень хорошо и красиво решаются этим способом. Хотя и это, естественно, не панацея.

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

Rock
()
Ответ на: комментарий от telinit

>Просто хочу понять, почему Линукс-сообщество недолюбливает C++. GUI, > а также всякие там прикладные проги не в счёт. Меня интересует >системный софт, работающий на низком уровне. >Даже ядро разрабатывается на Си. Хотя при всей его сложности >программировать на С++ было бы легче. Почему они не включают в ядро код > на Си++ ? Вопросы совместимости ? Квалифицированных программистов на >Си больше ? ЧТО ? Почему ты решил что С++ недолюбливают? и так легко сбрасываеш со счетов прикладной софт? Вам его религия писать запрещает? Да часть прикладных програм в линуксе написана на С, хотя использование С++ в них было бы логичнее, но это уже проблема их авторов, им проше писать на том, что они уже знают чем учить нечто новое. Но ты делаеш большую ошибку противопоставляя С и С++. Это инструменты а не религии. Если кто-то заявляет что С намного круче чем С++ то этот чудак скорее всего просто не понимает что такое ООП и для чего оно нужно. Ядро линукса проще делать на С языке который первоночально и задумывался как переносимый ассемблер, то же относится и к библиотекам типа glibc(незабывай что они используются не только из С и С++ но и из других языков, а у С++ есть обыкновение манглить имена функций в библиотеках, и нету стандарта на эту фичу). Но если писать прикладные програмы без использования ООП то разработка займет слишком много времене и денег. А вообще странные люди на ЛОР ходят, ява существует уже больше 7 лет, мелкософт собирается сделать системный АPI обьектно ориентированым, а тут многие непонимают елементарые вещи судя по их постам. Надеюсь эти люди свободный софт не пишут, а то он скоро будет в Ж%%% из-за таких девелоперов.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.