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

>>Тогда как понимать твои слова насчет "не ООП-либы" ?

>так и понимать. Дергать плюсовый ооп из сишного ооп - гемор

Нормально упакованный - не больший гемор, чем обычные Си-функции.

>>Исключения (вместо goto или лапши из if), классы и наследование, шаблоны (вместо макросов).

>goto и лапши из if в glib/gtk не наблюдал что-то :)

Обработка ошибок часто игнорируется. Исключения как раз хороши тем, что не позволяют ошибке уйти незамеченной. Впрочем, в GUI-тулките это может быть и не критично.

> Классы и наследования там есть.

Ну тогда они и в PL/I есть, и в Ассемблере.

> Шаблоны...вялый аргумент.

ну хоть один аргумент признал.

> Кодогенерация рулит =)

Афигеть.

>Пользователю - плевать. Разработчику библиотеки - нет.

зато, к примеру, круг разработчиков KDE/QT приложений состоит только из с++ кодеров.

>А что, "порядочность" Униховой либы определяется языком реализации?

если ты напишешь либу на smalltalk, то она в мире юнихов не будет считаться "порядочной" :)

>Нормально упакованный - не больший гемор, чем обычные Си-функции.

нормально упакованный - это без виртуальных методов от родителя вплоть до потомка? :) а при чем тут ООП? =)

>Обработка ошибок часто игнорируется. Исключения как раз хороши тем, что не позволяют ошибке уйти незамеченной.

в обоих случаях прога грохнется :) обработал ты исключение или нет

>Ну тогда они и в PL/I есть, и в Ассемблере.

о чем и речь. ООП - это парадигма. А С++ - это реализация парадигмы ООП, плохо совместимая с другими реализациями.

>Афигеть.

угу. Кстати, если ты не в курсе, тот же PyQt использует кодогенерацию. Потому что руками делать обвязку для Qt - это застрелиться можно. Вот такой "удобный" язык С++ :)

и wine тоже юзает кодогенерацию :) Да много где она используется...

>>Так - с Си. Остальные современные языки - объектно-ориентированные.

>чтобы из жабы дергать плюсовый ооп - нужно извращаться даже поболее чем в Си :) А веть казалось бы - тоже ООП язык.

Во-первых, не надо приплетать Java (и .NET) - у них принципиально другой подход. Во-вторых - JNI неудачный интерфейс.

> Ты наверное, не понимаешь, что проблема - в ABI.

Уже понимаю. Ты открыл мне глаза, спасибо.

> Оно у с++ одно, у жабы - другое, у питона - третье. У каждого ООП-языка - своё =)

Глубокая мысль.

> И везде приходится сишные классы заворачивать и потом разворачивать.

Какая разница, заворачивать/разворачивать Си-классы или Си++-классы? А писать удобнее на Си++.

> Так что? Плавно приходим к мысли, что писать нужно только на плюсах, а все остальное фтопку?

Интересно, как ты пришел к этой мысли?

> Или все-таки соглашаемся, что плюсовые либы - это худший вариант, чем плюсовые либы? =)

Segmentation fault (core dumped)

>>Причем здесь писание на Сях? В конце концов, на Си++ можно писать как на Си.

>ты, похоже, воспринимаешь С++ как си с классами. Нельзя на с++ писать как на сях. Да, они очень похожи, но это разные языки

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

>>Кстати, вызывать функции на Си из ассемблера тоже неудобно.

>почему? с каких пор call стал неудобен? Можно, конечно сравнить с вызовом плюсового метода, но там вообще каша будет =)

Когда ты последний раз писал вызов Си-кода из Ассемблера? Сам вызов - да, одна-две инструкции. Но занесение параметров в стек и извлечение результатов приходится делать руками. Если параметр - структура, приходится выделять под нее память.

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

>>Нормально упакованный - не больший гемор, чем обычные Си-функции.

>нормально упакованный - это без виртуальных методов от родителя вплоть до потомка?

Нет, это с виртуальными методами, оформленными как вызовы Си-функций.

>>Обработка ошибок часто игнорируется. Исключения как раз хороши тем, что не позволяют ошибке уйти незамеченной.

>в обоих случаях прога грохнется :) обработал ты исключение или нет

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

> ООП - это парадигма. А С++ - это реализация парадигмы ООП, плохо совместимая с другими реализациями.

Вообще-то они _все_ между собой плохо совместимы. Как насчет вызовов Python <-> Ruby, Java <-> Python (не рассматриваем случай единой виртуальной машины)? А Си++ - первая из широко применяемых и эффективных реализаций ООП.

> Кстати, если ты не в курсе, тот же PyQt использует кодогенерацию. Потому что руками делать обвязку для Qt - это застрелиться можно. Вот такой "удобный" язык С++ :)

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

> и wine тоже юзает кодогенерацию :) Да много где она используется...

Угу. Я тоже ее использую. Но всему свое место, и, например, использовать кодогенерацию для создания контейнеров типа вектора или списка - это overkill.

>Во-первых, не надо приплетать Java (и .NET) - у них принципиально другой подход. Во-вторых - JNI неудачный интерфейс.

ну ладно. А питон сойдет? Или ocaml? smalltalk? Object Pascal? :) Много там у нас осталось ООП-языков? =)

>Какая разница, заворачивать/разворачивать Си-классы или Си++-классы? А писать удобнее на Си++.

c-классы не нужно заворачивать :) только разворачивать и то не всегда

>Segmentation fault (core dumped)

ниасилил? =)

>Когда ты последний раз писал вызов Си-кода из Ассемблера? Сам вызов - да, одна-две инструкции. Но занесение параметров в стек и извлечение результатов приходится делать руками. Если параметр - структура, приходится выделять под нее память.

макросы, макросы, макросы! И зачем выделять память? Поделись сакральным знанием. Если у нас есть набор параметров, то логично предположить, что память уже где-то была выделена =)

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

угу. а виртуальный?

> Пользователю - плевать. Разработчику библиотеки - нет.

Извините, я слегка в терминах запутался. Пользователь - это тот, кто использует библиотеку? Да, ему плевать, если API поддерживается, стабилен и не создает лишних внешних зависимостей (например, плюсовый рантайм?). Разработчику библиотеки - разумеется, не плевать. Но платой за унихокорректный API для разработчика либы будет лишний геморрой по "планаризации" его красившенького плюсового API. Матюги и кровавыя слезы.

> А что, "порядочность" Униховой либы определяется языком реализации?

Определяется соответствием ее API и ABI принятым в унихе правилам. Которые (по чисто случайному совпадению) являются сишными. Кстати, IIRC на самой заре винюковой молодости МС пытались ввести в винюках паскалевские соглашения (винюки на паскале начинали ваять). Не так бы это было страшно, если б в некоторый момент не оказалось, что реально в системе мешанина соглашений.

> А кто они такие и что плохого сделали?

Мазилу делают. Геко делают. И API их плюсовый, с которым было некоторое кол-во плясок при смене поколений gcc.

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

Мне полностью манглированное плюсовое имя какого-нибудь невиртуального метода тут привести - или не стОит, вдруг тут дамы?

>Нет, это с виртуальными методами, оформленными как вызовы Си-функций.

т.е., обертка вокруг класса?

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

грохается. на первом же ASSERT :)

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

для си биндинг написать в разы легче на самом деле. Именно поэтому биндинги к GTK штампуются, как горячие пирожки. А PyQt стал более менее юзабельным только после того, как написали специальную и достаточно нетривиальную программу, которая эти биндинги делает =)

>Но всему свое место, и, например, использовать кодогенерацию для создания контейнеров типа вектора или списка - это overkill.

overkill - это когда для использования библиотеки, позиционируемой как тулкит приходится писать кодогенераторы чтобы получить биндинги к нужному языку. В данном случае, получается что разработчик поленился, и вынудил тех, для кого он собственно и делал тулкит, выполнять лишние телодвижения. Нет уж, будь добр, если пишешь либу - пиши на сях. А с++ будешь юзать для своих проектов. Иначе твою либу постигнет судьба DCOP :)

Что ты используешь при написании _приложений_ - твое личное дело. Но юникс - это Си. Просто потому что лучше чем Си ничего не придумано. Всякие ООП языки вынуждают создавать прослойку. А межязыковой OOP ABI вряд ли стандартизируют в обозримом будущем

>Мне полностью манглированное плюсовое имя какого-нибудь невиртуального метода тут привести - или не стОит, вдруг тут дамы?

ну... в Vtbl же лезть не надо :)

>Мазилу делают. Геко делают. И API их плюсовый, с которым было некоторое кол-во плясок при смене поколений gcc.

ну они же не виноваты - им оно такое в наследство досталось

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

>Мне полностью манглированное плюсовое имя какого-нибудь невиртуального метода тут привести

Но _вызывается_ он точно так же? ;)

> - или не стОит, вдруг тут дамы?

Да откуда здесь дамам взяться? 8)

> Но _вызывается_ он точно так же? ;)

Но попытка вписать его имя на память после call - будет стОить мне остатков разума;)

>>Во-первых, не надо приплетать Java (и .NET) - у них принципиально другой подход. Во-вторых - JNI неудачный интерфейс.

>ну ладно. А питон сойдет?

У Питона нет проблем с обращением к Си++ - объектам (ну или я их не вижу в повседневной работе).

>>Когда ты последний раз писал вызов Си-кода из Ассемблера? Сам вызов - да, одна-две инструкции. Но занесение параметров в стек и извлечение результатов приходится делать руками. Если параметр - структура, приходится выделять под нее память.

>макросы, макросы, макросы!

Макросы тоже писать надо.

> И зачем выделять память? Поделись сакральным знанием.

Кто из нас специалист по ABI, ты или я? Должен знать, как вызываются Си-функции, если один из параметров - структура.

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

>угу. а виртуальный?

Подозреваю, что гораздо труднее ;), но на практике мне это никогда не было нужно. Наверное, в общем случае для этого надо быть компилятором :/

>> Пользователю - плевать. Разработчику библиотеки - нет.

>Извините, я слегка в терминах запутался. Пользователь - это тот, кто использует библиотеку?

Да

>> А что, "порядочность" Униховой либы определяется языком реализации?

>Определяется соответствием ее API и ABI принятым в унихе правилам. Которые (по чисто случайному совпадению) являются сишными.

То есть Си++ либа вполне может быть "порядочной". А если предоставляет 2 интерфейса - так вообще сказка.

Еще раз выражу свою мысль - Си++ либа может предоставлять как Си-, так и Си++-интерфейс. В любом случае применение Си++ оправдано тем, что он дает больше возможностей программисту. А то, что Си++-интерфейс не является "порядочным"... "Пути меняются, Стилгар. Ты и сам их менял" -- Ф.Херберт, "Дюна"

> Кстати, IIRC на самой заре винюковой молодости МС пытались ввести в винюках паскалевские соглашения

IIRC, это соглашение так и осталось для системных dll.

>> А кто они такие и что плохого сделали?

>Мазилу делают. Геко делают.

Не, не надо их убывать. Хорошее дело делают.

> И API их плюсовый, с которым было некоторое кол-во плясок при смене поколений gcc.

Да, смена ABI - вещь болезненная :( Но здесь дистростроители могли бы и облегчить жизнь.

Таак, из Intel vs. Gnome перекатились в Gnome vs. KDE, потом в обсуждение приложений Gtk vs. Qt, потом в обсуждение работы на декстопе в стиле Gnome vs. стиле KDE, потом в C++ библиотеки против C, потом в принципы программирования на C и C++. А дальше что? Давайте уже сразу, без этих новомодных штучек, Vim против Emacs пообсуждаем. Народ заодно разогреется, а то валить из этого треда уже стали, беседуют пара людей между собой и все...

Молодое поколение выбирает Kate vs. gedit

>У Питона нет проблем с обращением к Си++ - объектам (ну или я их не вижу в повседневной работе).

у питона класс имеет кучу метаданных :) т.е. обёртка нужна в любом случае. Если это "нет проблем" то я теряюсь, что для тебя проблема =)

>Кто из нас специалист по ABI, ты или я? Должен знать, как вызываются Си-функции, если один из параметров - структура.

хочешь сказать, что в с++ или с+ можно легко передать функции нулевой указатель, а в асме нет? =) память выделять надо в любом случае. Так что пример левый =)

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

началось. "мне это не было нужно". Хотя, про то что если наружу торчат только статические методы - то плевать, что там у либы внутри - я уже говорил =)

>Да, смена ABI - вещь болезненная :( Но здесь дистростроители могли бы и облегчить жизнь.

причем тут дистростроители? или предлагаешь остановиться на одной из версий gcc и больше _никогда_ её не менять? :)

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

> Не "другим языкам", а Си.

Да не, другие языки пользуются Си соглашением ;-)

>Таак, из Intel vs. Gnome перекатились в Gnome vs. KDE, потом в обсуждение приложений Gtk vs. Qt, потом в обсуждение работы на декстопе в стиле Gnome vs. стиле KDE, потом в C++ библиотеки против C, потом в принципы программирования на C и C++. А дальше что?

если я правильно помню генплан, то скоро начнем обсуждать принципы построения AI в общем и системы распознавания образов в частности. Где-то постов через 50

:)

>>Нет, это с виртуальными методами, оформленными как вызовы Си-функций.

>т.е., обертка вокруг класса?

Например

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

>грохается. на первом же ASSERT :)

А когда он будет, этот assert? Будет ли вообще? И не забывай - исключение можно перехватить и разумно обработать (в отличие от).

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

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

Не юли. Так "кодогенерация" или "писать"? По моему опыту, писать обертки вручную проще для Си++ (Python). А уж если SWIG использовать...

>>Но всему свое место, и, например, использовать кодогенерацию для создания контейнеров типа вектора или списка - это overkill.

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

Так я не понял, использование кодогенерации для векторов/списков - это нормально?

> Иначе твою либу постигнет судьба DCOP :)

Вот только не надо приводить в пример противостояние GNOME и KDE. Это чистая политика. GNOME - "наш ответ KDE" от RedHat. NIH, блин. Не дадим основать свободный десктоп на несвободной либе! Зла не хватает 8/

> Перле гуевых программ не пишут (или почти не пишут).

frozen-bubble - консольная?

> Лиспа вообще не существует.

Ну надо было тебе такую чушь сказать на этом сайте ;-)

> Кстати, вызывать функции на Си из ассемблера тоже неудобно. Это недостаток Си?

Вот те раз, а нам удобно :-P Скорей недостаток твоего образования :-D

>>У Питона нет проблем с обращением к Си++ - объектам (ну или я их не вижу в повседневной работе).

>у питона класс имеет кучу метаданных :)

Зависит...

> т.е. обёртка нужна в любом случае.

Конечно

> Если это "нет проблем" то я теряюсь, что для тебя проблема =)

"нет проблем" == "обертка тривиальна".

>>Кто из нас специалист по ABI, ты или я? Должен знать, как вызываются Си-функции, если один из параметров - структура.

>хочешь сказать, что в с++ или с+ можно легко передать функции нулевой указатель, а в асме нет? =)

Нет, не хочу.

> память выделять надо в любом случае. Так что пример левый =)

Ты специалист по ABI или погулять вышел?

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

>началось. "мне это не было нужно".

Ну извини, что у меня так судьба сложилась. Если ты такое делал - поделись впечатлениями.

> В частности, если ты не любишь Си++, но вынужден использовать Си++-тулкит, пиши свою прогу как на Си.

Извини, но Си и Си приплюснутые уже эволюционировали в два разные ветки, код написанный для Си теперь не всегда понимается приплюснутым компилятором. :-(

>Например

void c_call(void* o,int a) { ((Obj*)o)->vcall(a); }

примерно так =)

>Не юли. Так "кодогенерация" или "писать"?

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

>Так я не понял, использование кодогенерации для векторов/списков - это нормально?

зависит от ситуации. Если основа программы - списки, то её и писать нужно не на сях и не на плюсах =)

>Не дадим основать свободный десктоп на несвободной либе!

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

:)

>> Перле гуевых программ не пишут (или почти не пишут).

> frozen-bubble - консольная?

Там было "почти"

>> Лиспа вообще не существует.

> Ну надо было тебе такую чушь сказать на этом сайте ;-)

А я специально, по злобе оттого, что ниасилил.

>> Кстати, вызывать функции на Си из ассемблера тоже неудобно. Это недостаток Си?

> Вот те раз, а нам удобно :-P

Рад за вас

> Скорей недостаток твоего образования :-D

Куда мне до тебя... Ты, наверное, дипломированный специалист по вызову Си-функций из Ассемблера.

> То есть Си++ либа вполне может быть "порядочной". А если предоставляет 2 интерфейса - так вообще сказка.

Я ж уже выше сказал - дайте мне сишный API/ABI, а внутри хоть на logo мучайтесь...

> В любом случае применение Си++ оправдано тем, что он дает больше возможностей программисту.

В том-то и дело, что нет. Впрочем, тут вопрос о том, что считать возможностями...

> Пути меняются, Стилгар

Пока в унихе не поменялось соглашение о том, как должны быть организованы API/ABI - С остается его языком. А плюсы - языком BeOS и кого там еще...

> IIRC, это соглашение так и осталось для системных dll.

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

> Не, не надо их убывать. Хорошее дело делают.

Только поэтому я их еще и не убил;) Но с API они здорово ошиблись;)

>"нет проблем" == "обертка тривиальна".

а если "обертка не нужна" - это как? :) лучше, чем "обертка тривиальна" или хуже? =)

>>хочешь сказать, что в с++ или с+ можно легко передать функции нулевой указатель, а в асме нет? =)

>Нет, не хочу.

>> память выделять надо в любом случае. Так что пример левый =)

>Ты специалист по ABI или погулять вышел?

потрудись объяснить, что ты имел ввиду под выделением памяти. А то я уже нихера не понимаю твоей логики.

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

впечатления я уже говорил. Использовать c++ можно только "внутри", чтобы наружу никаких плюсов не торчало. Всё. Иначе гарантирован геморрой.

>Только поэтому я их еще и не убил;)

а что, есть возможность? =)

Почти что ;-)

>>Например

>void c_call(void* o,int a) { ((Obj*)o)->vcall(a); }

>примерно так =)

Это был не вопрос :D "Например" == "один из возможных вариантов"

>> Не юли. Так "кодогенерация" или "писать"?

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

Если писать свои кодогенераторы, то конечно.

>>Так я не понял, использование кодогенерации для векторов/списков - это нормально?

> зависит от ситуации. Если основа программы - списки, то её и писать нужно не на сях и не на плюсах =)

То есть - _не_ нормально?

> Напомню, на тот момент лицензия qt сильно ограничивала распространение программ.

Не надо напоминать. Особенно то, чего не было.

> Но все равно, нашлись умники, осилившие кидание кнопок в С++Builder на формочку, подучились и написали кде

Это такой изящный уход от темы?

>Куда мне до тебя... Ты, наверное, дипломированный специалист по вызову Си-функций из Ассемблера.


push %ebx
push Main
push p_disp
call XSelectInput


офигенно сложно, да? :)

>То есть - _не_ нормально?

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

>Не надо напоминать. Особенно то, чего не было.

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

>Это такой изящный уход от темы?

тему напомни

> А межязыковой OOP ABI вряд ли стандартизируют в обозримом будущем

В рамках .NET и Java - стандартизируют. И, если моя память мне ни с кем не изменяет, Си++ ABI уже стандартизован.

>> В частности, если ты не любишь Си++, но вынужден использовать Си++-тулкит, пиши свою прогу как на Си.

> Извини, но Си и Си приплюснутые уже эволюционировали в два разные ветки, код написанный для Си теперь не всегда понимается приплюснутым компилятором. :-(

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

>В рамках .NET и Java - стандартизируют. И, если моя память мне ни с кем не изменяет, Си++ ABI уже стандартизован.

я имел ввиду _общий_ стандарт. Для вызова функций такой единый ABI есть, а для ООП (вызов методов, представление экземпляра класса и т.д.) нету. Упс? =)

> push %ebx > push Main > push p_disp > call XSelectInput

>офигенно сложно, да? :)

Во-первых, ты выбрал простой вариант. Во-вторых, ты забыл убрать параметры со стека.

>>В рамках .NET и Java - стандартизируют. И, если моя память мне ни с кем не изменяет, Си++ ABI уже стандартизован.

>я имел ввиду _общий_ стандарт.

Стандарт .NET общий для: Си++, C#, J#. Стандарт общий Java: Java, Python, Groovy, (Ruby?).

> Для вызова функций такой единый ABI есть, а для ООП (вызов методов, представление экземпляра класса и т.д.) нету. Упс? =)

Ты не читаешь? Я написал про 3 стандарта - 2 многоязыковых для соответствующих виртуальных машин, 1 для "родного" кода, скомпилированного из Си++.

>>Не надо напоминать. Особенно то, чего не было.

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

Ты сказал, что она накладывала ограничения на распространение программ. Этого не было.

>> Это такой изящный уход от темы?

> тему напомни

Флэйм о пригодности Си++ для разработки библиотек. И как модеры нас терпят?

Зачем мучать себя, запихивая в прокрустово ложе совместимости с плюсами, вместо того чтобы насладиться мощью C99? Объясните мне смысл этого явления? Я еще готов понять мотив "совместимость со старым стандартом С"... (хотя на практике это и даст совместимость с плюсами).

> Зачем мучать себя, запихивая в прокрустово ложе совместимости с плюсами, вместо того чтобы насладиться мощью C99?

AAAAAAAAAAAAA!!!!!!!!!!!!!!!!

> AAAAAAAAAAAAA!!!!!!!!!!!!!!!!

Я рад, что Вы оценили глубину моей мысли.

> приличных бесплатных приложений под КДЕ не названо. слив засчитан :)

Уже названо. И обсуждено. Протрите глаза. :)

> так и запишем -- не умеет организовать рабочее пространство :)

Тык мне работой надо заниматься, а не окошки раскладывать. И KDE мне это позволяет. :)

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

а это, по-твоему, не ограничение, когда "вот тут можно, а вокруг - ни-ни!" ?

>Стандарт .NET общий для: Си++, C#, J#. Стандарт общий Java: Java, Python, Groovy, (Ruby?).

ты русский язык в албании учил? Я говорю об _общем_ стандарте на ООП ABI . Понимаешь? ОБЩЕМ. Для виртуальных машин, интерпретаторов и компиляторов

даже для компиляторо единого стандарта на ООП ABI нет и не предвидится!

а ты предлагаешь на этом бардаке делать библиотеки :)

ферштейн?

Насладиться C99 - поюзать инициализацию структур и вроде еще новый непревзойденный тип long long? Да, оно стоит того, чтобы забить на C++.

То, что создатели этих языков договорились только до общего C вызова imo не есть хорошо, но не как не характеризует библиотеки каждого.

Geek, ты же вроде не нападаешь на java с требованием предоставить C биндинги к swing?

>Ну если на компьютере не работать, а дрочить - то зачем нам вообще приложения?

Ну если Вам не нужны --- на здоровье, дрочите дальше =)

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

А что, все что не Inkscape, не Gimp и не Hugin --- это уже не приложения, а красивые утилитки?

Да-да, я пользователь средненького уровня. Я не использую вышеперечисленные приложения, а юзаю красивые утилитки kate, gcc, tetex =)