GNOME 2.12 - что день грядущий нам готовит

Вау! И это любители плюсов говорят о том, что идеологии смешивать не надо?? Да эклектичнее этого языка разве что си-шарп (даже жаба, мне кажется, более последовательна в своем ОО-изме)! И ведь провоцируют плюсы смешивать, ой как провоцируют...

geek

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

>>представь себе знаю. Интересно, каких извращений потребует в c++ ядре syscall из _не_ c++. Или сисколлы там ни разу ни методы? Но тогда забавно выглядит вызов из c++-приложений. Типа разворачиваем объект в структуру, потом syscall, потом уже в ядре структура опять сворачивается в объект и пошла обработка. Забавно.

такая офигинея ....
а просто x->sys_call () типа религиозные запреты ?
или вы вообще плохо представляете как выглядит вызов функции на ассемблере ?

>Это-то не очень страшно. В большинстве случаев (всегда?) передаваться будет не объект, а ссылка на него (не обязательно указатель, но что-нибудь семантически подобное)

скорее всего. Только вот...софт для системы оказывается загнан в рамки це++. Для остального - врапперы. Мне кажется девелоперы скорее забъют на такую ОС, чем будут заморачиваться =) Есть простой и понятный linux

>>>И ведь провоцируют плюсы смешивать, ой как провоцируют...

те кто не умеют сдерживать свои наклонности существует smalltalk :)))

>а просто x->sys_call () типа религиозные запреты ? или вы вообще плохо представляете как выглядит вызов функции на ассемблере ?

да нет никаких запретов. Можно псевдокодом? =) а то ассемблерный вызов метода сильно зависит от ABI

object->vtable[method](object, ...)

но и особого смысла переписывать ядра на C++ тоже нет

То, что девелоперы на других языках забьют - может, так и будет (хотя ведь плюсисты наверняка байндингов понаделают, через extern C). Честно скажу - на сегодня мне представить ОС без позиксового апи практически невозможно. Поэтому даже на тему "если бы" рассуждать не хочется:)

Ага! Вот так вот вы всегда...:)

>Поэтому даже на тему "если бы" рассуждать не хочется:)

у меня ощущение, что дискуссия зашла в тупик

Самый простой вариант: в стек запихиваются:

1. Указатель на объект (хэндл или как угодно) - 4 байта

2. Идентификатор виртуальной функции - 4 байта

3. Все остальные параметры

Остальное - дело ядра.

> привык рассматривать проблему со всех сторон, а не только "в лоб"

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

> аськи нету. грамотные "поцаны" юзают жабер

даже в таком "мелком" вопросе ты не упустил своего шанса вые%:ться, какой ты правильный и продвинутый.

это замечательно характеризует как недалекую и самоуверенную личность

>> потому что посикс не объектный? извини, но это маразм - пытаться все запихать в ооп

.....
и все что вы знаяте о системных интерфейсах ?

>> можешь посмотреть, на чем написан прогрессивный plan9.
plan9 - идеология unix доведенная со совершенства
никому не нужен .....

>> ps: тебя послушать, так linux, bsd, hurd, plan9 писали идиоты, которым недоступна прелесть и красота C++.

нет - гном писали идиоты
которые не могли просто подумать головой

>нет - гном писали идиоты которые не могли просто подумать головой

потому что они положили хер на C++ и QT? Ню-ню. аргументы кончились? =)

> нет - гном писали идиоты

Как насчет "оскорбления участников дискуссии"?;)

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

>Самый простой вариант: в стек запихиваются:
>1. Указатель на объект (хэндл или как угодно) - 4 байта
>2. Идентификатор виртуальной функции - 4 байта
>3. Все остальные параметры
>Остальное - дело ядра.

самое забавное
что в реальности так оно и происходит :)))
например в linux ядре :))

>> нет - гном писали идиоты
>Как насчет "оскорбления участников дискуссии"?;)

удали то сообщение
и прими извинения, пожалуста
:)

Ну, не совсем - но похоже. А как еще оно может быть?:) Просто geek боялся, что начнут бинарное представление объекта туда-сюда по стеку гонять - я хотел ему показать, что не все так страшно...

Удалить не могу - не модератор. Извинения приняты:)

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

скорее всего тут - на вкус и цвет ,,,

ладно, поживем - увидим
:) время думаю тазрешит наш спор :)

Хорошо. Конечно увидим. Как умрут всякие С и плюсы. И настанет везде один Кобол:)

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

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

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

классная фраза для завершения флейма C vs C++ =)

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

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

Не все так плохо. Все-таки наработки fd.o потихоньку проникают в мир КДЕ. libxml2 исползуется, вроде. hal используется наверняка. pkgconfig. dbus тоже имеет шансы. Вон, уже про организацию меню договорились. Про клипборды тоже конструктивный диалог, вроде, идет.

ЗЫ жаль, кде libxklavier не адоптит. Потому и вижу xxkb на каждом втором кдешном скриншоте - местная-то переключалка кривовата чуток.

>для убития мнения что какой-то такой язык - дерьмо

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

пользуюсь местной :) пойдет :))

так выпьем же за повсеместное расширение и развитие fd.o !
:)))
ps
только про PIDL не забудте пожалуста
вижу тут хорошего много и полезного отечеству и его сынам :)

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

обидно конечно. Просто когда разрабатывали ООП-языки - о совместимости не думали. Нет, конечно, если бы OOP было реализовано на уровне железа (как реализован простой вызов функции) - то вопросов "а как мне вызвать метод из C++ либы в питоне без гемора" не стояло бы. Может быть, проблема будет решена через пару поколений ЭВМ =)

> только про PIDL не забудте пожалуста

Любой *idl - это тоже отражение некоторой объектной модели;)

> вижу тут хорошего много и полезного отечеству и его сынам :)

Ох уж эти сексисты от хайтека! Вечно про дочерей забывают!:)

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

>обидно конечно. Просто когда разрабатывали ООП-языки - о совместимости не думали. Нет, конечно, если бы OOP было реализовано на уровне железа (как реализован простой вызов функции) - то вопросов "а как мне вызвать метод из C++ либы в питоне без гемора" не стояло бы. Может быть, проблема будет решена через пару поколений ЭВМ =)

а простой вызов функции реализован на уровне железа ??? :))
какого если не секрет ? у всех ?? :)))))))
а что вызов С либы стоит без гемора ?
совершенно ?
даже переходник писать не надо ?
а вы писали ?

:))))))))))))))))

Да, уговорить любителя КДЕ выпить за fd.o - это не фунт изюму!:) Присоединяюсь к тосту:)

дочери это хорошо :)))

>> Любой *idl - это тоже отражение некоторой объектной модели;)
могу только заметить что настолько общей и простой
что никому вреда не будет :)

>а простой вызов функции реализован на уровне железа ??? :))

CALL

RET

>а что вызов С либы стоит без гемора ?

вот эту фразу не понял.

>>а простой вызов функции реализован на уровне железа ??? :))
>CALL
>RET

уверены ? segfault не боитесь ?

>>а что вызов С либы стоит без гемора ?
>вот эту фразу не понял.

уверены насчет вызова с из питона явы caml smalltalk ruby ?
уверенны что все так просто ?
взял сделал
call
потом
ret
?

а на alpha, sparc ?
тоже самое ? совершенно также ?

>уверены ? segfault не боитесь ?

с чего бы?

>уверены насчет вызова с из питона явы caml smalltalk ruby ?

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

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

>>уверены ? segfault не боитесь ?
>с чего бы?

не писал ассемблер ....

>>уверены насчет вызова с из питона явы caml smalltalk ruby ?
>вполне. забиндить _интерпретируемый_ язык к сишной либе в разы проще, чем к c++->либе.
>ps: или вы не в курсе, что такое интерпретация?

не писал переходники ....

>а на alpha, sparc ? тоже самое ? совершенно также ?

логика такая же

не видел ни спарк ни альфа ассемблера ...

>не писал ассемблер ....

ассемблер - не писал

и что?

>не писал переходники ....

переходники писал. дальше что?

>не видел ни спарк ни альфа ассемблера ...

sparc assembler видел. Может, по теме дискуссии что-нибудь скажешь? =)

Интересно, является ли хоть один из перечисленных языков интерпретируемым?... java и smalltalk - точно не. Уже очень давно...

>>не писал ассемблер ....
>ассемблер - не писал
>и что?

ну что же вы беретесь спорить о том чего не знаете ?

>>не писал переходники ....
>переходники писал. дальше что?

и к С и к С++ хотя бы для половины названых языков ?

>Интересно, является ли хоть один из перечисленных языков интерпретируемым?... java и smalltalk - точно не. Уже очень давно..

байткод. суть не сильно отличается. jit будем рассматривать?

>>Интересно, является ли хоть один из перечисленных языков интерпретируемым?... java и smalltalk - точно не. Уже очень давно...

человек нарывается на то что уже обсуждали
на проблему различия объектных моделей и тп

если такое различие очень сильное
то тут что С что С++ одна херовина

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

>>kde, собранный gcc34 работал на qt, собранном с gcc40. Так что не надо тут. >это кто тебе сказал?

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

>ну что же вы беретесь спорить о том чего не знаете ?

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

например...такое:

object->method(a,b,c,d)

>точно. сломали при переходе на 3.4.

??

Что сломали?

... на девятую сотню пошли ...