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

прикольно. Пока ты сало на мало менял - я успел ответить :)

И этот человек - посылающий коллегам и партнерам ТОЛЬКО hard copies - в виде PDF, факсов и распечаток курьерской почтой - занимается корпоративным управлением? Назовите вашу корпорацию - и я тогда точно миллионером стану, закупив акции ваших конкурентов. Ибо корпорация которой управляют кдешнеги долго не живет.

>Чем не угодили Jabber-гейты? Почему я могу без проблем общаться в ICQ, IRC, Jabber и MSN?

Да, мне только еще гейтвей ставить или какую-нибудь проксю траффик перекодирующую - потому как мудаги разрабатывающие копыта упорно не хотят признавать что поддерживать надо стандарты де-факто, а не записанные на бумажке которой билли гейц подтирается. Я лучше gaim поставлю и буду работать out of the box, чем с помощью костылей компенсировать тупое упрямство разработчегов, которым уже несчетное количество раз присылали патчи для решения проблемы.

>Так KMail поддерживает сервера совместной работы

KMail-Exchange - в студию!!!!

> Кааак?? Там же "GUI на основе GTK"!

Я не комплексую насчёт инструментария. :)

> И этот человек - посылающий коллегам и партнерам ТОЛЬКО hard copies - в виде PDF, факсов и распечаток курьерской почтой - занимается корпоративным управлением?

Я говорил о том, что посылаю только твёрдые копии? Похоже, вы не в курсе, что такое корпоративное управление. Просветитесь прежде, чем снова сядите в лужу. :)

> копыта упорно не хотят признавать что поддерживать надо стандарты де-факто

Ещё раз: какие проблемы с Jabber-гейтом?

> KMail-Exchange - в студию!!!!

Нет под рукой - так бы носом ткнул. :)

>> Ничего не поделаешь, в C мы гораздо слабее гномовцев. :)

>И эти люди делают УНИХОВЫЙ десктоп! ;)

Эти люди делают _современный_ Униховый десктоп :D

> Опять же, компоновку не сделаешь многопанельной.

А это кому-то надо?

>> Planner

> Возможностей и стабильности намного меньше.

Чем у кого? KPlato? Ерунда.

>> Grisbi и Gnucash :) > Опять же, сильно не дотягивают.

Гооооонишь :)

> Уж Gnucash и не вспоминал бы. Попробуй на юникодной локали запустить. :)

Запустил. Что не так? :)

>А если гном считает, что PIM является частью необходимого минимума? То вам в гноме функций мало, то PIM выкинуть хотите... PIM - это как раз _необходимая_ функция, в отличие от способа задать разный фон разным апплетам.

Для корпоративного пользователя еще возможно (если только в организации не используется несовместимая с Evo groupware система ), для домашнего - явное излишество.
А причем здесь аплеты?

> Это относится к позиции "гном уникален и идеален".
>>А кто это сказал? И причем тут моно?
Так мне видится позиция антикритиков гнома в данном топике. Если вы не согласны с этим утверждением - приведите свою краткую формулировку вашей позиции.
А моно просто родственный гному проект с похожей позицией сторонииков в данном топике.

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

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

Вообще, как мне кажется, Evo в качестве дефолтного клиента - это не принципиальное желание дать пользователем PIM, а просто Ximian'овское наследство (так же как и наутилус) + Evo сама по себе одна из лучших гномовских программ - вот ее и ставят по дефолту.

> А это кому-то надо?

Да. Как для веб-страниц, так и для папок файлов.

> Чем у кого? KPlato? Ерунда.

Сравним по количеству фич? Просто прочтите на сайте.

> Гооооонишь :)

Аргументы?

> Запустил. Что не так? :)

Только не говори, что русский текст отображается нормально, и не появляется помойка новых окон - не поверю всё равно! :)

>Коммерческого софта под KDE не видели? :)

>Для начала - Hancom Office. Для продолжения - thekompany.com, далее - везде (почти). Для GNOME сходу не вспомню. Надо Imendio спросить :)

Спасибо за линк. Но походу зависимость от кде там только у одной проги Kapital. Остальное вроде QT

>> Чем у кого? KPlato? Ерунда.

> Сравним по количеству фич? Просто прочтите на сайте.

Зачем читать на сайте, если я сам его пытался использовать? :)

Hint: я никогда не спорю про софт, который так или иначе не использую сам. В отличие от ... :)

Кстати, нормальных сетевых диаграмм, которые нужны для проектирования, до сих пор нет даже в MS Project.

>> Гооооонишь :)

> Аргументы?

Ну ты же начал по недотягивание разглагольствовать. Вот сам и аргументируй :)

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

В Gtk2? :) Да нормально всё :)

> и не появляется помойка новых окон

Не наблюдаю :)

P.S. Как там поживает поворот снимка в Krita? 10% уже есть? :)

kbuildsyscoa - вроде как создание кэша desktop файлов(mime, и т.д.).

То, что этого похоже нет в gnome меня каждый раз(как я его вижу) удивляет. Апплет главного меню(Applications...) перечитывает (походу даже с диска) икошки всех приложений ==> на моем железе(AXP 2000,400Mb Ram) все это весьма тормозит.

У OpenOffice свой внутренний тулкит, который умеет рисоваться через gtk, kdelibs(использует qt и диалоги от kde) и вообще все, что движется.

> Эти люди делают _современный_ Униховый десктоп :D

В современных унихах плюсы заменили С в качестве базового языка? Где про это можно почитать?

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

URL?

2.0.2 точно можно собирать как с kde так и с gtk(что под windows - не знаю).

> Для корпоративного пользователя еще возможно (если только в организации не используется несовместимая с Evo groupware система ), для домашнего - явное излишество.

У домашнего пользователя не может быть списка дел (TODO)?

> приведите свою краткую формулировку вашей позиции.

"GNOME. We suck less" (сорри, утянуто у мутта).

> А моно просто родственный гному проект с похожей позицией сторонииков в данном топике.

И тем не менее официального отношения к гному не имеет. Оставляем за бортом.

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

Я возражаю, что Ева - больше, чем почтовый клиент (но и почтовый клиент тоже). А гном декларирует минимализм в бессмысленных излишествах, а не в полезных для дела функциях. Не надо путать гном с twm. Функции PIM - реальная польза.

> Evo в качестве дефолтного клиента - это не принципиальное желание дать пользователем PIM, а просто Ximian'овское наследство (так же как и наутилус) + Evo сама по себе одна из лучших гномовских программ - вот ее и ставят по дефолту.

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

А это кто http://kde.openoffice.org ?

>> Потому как нет под KDE-Qt приличных бесплатных приложений.

> Очень интересно, а под GTK есть? Только не старьё проприетарное, а нормальные проекты?

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

> Ага, не угодили. MDI нет, бегать и искать разбросанные панельки особого желания нет. Перекрытая рисунком панель инструментов GIMP - ад!

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

>>До меня один ананимус поднимал вопрос разработки GPL Qt, если троли поменяют лицензию QT. Организовать сообщество разработчиков в этой ситуации потребует большого времени и большого количества усилий.

>Ну а кто говорил что будет легко? =) Но главное то, что это _возможно_. Можно подумать, что нет более крупных проектов, которые делаются сплошь энтузиастами ;)

Потеря времени при написании программы может оказаться фатальной , это дополнительный большой риск с весьма неопределенным по времени решением.

Использовать последнюю GPL версию ни кто не мешает. imo

>> Эти люди делают _современный_ Униховый десктоп :D

>В современных унихах плюсы заменили С в качестве базового языка? Где про это можно почитать?

На сайте KDE 8)))))

А если серьезно - что такое "базовый язык"? Тот, на котором написана "базовая система" (== ядро, shell и утилиты из набора POSIX)? Так во всех современных Унихах это было написано лет 15 назад (или 20?), поэтому C++ никогда не будет "базовым языком" в этом смысле.

Если "базовый язык" - это язык, на котором написано большая часть ПО для Унихов, то здесь существует такая вещь, как инерция мышления. Ветераны Unix часто относятся к C++ плохо (я никогда не мог толком понять, почему). Чистый C плохо подходит для задач, оперирующих сложными данными (нет, ядро ОС к таким задачам не относится). В GCC даже сделали специальный препроцессор, и периодически начинаются разгворы "а не перейти ли нам на C++". Но "базовый язык" и не имеет дела со сложными данными.

От себя могу сказать, что более уёби^Wуродливой библиотеки, чем GLib, не встречал. Вместо того, чтобы всё это вытуживать, можно было просто определить подходящее подмножество C++.

Насчет почитать - попробуй это http://www.telegraph-road.org/writings/cpp_plea.html (не про "базовый язык", но всё же). Если не убедит, ну что ж... we'll have to agree to disagree, так, кажется, говорят ;)

>Ветераны Unix часто относятся к C++ плохо (я никогда не мог толком понять, почему)

вот когда почитаешь, что такое c++, как представлены в памяти объекты, и почем c++-библиотеки тяжело использовать из не-c++ языков - тогда поймешь

>Чистый C плохо подходит для задач, оперирующих сложными данными

а мужики-то не знают...может, тебе стоит поучить основы компьютерной грамотности?

>Вместо того, чтобы всё это вытуживать, можно было просто определить подходящее подмножество C++.

этот бред даже комментировать не хочется.

> we'll have to agree to disagree

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

>>Ветераны Unix часто относятся к C++ плохо (я никогда не мог толком понять, почему)

>вот когда почитаешь, что такое c++, как представлены в памяти объекты,

Я всё это знаю.

> и почем c++-библиотеки тяжело использовать из не-c++ языков - тогда поймешь

Тяжело по сравнению с чем? GLib тоже отнюдь не подарок.

>>Чистый C плохо подходит для задач, оперирующих сложными данными

>а мужики-то не знают...может, тебе стоит поучить основы компьютерной грамотности?

Учиться полезно всем. Тебе тоже.

>>Вместо того, чтобы всё это вытуживать, можно было просто определить подходящее подмножество C++.

>этот бред даже комментировать не хочется.

Ну так и не комментируй.

> не недооценивайте сложность структур данных в ядре.

Да никогда! 8) Я немного знаком с ядром Linux (хотя ничего сложнее драйверов символьных устройств не писал).

>Тяжело по сравнению с чем? GLib тоже отнюдь не подарок.

ты вообще разницу между c и c++ знаешь? Или для тебя c++ - это "си с классами" ?

>> и почем c++-библиотеки тяжело использовать из не-c++ языков - тогда поймешь

> Тяжело по сравнению с чем? GLib тоже отнюдь не подарок.

по сравнению с С-библиотеками.

> У нас просто различные требования к софту. Я уже писал, что нормально обхожусь только KDEшным софтом. И он меня, в отличие от GTKшного, вполне устраивает

А я только GTK приложениями, устраивают они в основном отсутствием кутешных тормозов, размазаности и уродских украшательств.

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

Точно по такой же причине не могу использовать QT/KDE софт, слишком мало функционала, зато куча уродских украшательств и тормоза.

> Это GIMP быстрый? Я вас умоляю! GTK+ 2.х вообще тормозной тулкит (в отличие от GTK+ 1.x и QT/KDE).

Чего O_O, по сравнению с тормазами куте и кед, гтк2 просто сверхсветовой!

>> и без постоянного использования gnome-приложений работать в линуксе невозможно, это три.

> Я же работаю. Значит, аксиома неверна. :)

С этим согласен, гномо-приложения сам не использую.

>>Тяжело по сравнению с чем? GLib тоже отнюдь не подарок.

>ты вообще разницу между c и c++ знаешь? Или для тебя c++ - это "си с классами" ?

Смотря что ты называешь "Си". Если C89, то да, Си++ - это Си c классами (а так же ссылками, шаблонами, исключениями и комментариями "//" :) ). C C99 сложнее.

С интересом послушаю твое объяснение о том, в чем же разница.

> Интересно, а почему у меня не тормозит, хоть железо и не новое? Может, не в DE дело?

Да неужели, не в ДЕ, под xfce и в console летает, под KDE тормозит, совсем не в DE дело?

> Или железо совсем древнее?

Совсем древнее: пень 2 233 МГц, 384 Мб озу, диск и котроллер UDMA-2

дивикс и иксвиды смотрятся на ура через мплайер, если он не под кедами запускается ;-)

>>> и почем c++-библиотеки тяжело использовать из не-c++ языков - тогда поймешь

>> Тяжело по сравнению с чем? GLib тоже отнюдь не подарок.

> по сравнению с С-библиотеками.

Ну, 0) некоторые трудности при вызове библиотеки, реализованной на другом языке, вполне ожидаемы, 1) нет никаких проблем вызвать функцию, объявленную как extern "C", 2) проблемы взаимодействия с Си - это проблемы (не такие уж большие) этапа разработки библиотеки. Конечно, если эти (пусть и небольшие) проблемы перевешивают выгоды от использования Си++, или если разработчики _думают_, что они перевешивают 8), Си++ не используется.

>С интересом послушаю твое объяснение о том, в чем же разница.

ABI

дальше, сам додумаешь? :)

>>С интересом послушаю твое объяснение о том, в чем же разница.

>ABI

extern "C"

> дальше, сам додумаешь? :)

С интересом жду продолжения

>Конечно, если эти (пусть и небольшие) проблемы перевешивают выгоды от использования Си++, или если разработчики _думают_, что они перевешивают 8), Си++ не используется.

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

>>Конечно, если эти (пусть и небольшие) проблемы перевешивают выгоды от использования Си++, или если разработчики _думают_, что они перевешивают 8), Си++ не используется.

>при написании _библиотеки_ выгод у с++ слишком мало. Неудобства перевешивают.

Зависит... Например, от размера библиотеки (но не только).

> Это для _приложения_ без разницы, что использовать

Яволь

>extern "C"

> дальше, сам додумаешь? :)

>С интересом жду продолжения

ты сам-то знаешь, зачем extern "C" нужен? =)

[quote]
If you are including a C header file that isn't provided by the system, you may need to wrap the #include line in an extern "C" { /*...*/ } construct. This tells the C++ compiler that the functions declared in the header file are C functions.
[/quote]

и далее, зачем писать библиотеки на с++ в таком стиле:

#ifdef __cplusplus
class A {
public:
A();
void b();
private:
int a_;
};
#else
typedef struct A
A;
#endif

#ifdef __cplusplus
extern "C" {
#endif
extern void c_function(A*); /* ANSI C prototypes */
extern A* cplusplus_callback_function(A*);
#endif

#ifdef __cplusplus
}
#endif

- только для того чтобы предоставить нормальный интерфейс другим языкам программирования? А как с либой, скомпиленной таким образом будет прога на с++ взаимодействовать? Или держать библиотеку в двух скомпилированных вариантах - "для правильного чистопоцанского С++" и "для остальных"?


ПРОЩЕ писать библиотеки/тулкиты на простых как валенок Сях. Плюс оно и компиляться в разы быстрее будет

> ПРОЩЕ писать библиотеки/тулкиты на простых как валенок Сях. Плюс оно и компиляться в разы быстрее будет

UFRaw использует плюсовую библиотеку Exiv2 для чтения/записи EXIF. Жалоб нет. Даже libopenraw планируется переписать на плюсы. Про всякие там VIGRA вообще молчу :)

>UFRaw использует плюсовую библиотеку Exiv2 для чтения/записи EXIF. Жалоб нет. Даже libopenraw планируется переписать на плюсы. Про всякие там VIGRA вообще молчу :)

если библиотека экспортирует только функции - то проблем как бы и нет. Но тогда это не ООП-либа. Спрашивается, нафуя С++? =)

объекты из С-програм тоже можно юзать, только на эти самые объекты накладываются нехилые ограничения, которые превращают классы в банальные структуры. Т.е. QT таким макаром заюзать не получится

> ты сам-то знаешь, зачем extern "C" нужен? =)

Ээээ... В моем ПТУ говорили, что это для того, чтобы определить функцию, следующую соглашению о вызовах языка Си.

> и далее, зачем писать библиотеки на с++ в таком стиле:

Начинает брезжить тусклый свет понимания... Так писать нельзя, это точно. Не пиши так, ОК? Как минимум - определение интерфейса для Си должно быть в отдельном файле, и определению классов там не место.

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

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

> А как с либой, скомпиленной таким образом будет прога на с++ взаимодействовать?

Если не сделаешь лшибок - то нормально.

> Или держать библиотеку в двух скомпилированных вариантах - "для правильного чистопоцанского С++" и "для остальных"?

Какая каша у тебя в голове (ты уж извини). Скажи сразу - не писал ты библиотек на Си++, которые должны были взаимодействовать с Си.

> ПРОЩЕ писать библиотеки/тулкиты на простых как валенок Сях.

ZIL, InterViews, Fresco, Qt. Хотя писать тулкиты на Си можно, кто ж спорит.

> если библиотека экспортирует только функции - то проблем как бы и нет. Библиотека может иметь и 2 интерфейса.

> Но тогда это не ООП-либа.

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

> Спрашивается, нафуя С++? =)

Библиотека - это не только интерфейс, но и реализация. И как язык реализации Си++ имеет преимущества.

>Какая каша у тебя в голове (ты уж извини). Скажи сразу - не писал ты библиотек на Си++, которые должны были взаимодействовать с Си.

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

про ограничения на доступ к данным C++ класса из C- и прочих языков напомнить?

>ZIL, InterViews, Fresco, Qt. Хотя писать тулкиты на Си можно, кто ж спорит.

и что? много под это пишут на Сях? Или на перле? Или на лиспе?

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

короче, если в твоей голове бродит мысль "надо переписать все на плюсах и тогда будет щастье" - то разговаривать тут в общем-то не о чем =)

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

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

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

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

И как нынче поступают подобные плюсовые библиотеки? Делают два набора интерфейсных функций - или обходятся одним, "плоским сишным"? Если второе - плевать, что оно внутри плюсовое (ну, с точностью до возможных осложнений при линковании - нужно плюсовый рантайм не забыть, хотя бы в динамицкой форме). Соббсно что внутри черного ящика - каждый злобный буратино (мейнтейнер библиотеки) пусть сам определяет. А вот наружу порядочной униховой библиотеки должен торчать сишный интерфейс (хорошо, если он при этом ОО). Кстати, в этом смысле геководов повбивав бы...

> И как нынче поступают подобные плюсовые библиотеки?

Честно говоря, мне пофиг, я пользователь. Но когда поднимался вопрос, что удобнее для разработчиков - сишный libopenraw или же плюсовый, вся кодла дружно закричала, что having a nice OO library from the start would make life a lot easier. Итого договорились на C++ library with pure C interface - для тех. кто пишет свой софт на Gtk/C и Mono.

>> Какая каша у тебя в голове (ты уж извини). Скажи сразу - не писал ты библиотек на Си++, которые должны были взаимодействовать с Си.

>мля...ты предлагаешь переписать существующую базу кода на с++?

Где именно я это предложил? Для протокола - нет, не предлагаю.

> про ограничения на доступ к данным C++ класса из C- и прочих языков напомнить?

Не надо. Я верю, что ты что-то такое слышал.

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

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

>> ZIL, InterViews, Fresco, Qt. Хотя писать тулкиты на Си можно, кто ж спорит.

> и что? много под это пишут на Сях? Или на перле? Или на лиспе?

Причем здесь писание на Сях? В конце концов, на Си++ можно писать как на Си. На Перле гуевых программ не пишут (или почти не пишут). Лиспа вообще не существует.

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

PyQt. По-моему, есть то же и для Ruby, и для Perl. Есть wxHaskell.

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

Не нормально. Это приемлемый (обычно) костыль для взаимодействия с языками предыдущего поколения. Кстати, вызывать функции на Си из ассемблера тоже неудобно. Это недостаток Си?

> короче, если в твоей голове бродит мысль "надо переписать все на плюсах и тогда будет щастье" - то разговаривать тут в общем-то не о чем =)

Не умеешь ты читать мысли.

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

> я в курсе.

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

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

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

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

>перечисли.

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

> И как нынче поступают подобные плюсовые библиотеки? Делают два набора интерфейсных функций - или обходятся одним, "плоским сишным"? Если второе - плевать, что оно внутри плюсовое

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

> А вот наружу порядочной униховой библиотеки должен торчать сишный интерфейс (хорошо, если он при этом ОО).

А что, "порядочность" Униховой либы определяется языком реализации? А я-то думал, мантрами типа "do just one thing, and do it right", "small is beautiful", "software tool philosophy", "KISS", "DRY" 8)

> Кстати, в этом смысле геководов повбивав бы...

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

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

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

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

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

>Не надо. Я верю, что ты что-то такое слышал.

это не "что-то такое слышал", а самый что ни на есть факт =)

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

чтобы из жабы дергать плюсовый ооп - нужно извращаться даже поболее чем в Си :) А веть казалось бы - тоже ООП язык. Ты наверное, не понимаешь, что проблема - в ABI. Оно у с++ одно, у жабы - другое, у питона - третье. У каждого ООП-языка - своё =) И везде приходится сишные классы заворачивать и потом разворачивать. Так что? Плавно приходим к мысли, что писать нужно только на плюсах, а все остальное фтопку? Или все-таки соглашаемся, что плюсовые либы - это худший вариант, чем плюсовые либы? =)

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

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

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

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