Вызов метода

>А как вызов метода в этом случае будет выглядеть?

А методы не описываются внутри struct GSomeClass { }. 
Внутри класса описываются только виртуальные методы. А методы 
класса - это обычные функции с уникальным именем, в которое 
входит название класса (чтобы не пересекаться с другими функциями 
других классов). То есть, если в С++ это будет 
Object.Method( //параметры ),
то тут - object_method(GObject *self, /* параметры */ ).

Если ты в программе захочешь вызов метода сделать, то пишешь так

GObject *object;
object_method (object, /* параметры */);

Если хочешь сделать вызов какого-то метода предка, то пишешь так

proto_object_method (PROTO_OBJECT(object));

Ну то есть и тут надо помнить, в каком предке реализован нужный 
метод. Неудобство? Да. С препроцессором проблема решается. Хотя и без
препроцессора народ умудряется программы писать. :)

Отмечу, что Glib предгается, как "общий знаменатель" для общения приложений, а не как система программирования. Кто программировал по Windows, вспомните, кто из вас делал попытки реализовывать сложный интерфейс непосредственно на Win API? Думаю, это редкая пташка... Все пользовались то MFC, то VCL из Delphi, то еще чем-нибудь (давно уже ничего под вин не писал - не знаю, что там появилось с тех пор :). Писать можно и на Win API, но это великий геморрой. Вот Glib и прочится на это место в данном случае. Но для этого все должны договориться использовать Glib. То есть и Qt должны использовать именно его. А это пока нереально по политическим мотивам. Это же для многих будет шоком! Вывески новостей "Qt пошел на поклон к Glib!" ... Вот это флейма на весь интернет будет :))

>Не знаю, как kde, а вот про gnome это точно неверно утверждается. В gnome вес имеют две компании - RedHat и Ximian, которые и задают всему "хороший" тон. Если Novell договорится с RedHat, то все у него получится.

Ты забыл Sun Microsystems! Они тоже любят GNOME. :)

А, может быть, тут D-BUS главную роль сыграет. Это хороший компромисс, так как не задевает самолюбия сторон, а предлагает унифицированный уровень, к которому пишется отдельно API для Qt, Отдельно - для Glib. Ну то есть принцип "посредника при переговорах". :)...

Народ, спасибо всем за разъяснения! Сейчас постараюсь ответить всем.

>Про то, что кол-во кода сокращается при помощи препроцессоров - уже указали. Вообще, С++ исходно был препроцессором (точнее, многие его ранние реализации просто генерили С код). Так почему же не счесть, что специально заточенный под g-разработку препроцессор gok лучше, чем препроцессор общего назначения c++?:) Да, С, не будучи ОО языком, становится очень многословным в ОО режиме, это очевидно и с этим глупо спорить. Поэтому стремление сократить исходный код при помощи препроцессоров - естественно.

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

Cfront именно так и поступал (кстати, его разрабатывал сам Строуструп) - генерил С код из С++ исходников. Но это был уже другой язык, со своими ключевыми словами. А чем оперирует при этом gok? (я имею в виду ключевые слова, которые он ищет по тексту)
Ведь если бы использовались лишь макросы, хватило бы и cpp?

>Про PyQT. Раскройте, плиз, мне глаза - реализация этого байндинга обходится без extern "C"? Или все-таки пришлось сделать внешний интерфейс с соглашениями C?

Честно говоря, я не знаю. Потому как использовать не приходилось. А что может мешать питону посредством привязок свои объекты "связывать" напрямую с объектами Qt? http://www.riverbankcomputing.co.uk/sip/docs/sipref.html

>Вообще, подходя системно, вопрос о языках - это два вопроса - про реализацию и про интерфейсы. В вопросе об интерфейсах я выступаю за то, что API для широко используемых платформ должны формулироваться в соответствие с соглашениями С. Про реализацию - вопрос для меня вторичный (как старый жаваписец, я давно считаю хороший интерфейс важнее хорошей реализации). Как хотите. так и реализовывайте. Разве что помните про все потенциальные, широкой рукой раскиданные, грабли С++ (о которых я уже говорил неоднократно и про которые кто-то выразился в смысле "страшен С++ код чайника").

Да, программированию нужно учиться, и учиться долго, а не на 5-дневных курсах. Управлять самолетом пилоты тоже не один год учатся. Пора уже от "кукурузников" переходить к чему-нибудь более "широкофюзеляжному".

>Последний вопрос. Я еще не читал сегодняшние новости. Где новел выбрал Qt? Химиан теперь переводит evolution на Qt?

http://www.linux.org.ru/profile/ANDI/view-message.jsp?msgid=517298&back=%...

>А ничего, что ядро и иксы написаны на Сях? То, что мозилла на С++ - это тихий ужас и преступление перед мировой общественностью. Бинарники и плагины при смене версий gcc год утрясти не могли (преступление - это я не про реализацию, это я про интерфейс). Если у проекта, сколь угодно большого, есть публичный API, который будут использовать другие проекты - этот API должен выражаться в на С. Тчк. (Интерфейс на CORBA тоже подпадает под эту статью:)

Чего. Я же упоминал про BeOS. С нуля написали систему на С++. При этом чрезвычайно легкую и быструю. Так что "не так страшен черт, как его рисуют".
По поводу мозилы и всего остального, у кого "преступный С++ интерфейс".
Я очень надеюсь, что когда-нибудь стандартизируют экспортируемые имена С++.
Тут ничего не поделаешь.

Итак, углубим про препроцессоры. Есть срр - простенький и хиленький. Есть С++ - могучий ОО, с проверкой типов и пр. Есть gok - средней тяжести (по логарифмической шкале, я бы сказал:), специально заточенный под gtk.

Очевидно, что cpp хил. Т.е. народ пытается использовать всю его мощь в gobject, по возможности (тут еще надо учесть, что есть всякие extensions, которые приходится переносить с компилятора на компилятор) - но получается плоховато.

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

Очевидно, что gok не так мощен, как С++. Его задача - сократить многословность при создании gtk объектов. Эту задачу он решает, достаточно успешно. При этом - заметьте - никаких "неявностей" и "переопределений" (как в С++) не генерируется. Программист четко знает, в какое двоичное представление будет скомпилирован его код. Да, разумеется, богатство и мощь STL таким образом не получить, это точно. Но и всяких тонких багов, на которые так богат С++, тоже не схлопочешь.

Да, любителям С++. Меня всегда слегка забавляло, что { A a=b; } не то же самое, что { A a; a=b; }

2Zubok: спасибо, я вчера стУпил, забыл про кастинг к базовому классу.

Да, еще. Макросы - это потенциальное зло, когда используется тупой cpp. Хороший, умный макропроцессор - сила. Доказательство тому - C++.

> Управлять самолетом пилоты тоже не один год учатся

Видите ли, лично ко мне знание о граблях С++ пришло с опытом. За время его получения я написал некоторое кол-во кода. Этот код - его либо в помойку надо было отправлять, либо выпрямлять и объяснять (что в реальности и происходило, спасибо учителям) - но это же экономически невыгодно. Язык общего назначения должен быть безопасным. И быть ближе к автомобилю, чем к самолету - по времени обучения.

За ссылку спасибо. Действительно, забавно. Прикроют ли они при этом Химиан - вот что интересно. Все-таки корова-то дойная. А само решение - это пока только слова. Интересно будет посмотреть на дела. Если учесть, что одним из первых реальных шагов было улучшение гнома в поставке suse - говорить о том, что новел убивает это направление, рановато. Короче, как обычно, поживем-увидим. Это не изменит моего личного отношения к API на С++ и к языку, на котором безопасно программировать могут только гуру:)

> Я же упоминал про BeOS. С нуля написали систему на С++. При этом чрезвычайно легкую и быструю. Так что "не так страшен черт, как его рисуют".

Я не говорил, что большую систему нельзя написать на С++ и нужно использовать только С. Это Вы заявили, что ее необходимо разрабатывать только на С++. Разница в утверждениях очевидна?:)

> Я очень надеюсь, что когда-нибудь стандартизируют экспортируемые имена С++. > Тут ничего не поделаешь.

Угу. И двоичное представление vtbl, и организацию virtual inheritance (сама по себе вещь опасности и кривости немалой) тоже должны стандартизовать. И политику линкования при работе с темплейтами. long way to go... Прекрасно. А потом эти стандартизованные(ура!), перемангленные, километровой длины имена, мы будем использовать для создания байндингов к скриптовым языкам (которые плюсовой мовы не розумеют, зато заточены под сишные соглашения).

> Не только имена. Вы, например, знаете, как именно в памяти устроена таблица виртуальных функций и виртуальных базовых классов Вашего объекта? С точностью до байта? И она не зависит от версии и брэнда компилятора? От опций оптимизатора? Это только вопросы - вполне возможно, что на все Вы ответите "да".:)

Таблица - самый обыкновенный массив указателей. Для поддержки множественного наследования есть несколько реализаций, но в любом случае у программиста нет причин задумываться об этом. RTTI также может отличаться от компилятора к компилятору, но он уже стандартизован. К тому же программист на свое усмотрение может добавить поддержку метаобъектов (Qt), если ему это надо, но все остается под его контролем. За "байтами", выравниванием, размером объектов следит компилятор. Это нижний уровень.

>Тут же никто не спорит с Вами - да, на С ОО код длиннее. Зато интерфейсы стабильнее и предсказуемей.

Стабильность и предсказуемость обеспечивает стандарт С++98.

> Это нижний уровень.

Это ABI. Он должен быть совместимым и стандартным. И то, что у таблиц и RTTI есть несколько реализаций - убивает совместимость кода, сгенеренного разными компиляторами, по ABI нахрен.

> Стабильность и предсказуемость обеспечивает стандарт С++98

На уровне исходников. Но не на двоичном, как Вы признали выше.

>Просто и элегантно, как все на С:
(*gSomeClassInstance.parentClassInstance.virtMethod)(...);

сравнтие с:

gSomeClassInstance.virtMethod()

Но проблема не только в синтаксисе ведь. Хотя это тоже _очень_ важно.
А в том, что структура не контролирует доступ к данным. Все public. А это может привести к нарушению целостности данных, особенно сложных.

>А вообще, в gobject есть приличная система динамических вызовов по имени, так что можно методы даже по имени вызывать, через g_signal_ API.

Эти сигналы определяются программистом? А потом выборка их имен производится из массива?
И чем больше их определено, тем медленнее выборка?

> Все public. А это может привести к нарушению целостности данных, особенно сложных.

Ну, Вы уж хотите всего богатства синтаксиса С++:) Разумеется, это невозможно. Но на то, как использовать методы, вообще говоря, документация имеется:) Даже в жабке, при том, что в ней есть управление доступом, я встречал публичные методы, котороые не рекомендуется пользовать. В С++ такого не бывает?

Да, на самом деле это, конечно, будет

PARENT_CLASS(gSomeClassInstancePtr)->virtMethod(...)

> Эти сигналы определяются программистом? А потом выборка их имен производится из массива? > И чем больше их определено, тем медленнее выборка?

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

>Нет, не утопия. Каждый по-прежнему будет пользоваться тем, чем пожелает. Там речь идет о выборе слоя для взаимодействия. В данном proposal Havoc&Owen ставят проблему и приводят ее анализ, нежели дают конкретное предложение по реализации. Но чувствую я, что каждая строчка там принизана темой "это должен быть Glib" :) Все выведенные в конце свойства решения об этом говорят :)

В том-то и дело, что одним Glib дело не ограничится.
Четвертый рисунок:
XML - libxml.
GUI - ? Gtk?
DB - misc db libs

Дело в том, что в Qt все эти уровни отработаны, отлажены и хорошо работают уже сейчас. На всех платформах.

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

Понял.
С++ разрабатывался так, чтобы у программиста не было необходимости в привидениях. Страуструп даже синтаксис операторов приведения сделал ужасным, чтоб бросалось в глаза и отбивало охоту использовать. Это так, к слову.

>Писать можно и на Win API, но это великий геморрой. Вот Glib и прочится на это место в данном случае. Но для этого все должны договориться использовать Glib. То есть и Qt должны использовать именно его. А это пока нереально по политическим мотивам. Это же для многих будет шоком! Вывески новостей "Qt пошел на поклон к Glib!" ... Вот это флейма на весь интернет будет :))

Qt/Linux уже использует с десяток библиотек, так что здесь проблем не будет, думаю.
Если это облегчит библиотеку, они, может, и согласятся.

> у программиста не было необходимости в привидениях

Не мог пройти мимо. Это какому же программисту понадобились привидения? И зачем? Других программистов пугать?

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

Этого, извините, я не понял. Разве в С++ синтакс приведений не из С взят? Да, там, вроде, еще есть приведение в функциональной форме - но это только меняет расположение скобочек. Или Вы о чем-то другом7 А-а.. Вы, наверное, про какой-нибудь dyncast...

Не. Политически это неприемлемо, я думаю. Во всяком случае, пока у glib не поменяю первую букву. Да, в glib я включаю gobject - а вот подкладывание его под qt, я боюсь, потребовало бы коренных изменений в объектной модели.

Да, про "новел выбирает qt" - я пошукал по сети, это пока неформальная информация. Ждем-с официального анонса...

>А, может быть, тут D-BUS главную роль сыграет. Это хороший компромисс, так как не задевает самолюбия сторон, а предлагает унифицированный уровень, к которому пишется отдельно API для Qt, Отдельно - для Glib. Ну то есть принцип "посредника при переговорах". :)...

Я тоже думаю, что это будет самое разумное решение. Надо будет посмотреть подробнее...

> Я тоже думаю, что это будет самое разумное решение. Надо будет посмотреть подробнее...

Может, и не самое разумое (накладные расходы все-таки побольше, чем у обычных вызовов) - но, вероятно, наиболее реальное:)

Виртуальные методы и private

Нет. Не все public. В gobject реализованы private virtual и public virtual, но вот обычные невиртуальные методы - таки да - приватными не сделаешь. Возникает другой вопрос - а зачем, собственно они нужны? У нас же не какая-нибудь рантайм-система, чтобы бояться случайных обращений к функциям этой системы, которые трогать нельзя. Ведь у нас - компилируемый язык. Если ты используешь функции, которые нельзя использовать, то просто у тебя не будет правильно работать программа - вот и все. И ты это увидишь, потому что она неправильно будет работать. Кстати, помнится, в Python тоже не было private-функций когда-то. Их посчитали ненужными... Или я неправ? FIXME...

Если не сложно, напомните, как там реализованы private virtual? Что-то я не встречал. Обычные невиртуальные методы делаются private просто - они просто static в gsomeclass.c.:)

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

Разве не удобно:

string.find('a');
string.find("abc");
string.find(QRegExp("[Hh]ello"));

вместо того, чтобы помнить 3 функции?
Хорошая С++ библиотека сэкономит программисту время, которое он дополнительно потратит на изучение самого языка. Так что в сумме затраченное время может оказаться не в пользу таких библиотек, как Glib, где нужно в голове держать практически все.

Если(когда) приживется D-BUS, то этот "мусор" уже никого интересовать не будет.

Граждане, бес попутал! Читал private, а думал о protected :)... В Python не реализованы именно protected!!!! И в GObject они тоже не реализованы, так как функцию, объявленную, как static не унаследуешь.

2 svu: все правильно! private именно через static сделан. Это я просто о protected подумал :) Насчет private virtual... надо бы примерчик написать. Попозже немного накидаю.

>Очевидно, что gok не так мощен, как С++. Его задача - сократить многословность при создании gtk объектов. Эту задачу он решает, достаточно успешно. При этом - заметьте - никаких "неявностей" и "переопределений" (как в С++) не генерируется. Программист четко знает, в какое двоичное представление будет скомпилирован его код. Да, разумеется, богатство и мощь STL таким образом не получить, это точно. Но и всяких тонких багов, на которые так богат С++, тоже не схлопочешь.

И все-таки, какая информация является "входной" для gok?

Во-первых, все-таки он gob. gok - это утилятка для клавиатуры, совсем другая вещь (Zubok, круто мы лажанулись с именем?:) Вход - некий "птичий язык (а что вы ожидали от препроцессора?), заточенный под модель gobject.

Вот примерчик: http://www.5z.com/jirka/gtk-button-count.gob.html

>Да, любителям С++. Меня всегда слегка забавляло, что { A a=b; } не то же самое, что { A a; a=b; }

То же самое. Только работает быстрее. А разве к структурам в С это не относится?

То же самое? Если переопределены конструктор копирования A(B& b) и оператор присваивания =(B& b)?

>Во-первых, все-таки он gob. gok - это утилятка для клавиатуры, совсем другая вещь (Zubok, круто мы лажанулись с именем?:)

"Не мы, простите, а - вы" (с) Операция "Ы" :)... У меня все правильно написано - gob (кстати, я чуть было не бросился искать инфу про gok после твоего поста. Захотелось узнать поподробнее, но, слава Столману, не успел... :)

Ну, значит "мы":) А при чем тут Столман?8-/

> Угу. И двоичное представление vtbl, и организацию virtual inheritance (сама по себе вещь опасности и кривости немалой) тоже должны стандартизовать. И политику линкования при работе с темплейтами. long way to go... Прекрасно. А потом эти стандартизованные(ура!), перемангленные, километровой длины имена, мы будем использовать для создания байндингов к скриптовым языкам (которые плюсовой мовы не розумеют, зато заточены под сишные соглашения).

А разве имена в Gtk/Glib сейчас не такие?
this_is_name_of_function_1
this_is_name_of_function_2
...

Насчет Novell и KDE/QT:

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

И вот что интересно: какой-то КДЕ-шник запостил это на groklaw, в обсуждении вылез мужик, который на этом самом Brainshare был лично, и сказал что впечатление от того, что там говорилось, скорее противоположное.

Так что скорее всего - УТКА.

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

Вы пробовали линковать модули, откомпилированные разными С-компиляторами? Всегда получалось?
Страуструп говорит, что даже в С проблемы с ABI были.

А теперь еще вспоминаем, что в манглинге плюсовых имен присутствуют типы параметров (вот не помню про exceptions). Имена же гтк, как правило, содержат только имя класса и имя функции. Так что наши имена принципиально короче:) И, главное, на сегодня, без стандарта на плюсовый манглинг, обсуждать эту тему просто бессмысленно.

>Ну, Вы уж хотите всего богатства синтаксиса С++:) Разумеется, это невозможно. Но на то, как использовать методы, вообще говоря, документация имеется:) Даже в жабке, при том, что в ней есть управление доступом, я встречал публичные методы, котороые не рекомендуется пользовать. В С++ такого не бывает?

Не скажу за весь С++, но в Qt я не примомню такого. А по поводу чего в Java такие рекомендации?

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

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

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

Еще, насчет Novell KDE/QT

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

> Этого, извините, я не понял. Разве в С++ синтакс приведений не из С взят? Да, там, вроде, еще есть приведение в функциональной форме - но это только меняет расположение скобочек. Или Вы о чем-то другом7 А-а.. Вы, наверное, про какой-нибудь dyncast...

Да, о dynamic_cast. Но это так, к слову было.

>Не. Политически это неприемлемо, я думаю. Во всяком случае, пока у glib не поменяю первую букву. Да, в glib я включаю gobject - а вот подкладывание его под qt, я боюсь, потребовало бы коренных изменений в объектной модели.

Я думаю, идея с D-BUS действительно компромиссная. Ни вам, ни нам.

2 svu: Вставлю реплику. Ну на самом деле говорить о стабильности сишного ABI тоже надо очень осторожно. Ведь стандарт не оговаривает, как именно должны передаваться параметры в функцию, например. Вот появится завтра какой-нибудь компилятор, который, скажем передает параметры через (гы-гы) текстовый файл, а возвращать результат в регистры. Ну вот такая особенность реализации у них будет. Но соответствие стандарту языка же есть? Ведь так? Просто надо сказать, что ситуация c ABI языка Си гораздо более стабильная сейчас. Но заведомо неизвестно (во всяком случае мне), компилятор Intel C++ и gcc одинаково реализуют вызовы или нет? Гарантии, как я понимаю, никакой. Так что думаю, что "козырять" ABI здесь не совсем верно. :)

>Граждане, бес попутал! Читал private, а думал о protected :)... В Python не реализованы именно protected!!!! И в GObject они тоже не реализованы, так как функцию, объявленную, как static не унаследуешь.

Страуструп даже как-то пожалел, что в С++ protected ввел (во как!). Раньше без него обходились.
А в Java тоже protected есть?

Насколько я слышал, интеловский компилятор ведет себя прилично в смысле ABI (хотя ставить мою зарплату на это я не буду:) Да, гарантий нет - но и разнобоя я тоже не встречал очень давно. Хорошо, будем считать что стабильность Сишного ABI не целиком зависит от стандарта (хотя стабильность имен гарантирована!). По крайней мере, она существует де-факто. С++ не может похвастать даже этим - у него имена и то плавают!:)

Re:

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

С чего ради? Питон прекрасно цепляется к C++. Причем, именно к C++, а не к C. Даже, автоматом (через swig или еще как-нибудь)

> Страуструп даже как-то пожалел, что в С++ protected ввел (во как!). Раньше без него обходились.

Про это я не слыхал. Мне кажется, это уже происки пуристов:)

> А в Java тоже protected есть?

Еще как. Есть даже круче: private protected!:)

Вот, наконец нашелся человек, который смог открыть мне глаза. Я просто привык, что интерфейсы обычно чисто сишные - поэтому переспрашивал про питон. То, что к нему сделали плюсовый интерфейс - это любопытно. А где про это почитать можно? Типа - хочу я один метод питоновского объекта сделать на С++. Или один маленький объект реализовать. Как это будет выглядеть со сторны питона и со стороны плюсов?

Тогда идем дальше. Как плюсы цепляются к перлу?

>Вот примерчик: http://www.5z.com/jirka/gtk-button-count.gob.html

На С++ похоже) На выходе gob дает чистый С, а программист работает только с gob-файлами. Я правильно понял?
А Makefile как в этом случае поддерживается?
А подключение заголовочных файлов почему отсутствует?

Или я неправильно понял, а на основе этого файла генерится *.с, и программист работает дальше уже с С?

P/S Про gob сегодня вообще первый раз услышал. Поэтому для меня что gob, что gok...))

Уже сам нашел.

http://linuxgazette.net/issue49/pramode.html

Забавно. swig могуч. Интересно будет посмотреть, как они это делают...