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

>>Вообще-то ООП-либу возможно написать и на чистом Си.

> я в курсе.

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

> А если ты не в курсе, то Glib и Gtk - это ООП =)

Я в курсе, Такое вот ублюдочное ООП.

>>И как язык реализации Си++ имеет преимущества.

>перечисли.

Исключения (вместо goto или лапши из if), классы и наследование, шаблоны (вместо макросов). Я бы добавил еще и большую выразительность (за счет перегрузки операторов), но не стану: почему-то все считают, что перегрузка операторов - это плохо.

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

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

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

goto и лапши из if в glib/gtk не наблюдал что-то :) Классы и наследования там есть. Шаблоны...вялый аргумент. Кодогенерация рулит =)

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

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

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

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

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

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

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

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

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

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

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

Афигеть.

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

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

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

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

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

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

>Афигеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например

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

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

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

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

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

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

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

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

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

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

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

>Например

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

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

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

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

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

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

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

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

:)

>>Например

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

тему напомни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ферштейн?

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

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

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

Не все, а только некоторые. Думаю, это те, кто не умеет этим безопасно пользоваться =)

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

Ну все, писец, приехали.... =)))

geek, ты жжош! Ты взаправду жжош!!! =)))))

>Ну все, писец, приехали.... =)))

я имел ввиду "не обработал ли ты исключение или не проверил результат"

вот так правильно =)

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

что значит "договорились"? С-вызов - это банальный call по адресу и последующий возврат в точку вызова. Если угодно - это фундаментальное свойство процессоров =) НИЖНИЙ УРОВЕНЬ. Других вариантов просто нет :)

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

жаба - это вещь в себе. Хреновое взаимодействие с не-жабским окружением там заложено генетически. Единственный способ как-то пофиксить - это использовать взаимодействие через сокеты/dbus. Т.е. клиент-серверная модель :)

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

>что значит "договорились"? С-вызов - это банальный call по адресу и >последующий возврат в точку вызова. Если угодно - это >фундаментальное свойство процессоров =) НИЖНИЙ УРОВЕНЬ. Других >вариантов просто нет :)

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


call или jmp - вызов на уровне ассемблера(НИЖНИЙ УРОВЕНЬ).


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


>жаба - это вещь в себе. Хреновое взаимодействие с не-жабским >окружением там заложено генетически. Единственный способ как-то >пофиксить - это использовать взаимодействие через сокеты/dbus. Т.е. >клиент-серверная модель :)


java/.net/ruby/.... - можно, C++ - нельзя?

>java/.net/ruby/.... - можно, C++ - нельзя?

отличий между жабой, net, ruby и C++ не видишь? тады в морг =)

вижу, но все они весьма замкнуты.

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

разве что после всеобщего перехода на .NET

Не обязательно.


Сейчас заглянул /usr/include/c++ и обнаружил там кроме стандартной библиотеки C++ еще и такое:

/usr/include/c++/4.1.1/javax/swing/JButton.h:


// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-

#ifndef __javax_swing_JButton__
#define __javax_swing_JButton__

#pragma interface

#include <javax/swing/AbstractButton.h>
#include <gcj/array.h>

extern "Java"
{
namespace javax
{
namespace accessibility
{
class AccessibleContext;
}
namespace swing
{
class JButton;
class Icon;
class Action;
}
}
}

> Сейчас заглянул /usr/include/c++ и обнаружил там кроме стандартной библиотеки C++ еще и такое:

> /usr/include/c++/4.1.1/javax/swing/JButton.h:

каким боком это "межязыковой OOP ABI"?

Нет, я просто не знал, что из C++ можно вызывать код на java(gjc). Нужно будет опробовать.