Интел делает шаг в сторону гнома

>Это относится ответ на первое предложение, или на второе?

к обоим. Что ты имел ввиду под "Он сделал это"?

и выкинуть Си - извини, это утопия и тяжелая форма красноглазия

ассемблер тоже выкинуть? :) и встроить ООП в CPU? Так java-процессоры пытались выпускать, да что-то не очень получается :)

>хотя-бы то, как на C выглядит ООП

можно так:

struct obj { lpVtbl Vtbl; ..... }

:)

страшно? ;)

а есть ещё Objective C

кроме того, ООП далеко не всегда нужен. Попробуй осознать это :)

> Для этого нужно выбрать, на чем их писать. Или из существующих языков. Или путем каких-то соглашений(не использовать то или это в каком-то языке).

Ну да, о чем-то таком я и говорю. Вроде, так было сделано в BeOS IIRC. Но к униху это все отношения не имеет (хотя и может быть сделано как уровень абстракции на glibc).

> imo эта нейтральность приводит к сильной потере typesafe. Хотя всякое бывает, может сейчас она и полезна.

typesafety невозможна, если объектные модели разные, если механизмы работы с runtime информацией разные и т.д. и т.п. Пока нет единой "труъ" (хотя бы в рамках одной платформы) объектной модели, ни о чем подобном мечтать нельзя. А как только Вы сделаете такую модель - Вы тут же ставите "раком" языки, которые ей не соответствуют. При этом, возможно, Вы выиграете много других хороших вещей. Но только к униху это все отношения иметь не будет (как не имеет к нему отношения j2se api).

>и выкинуть Си - извини, это утопия и тяжелая форма красноглазия

>ассемблер тоже выкинуть? :) и встроить ООП в CPU? Так java-процессоры пытались выпускать, да что-то не очень получается :)

Про ООП в CPU я ни чего не говорил, и imo это бред. Но то, что ядро и основные библиотеки(как и 80% прочего софта) сейчас пишутся весьма объектно ориентированно, imo говорит о том, что возможно стоит использовать языки, спроектировнааые для ООП.

>>хотя-бы то, как на C выглядит ООП

>можно так:

>struct obj { lpVtbl Vtbl; ..... }

>:)

>страшно? ;)

Нет, не страшно, но через жопу. Чтобы использовать такой vtbl потребуется инициализировать не только данные объекта, но и его функции. В отличие от инициализации структур в кострукторы/деструкторы обязательно передавать все параметы и эти параметры проверяются кодом(вдруг тебя не всякий int устраивает в этом поле?).

В C исходно нет понятия class, и C не будет как-то следить за инициализацией. Не будет следить за public/private просто потому, что он про них ни чего не знает. =>> он не выдаст warning-ов если где-то налажать.

>а есть ещё Objective C

Ты его знаешь? Или знаешь людей, знающих его? Я - нет. Может язык и хороший, но единственный пример его применения, с которым я сталкивался - OpenStep/WindowMaker(пользоваться можно, но он уже давно не развивается).

>кроме того, ООП далеко не всегда нужен. Попробуй осознать это :)

Кто-же спорит.

А когда доживем до пятого, то писать придется в моск:)

>>а есть ещё Objective C

> Может язык и хороший, но единственный пример его применения, с которым я сталкивался - OpenStep/WindowMaker(пользоваться можно, но он уже давно не развивается).

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/i...

>Но то, что ядро и основные библиотеки(как и 80% прочего софта) сейчас пишутся весьма объектно ориентированно, imo говорит о том, что возможно стоит использовать языки, спроектировнааые для ООП.

"весьма объктно ориентировано" вовсе не значит, что нужен ООП-язык.

и в ядре и в либах из всей парадигмы ООП используется только инкапсуляция. Всё. Зачем там C++? чтобы заставить _весь_ софт переписать на плюсах? в сад

Не только инкапсуляция. Полиморфизм, обычно реализуемый через указатели на функции, наследование, реализуемое через агрегацию - все есть, но на C(ибо так кошернее). Я не предлагаю переписывать _весь_ софт на плюсах, но imo OOP на C - жопа.

Imo то, что C - "Системный язык Unix" последние 30 лет - не означает, что и следующей 30 лет он им будет. C - не что-то принципиальное, это тот минимум, который поддерживается всеми языками и платформами. И imo то, что последние ~20 лет ООП - почти основная концепция, указывает на возможность её включения в этот минимум.

>Полиморфизм, обычно реализуемый через указатели на функции, наследование, реализуемое через агрегацию - все есть, но на C(ибо так кошернее)

где ты там полиморфизм углядел?

>mo то, что C - "Системный язык Unix" последние 30 лет - не означает, что и следующей 30 лет он им будет.

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

>И imo то, что последние ~20 лет ООП - почти основная концепция

да вы, батенька, мечтатель :) Я, с момента как ООП пошел в массы, наблюдал сначала вьюношей с горящими глазами ("Уау! я могу кнопку описать объектом кнопка"), а потом мущщин с потухшим взором =) ООП, если и не провалился, то явно не оправдал надежд, и не стал убийцей процедурного программирования. И не станет. Просто потому что вещей, которые программировать в процедурном стиле - на порядок больше, чем тех, которые проще описывать объектами. Ну не впихивается реальный мир в нули, единички и переходы по адресу =)

А нишу ООП я уже указал, и не вижу смысла повторяться.

>mo то, что C - "Системный язык Unix" последние 30 лет - не означает, что и следующей 30 лет он им будет.

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

Если уровень определять зависимостями, то assembler, C и C++ находятся на одном уровне, так-как все они не требуют jit/интерпретатора и имеют маленькую стандартную библиотку, ни как не связанную с платформой/целями применения.

Если уровень определять с точки зрения системного программирования, то assembler можно без проблем вставлять в C/C++ там, где это необходимо.

Если уровень определять с точки зрения проектирования, то C++ содержит больше возможностей чем C.

Так с какой точки зрения C - низкоуровневый язык, и чем это лучше?

>да вы, батенька, мечтатель :) Я, с момента как ООП пошел в массы, наблюдал сначала вьюношей с горящими глазами ("Уау! я могу кнопку описать объектом кнопка"), а потом мущщин с потухшим взором =) ООП, если и не провалился, то явно не оправдал надежд, и не стал убийцей процедурного программирования. И не станет. Просто потому что вещей, которые программировать в процедурном стиле - на порядок больше, чем тех, которые проще описывать объектами. Ну не впихивается реальный мир в нули, единички и переходы по адресу =)

Если среди тех вьюношей он и провалился, то это ни чего не говорит о самой идее. Не нужно воспринимать её слишком прямо. ООП и не пытается описывать реальный мир. Разделение на классы скорее связано с зависимостями в программе, чем в предметной области, хотя делить можно и по другим критериям. Кнопки тут совершенно побоку.

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

Большая часть сишного кода скомпилится на плюсах с правками на уровне

-int* a = malloc(... +int* a = (int*)malloc(...

>Если уровень определять зависимостями, то assembler, C и C++ находятся на одном уровне, так-как все они не требуют jit/интерпретатора и имеют маленькую стандартную библиотку, ни как не связанную с платформой/целями применения.

не путай. На одном уровне находятся асм и Си - именно из-за простого ABI у C++ ABI комплекснее.

>Но C++ ни как не мешает прогать процедурно, хотя-бы потому, что полностью включает в себя C

насчет полностью - ты сам себе противоречишь. цитирую:

>-int* a = malloc(... +int* a = (int*)malloc(...

и потом, malloc в С++ говорит о том, что С++ был выбран _НЕПРАВИЛЬНО_. Нахера использовать С++, если все равно писать на Си? Чтобы удовлетворить самолюбие пионеров, кое-как знающих ООП и кричащих что это круто? Нах

>Если среди тех вьюношей он и провалился, то это ни чего не говорит о самой идее.

идея делать всё на ООП (плюсы, жаба) ПРОВАЛИЛАСЬ. У них есть своя ниша, и _НЕ_ _БОЛЕЕ_. Я уже устал тебе это объяснять. А желание выкинуть из юниксов Си и писать _системные_ библиотеки и, не приведи патрег, ядро, на плюсах - это, извини меня, ТУПОСТЬ и КРАСНОГЛАЗИЕ в самой тяжелой форме.

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

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

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

> malloc в С++ говорит о том, что С++ был выбран _НЕПРАВИЛЬНО_.

Вообще-то речь шла о том, чтобы перекомпилировать программу на Си компилятором Си++.

> Нахера использовать С++, если все равно писать на Си? Чтобы удовлетворить самолюбие пионеров, кое-как знающих ООП и кричащих что это круто?

Нет смысла, конечно... Вещи вроде шаблонов, ссылок, исключений - они ж никому не нужны.

> Нах

Ты заметил, что "Нах" и "В морг" в этом треде кричишь только ты?

> Я уже устал одно и тоже тебе разжевывать, чесслово.

Да ладно, признайся, что тебе это нравится.

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

Ясное дело, ты один здесь из реального большого мира.

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

вовсе нет. читай тред внимательнее

>Вообще-то речь шла о том, чтобы перекомпилировать программу на Си компилятором Си++.

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

>Нет смысла, конечно... Вещи вроде шаблонов, ссылок, исключений - они ж никому не нужны.

или ты искренне уверен, что появятся?

>Ясное дело, ты один здесь из реального большого мира.

не один, не переживай за меня

>> gnome-terminal, firefox, gajim, gvim, thunderbird, OOo.

>konsole, konqueror, kopete, kate, kmail, koffice. :)

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

>Вообще-то речь шла о том, чтобы перекомпилировать программу на Си компилятором Си++.

>а смысл? ни шаблонов, ни ссылок ни исключений от этого в ней волшебным образом не появятся.

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

>Если уровень определять зависимостями, то assembler, C и C++ находятся на одном уровне, так-как все они не требуют jit/интерпретатора и имеют маленькую стандартную библиотку, ни как не связанную с платформой/целями применения.

>не путай. На одном уровне находятся асм и Си - именно из-за простого ABI у C++ ABI комплекснее.

В той части C++, которая есть в C ABI у них одинаковый.

>Но C++ ни как не мешает прогать процедурно, хотя-бы потому, что полностью включает в себя C

>насчет полностью - ты сам себе противоречишь. цитирую:

>-int* a = malloc(...

>+int* a = (int*)malloc(...

Да, C++ ругается на неявное приведение типов. Это логично. И помогает искать лаги. Это примерно как переход с gcc3 на gcc4, просто компилятор стал чуть более строгим. Этот переход не занял много времени.

>и потом, malloc в С++ говорит о том, что С++ был выбран _НЕПРАВИЛЬНО_. Нахера использовать С++, если все равно писать на Си? Чтобы удовлетворить самолюбие пионеров, кое-как знающих ООП и кричащих что это круто? Нах

Кто тебе сказал, что в C++ нельзя/плохо использовать malloc? Если понимаешь в чем разница между malloc и new[] то используешь то, что подходит в данной ситуации.

Темболее если речь идет о компиляции сишного кода плюсовым компилятором.

>идея делать всё на ООП (плюсы, жаба) ПРОВАЛИЛАСЬ. У них есть своя ниша, и _НЕ_ _БОЛЕЕ_. Я уже устал тебе это объяснять. А желание выкинуть из юниксов Си и писать _системные_ библиотеки и, не приведи патрег, ядро, на плюсах - это, извини меня, ТУПОСТЬ и КРАСНОГЛАЗИЕ в самой тяжелой форме.

Пока ты это скорее повторяешь(в стиле "Именем патрика объявляю вас всех красноглазыми фонатиками. Всех в морг.") чем аргументированно объясняешь.

Интересно, что плохого в переводе(для начало просто компиляции) ядра на C++? Оно изолировано, т.е. его ни кто прямо не вызывает => не будет ни каких проблем с совместимостью с софтом.

>Я уже устал одно и тоже тебе разжевывать, чесслово. Думаешь, что С++ настолько же низкоуровневый как Си? Думай на здоровье, только не сильно удивляйся, когда окажется, что реальность сильно отличается от придуманного тобой и другими фанатиками плюсов мирка

Ну я не просто говорю, я еще и аргументы привел.

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

> вовсе нет. читай тред внимательнее

Ссылочку не подбросишь?

>>Ясное дело, ты один здесь из реального большого мира.

>не один, не переживай за меня

Переживать? Я за тебя рад.

На смысловом уровне, предложение привести код ядра к плюсовым стандартам аналогично предложению адаптировать его к любому другому языку. Ибо в любом случае - перенос кода с языка А на язык Б (разница только в расстоянии между языками - и соотв. усилиях по переносу). Поскольку С не является подмножеством С++ (иначе усилия по переносу были бы нулевыми).

Я подозреваю, что человеку, заюзающему темплейты в ядре, Линус оторвал бы гениталии. И я его в этом поддерживаю;)

imo в случае перевода с C на C++ расстояние не особо велико. В том-то и дело. А так - согласен.

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

> imo в случае перевода с C на C++ расстояние не особо велико

Безусловно, оно минимально (для любого другого языка оно больше). Но смысла это не меняет - предлагается смена языка ядра.

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

> Я подозреваю, что человеку, заюзающему темплейты в ядре, Линус оторвал бы гениталии. И я его в этом поддерживаю;)

Почему, кстати? Шаблоны не требуют runtime-поддержки.

Согласен.

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

> Шаблоны не требуют runtime-поддержки.

CMIIW - нет стандарта на генерацию двоичного кода из темплейтов. Значит, нет детерминированности двоичного представления кода ядра. Зависимость от компилятора становится плохо контролируемой (и даже от опций - IIRC темплейтный код можно было компилировать и линковать по-разному, когда я последний раз смотрел на это дело). У ядра и так хватало проблем с разными компиляторами.

> CMIIW - нет стандарта на генерацию двоичного кода из темплейтов. Значит, нет детерминированности двоичного представления кода ядра.

Стандарта на генерацию кода вообще нет :) И двоичное представление ядра и при использованиее Си недетерминорованно.

> Зависимость от компилятора становится плохо контролируемой (и даже от опций - IIRC темплейтный код можно было компилировать и линковать по-разному, когда я последний раз смотрел на это дело). У ядра и так хватало проблем с разными компиляторами.

В общем, довод в стиле "как бы чего не вышло". Хороший довод (без всякой иронии). Кстати, эксперимент по преводу ядра на Си++ был на заре времен (IIRC, еще до GCC 2), закончился провалом. А учитывая, что самую полезную для ядра фишку, исключения, в ядре использовать не получится из-за нетривиальной runtime-поддержки, перевод на Си++ бессмысленен, ИМХО.

Хотя ядра на Си++ есть :)

Уходя еще глубже в оффтопик - стандарт Си после C99 включает в себя try/catch/finally ?

Вроде нету except-ов. Смотрел на http://gcc.gnu.org/c99status.html

ИМХО любая система exceptions без объектной модели (в частности, наследования) - довольно грустное зрелище.

> ИМХО любая система exceptions без объектной модели (в частности, наследования) - довольно грустное зрелище.

Не более грустное, чем возвращение кодов ошибок. Хотя с объектами веселее (кто ж спорит!), но PL/I, Clu, Эль-76, Ada обошлись и без них. И Си - тоже обошелся ;)

>и в ядре и в либах из всей парадигмы ООП используется только инкапсуляция

Полиморфизм тоже используется. Смотри например реализацию read/write, которые могут работать с различными объектами (файл/сокет (куча видов)/и тп) которые имеют однотипные операции (read/write/и тп).

Intel делает шаг в сторону гроба :-)

здрасте. несколько мыслей насчет гнома и кде.

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

2) оценивая принадлежность софтины к гному \ кде чаще всего имеют ввиду gtk \ qt . хотя надо оценивать уровень интеграции програмульки с другим софтом (как например амарок с конквиком)

3) самые частоиспользуемые вещи (на мой взгляд) - терминал, файл-менеджер и текст-редактор. konsole почему-то приятнее - шустрее реагирует на действия юзера. kate - вообще гениальнейшая вещ, никакой gedit ей не конкурент. конквик как файл менеджер вполне хорош, наутилус иногда ведет себя не совсем адекватно.

4) карамба. именно она. чем гордится apple? своим занюханным дашбордом, который "у нашего магазина конкретно отсасывает (с)" ("магазин" = "карамба"). карамба делает жизнь кде-шника намного приятнее.