Qt 4.4

> glib действительно не имеет отношения к плюсам. Потому что написана на C =)

> ога, а ещё на плюсах можно написать генератор лиспового кода и вызов sbcl. Ура, плюсы это лисп!

Отсюда следует, что с++ таки имеет отношение к лиспу, если на нём написать генератор лиспового кода,

> /me покосился на топик

ты чего, она же на плюсах!!! ::))

>ты чего, она же на плюсах!!! ::))

а речь о чём? Особенно в контексте extern "C" ? =)

> а речь о чём? Особенно в контексте extern "C" ? =)

Об использовании библиотеки, конечно ::))

> static GTypeInfo info = {
> sizeof (GObjectClass),
> (GBaseInitFunc) g_object_base_class_init,
> (GBaseFinalizeFunc) g_object_base_class_finalize,
> (GClassInitFunc) g_object_do_class_init,
> NULL /* class_destroy */,
> NULL /* class_data */,
> sizeof (GObject),
> 0 /* n_preallocs */,
> (GInstanceInitFunc) g_object_init,
> NULL, /* value_table */
> };

> type = g_type_register_fundamental (G_TYPE_OBJECT, g_intern_static_string ("GObject"), &info, &finfo, 0);

Теперь понятно почему С++ кодерам так "мало платят".
Спасибо, я уж как-нить на C++ полабаю.

//captcha: yoowork

>Теперь понятно почему С++ кодерам так "мало платят". 
>Спасибо, я уж как-нить на C++ полабаю. 

Ну вот С++ код ля генерирования типов. Подумай.



    namespace Private
    {
        template<class, class> 
        struct ScatterHierarchyTag;
    }

    template <class TList, template <class> class Unit>
    class GenScatterHierarchy;
     
    template <class T1, class T2, template <class> class Unit>
    class GenScatterHierarchy<Typelist<T1, T2>, Unit>
        : public GenScatterHierarchy<Private::ScatterHierarchyTag<T1, T2>, Unit>
        , public GenScatterHierarchy<T2, Unit>
    {
    public:
        typedef Typelist<T1, T2> TList;
        // Insure that LeftBase is unique and therefore reachable
        typedef GenScatterHierarchy<Private::ScatterHierarchyTag<T1, T2>, Unit> LeftBase;
        typedef GenScatterHierarchy<T2, Unit> RightBase;
        template <typename T> struct Rebind
        {
            typedef Unit<T> Result;
        };
    };
     
    // In the middle *unique* class that resolve possible ambiguity
    template <class T1, class T2, template <class> class Unit>
    class GenScatterHierarchy<Private::ScatterHierarchyTag<T1, T2>, Unit> 
        : public GenScatterHierarchy<T1, Unit>
    {
    };

    template <class AtomicType, template <class> class Unit>
    class GenScatterHierarchy : public Unit<AtomicType>
    {
        typedef Unit<AtomicType> LeftBase;
        template <typename T> struct Rebind
        {
            typedef Unit<T> Result;
        };
    };
    
    template <template <class> class Unit>
    class GenScatterHierarchy<NullType, Unit>
    {
        template <typename T> struct Rebind
        {
            typedef Unit<T> Result;
        };
    };
     
    template <class T, class H>
    typename H::template Rebind<T>::Result& Field(H& obj)
    {
        return obj;
    }
     
    template <class T, class H>
    const typename H::template Rebind<T>::Result& Field(const H& obj)
    {
        return obj;
    }
     
    template <class T>
    struct TupleUnit
    {
        T value_;
        operator T&() { return value_; }
        operator const T&() const { return value_; }
    };

    template <class TList>
    struct Tuple : public GenScatterHierarchy<TList, TupleUnit>
    {
    };

    template <class H, unsigned int i> struct FieldHelper;
    
    template <class H>
    struct FieldHelper<H, 0>
    {
        typedef typename H::TList::Head ElementType;
        typedef typename H::template Rebind<ElementType>::Result UnitType;
        
        enum
        {
            isTuple = Conversion<UnitType, TupleUnit<ElementType> >::sameType,
            isConst = TypeTraits<H>::isConst
        };

        typedef const typename H::LeftBase ConstLeftBase;
        
        typedef typename Select<isConst, ConstLeftBase, 
            typename H::LeftBase>::Result LeftBase;
            
        typedef typename Select<isTuple, ElementType, 
            UnitType>::Result UnqualifiedResultType;

        typedef typename Select<isConst, const UnqualifiedResultType,
                        UnqualifiedResultType>::Result ResultType;
            
        static ResultType& Do(H& obj)
        {
            LeftBase& leftBase = obj;
            return leftBase;
        }
    };

    template <class H, unsigned int i>
    struct FieldHelper
    {
        typedef typename TL::TypeAt<typename H::TList, i>::Result ElementType;
        typedef typename H::template Rebind<ElementType>::Result UnitType;
        
        enum
        {
            isTuple = Conversion<UnitType, TupleUnit<ElementType> >::sameType,
            isConst = TypeTraits<H>::isConst
        };

        typedef const typename H::RightBase ConstRightBase;
        
        typedef typename Select<isConst, ConstRightBase, 
            typename H::RightBase>::Result RightBase;

        typedef typename Select<isTuple, ElementType, 
            UnitType>::Result UnqualifiedResultType;

        typedef typename Select<isConst, const UnqualifiedResultType,
                        UnqualifiedResultType>::Result ResultType;
            
        static ResultType& Do(H& obj)
        {
            RightBase& rightBase = obj;
            return FieldHelper<RightBase, i - 1>::Do(rightBase);
        }
    };

    template <int i, class H>
    typename FieldHelper<H, i>::ResultType&
    Field(H& obj)
    {
        return FieldHelper<H, i>::Do(obj);
    }

А теперь то же самое на си и без glib

> А теперь то же самое на си и без glib
anonymous (*) (04.05.2008 14:08:43)

+500
Absurd, ждем аналога на C.
Желательно без нестандарнтных расширений, но в крайнем случае, - можно и с использованием glib.

>А теперь то же самое на си и без glib

Вместо быдлоблоба который породит шаблон GenScatterHierarchy можно просто сделать массив вариантов и не трахать себе мозг.

Поподробнее можно? Каким образом массив вариантов заменит механизм шаблонов? Приведи пример, пожалуйста.

Почему нет метки "C++ vs C"?

> Вместо быдлоблоба который породит шаблон GenScatterHierarchy можно просто сделать массив вариантов и не трахать себе мозг.

Ладно, упростим задачу. Приведи пример реализации аналога в си:

* Определение шаблона (в твоем понимании - "быдлоблоба"):
template< class T >
T min( T a, T b )
{
if( a < b ) return a;
else return b;
}


* Использование:
min( 1, 2 );
min( 'a', 'b' );
min( string( "abc" ), string( "cde" ) );

>Каким образом массив вариантов заменит механизм шаблонов?

Повторяю медленно: Когда из *.so можно будет экспортировать шаблоны и клиент кода сможет их инстанциировать с нужными уму типами, тогда и поговорим о механизме шаблонов. До этих пор передаем коллекции из элементов разных типов с помощью массива вариантов и никак иначе.

>* Использование: min( 1, 2 ); min( 'a', 'b' ); min( string( "abc" ), string( "cde" ) );

Бесполезный синтаксический сахар. Больше сказать нечего.

>Бесполезный синтаксический сахар.

Мда... Серьёзное заявление.

А у него на нике все написано, чего вы хотите.

> Повторяю медленно: Когда из *.so можно будет экспортировать шаблоны и клиент кода сможет их инстанциировать с нужными уму типами, тогда и поговорим о механизме шаблонов. До этих пор передаем коллекции из элементов разных типов с помощью массива вариантов и никак иначе.

_из_ *.so _экспортировать_ шаблоны? что-то я не улавливаю твой полет фантазии... ты не запутался в собственных мыслях?

>_из_ *.so _экспортировать_ шаблоны? что-то я не улавливаю твой полет фантазии... ты не запутался в собственных мыслях?

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

>>Бесполезный синтаксический сахар.

>Мда... Серьёзное заявление.

В ООП языке string и integer должны иметь виртуальную функцию наподобие boolean less(), и функция min() должна пользоваться ей. Статического решения для этой задачи не существует.

> следовательно в топку.

заявил Absurd, отстрелив себе обе ноги ::))

>В ООП языке string и integer должны иметь виртуальную функцию наподобие boolean less(), и функция min() должна пользоваться ей. Статического решения для этой задачи не существует.

хочу заметить: ты это втолковываешь людям, которые не знают, чем класс отличается от объекта и что такое виртуальные методы.

А ты им про неэкспортируемость шаблонов и обломы с их min() в случае, когда у типа в принципе нет оператора сравнения =)

не поймут-с

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

> В ООП языке string и integer должны иметь виртуальную функцию наподобие boolean less(), и функция min() должна пользоваться ей. Статического решения для этой задачи не существует.

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

// captcha: sexher

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

> Т.е шаблоны не имеют динамической инстанциации и ABI -> следовательно в топку.

Так в C++ с пометкой "мета" вообще ничего динамического нет, всё compile-time only.

>Ты не поверишь. В приведенном шаблоне есть только одно требование к используемому типу данных: наличие определения для оператора <

Ты не поверишь. Absurd именно это и сказал =)

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

Мдя... Они хочут показаться умными и вечно говорят о непонятном...

> Т.е шаблоны не имеют динамической инстанциации и ABI -> следовательно в топку.

А позвольте уточнить, что в Вашем понимании есть "динамическая инстанциация" и "ABI" шаблонов?

// captcha: higther

>А позвольте уточнить, что в Вашем понимании есть "динамическая инстанциация" и "ABI" шаблонов?

что мешает тебе сходить в гугль? Нежелание учиться?

>>Ты не поверишь. В приведенном шаблоне есть только одно требование к используемому типу данных: наличие определения для оператора <
>Ты не поверишь. Absurd именно это и сказал =)

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

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

Если я ошибаюсь - не сочти за труд - кинь в меня ссылку. Если не отыщешь - поясни своими словами. Я тебя очень сильно прошу.

> А позвольте уточнить, что в Вашем понимании есть "динамическая инстанциация" и "ABI" шаблонов?

По всей видимости, под отсутствием динамической инстанциации он имел в виду то, что шаблонизированный класс нельзя специализировать в рантайме. Под отсутствием ABI, вероятно, подразумевается, что нельзя просто взять и подгрузить so/dll, написанную на плюсах с применением шаблонов, и начать без заморочек использовать её (собственно, шаблоны тут не при чём, т.к. с обычным классом без знания его прототипа тоже нельзя работать). Всё это можно выразить короче: в С++ нет метаобъектного протокола.

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

наверное, он имел ввиду, что шаблонами в данном примере решается задача, которая уже решена перегрузкой операторов. И можно обойтись простым ('a'<'b' ? 'a' : 'b') вместо min('a','b'). Или макрос забабахать =)

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

Если с правильного конца взять тот же m4 или bison - можно ещё круче наворотить. Только вот к языку это будет иметь такое же отношение, как и родные (казалось бы) шаблоны c++. Т.е. "синтаксический сахар". Полезный или бесполезный - это уже другой вопрос. Для упрощения печатания кода - наверное полезный. Для понимания "как оно работает" - скорее вредный =)

s/(m4|bison)/lisp/ ? :)

Кстати говоря, Vala именно так и сделана. Из нечто шарпообразного сишный код генерится, сам язык на лексе написан.

>s/(m4|bison)/lisp/ ? :)

"если Вы пишете большой проект - рано или поздно Вы обнаружите, что переизобретаете lisp" (c) =)

>Кстати говоря, Vala именно так и сделана. Из нечто шарпообразного сишный код генерится, сам язык на лексе написан.

Vala и есть мешок "синтаксического сахара" =)

> Vala и есть мешок "синтаксического сахара" =)

Разве это плохо? :)

>Разве это плохо? :)

зависит от точки зрения. Человек который знает только Vala, не зная кишок Glib/GObject будет писать менее эффективный код. Другое дело, что для многих приложений этого хватит

По-моему, в качестве general purpose языка для Gnome это неплохая альтернатива C++, Python'у и Mono.

Вот, кстати, библиотеку коллекций на vala уже наваяли (libgee). Можно использовать со всем, что gobject умеет.

> наверное, он имел ввиду, что шаблонами в данном примере решается задача, которая уже решена перегрузкой операторов. И можно обойтись простым ('a'<'b' ? 'a' : 'b') вместо min('a','b'). Или макрос забабахать =)

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

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

Как я уже выше отписал мне представляется проблематичным замена шаблонов классов другими средствами.

Я правильно понял, что "инстанциацию и ABI шаблонов" следует трактовать как поддержку механизмов плагинов и сериализации/десериализации?

Механизмы поддержки плагинов в C++ давно реализованы. Тоже самое - относительно сериализации данных, есть даже вроде бы успешные реализации сериализации объектов. Если в приложении на C++ есть поддержка плагинов, плагин подготовлен и доступен для приложения - в чем проблема? В чем сакральный смысл "загрузки плагина и доступа к хранимому в нем (?!) шаблону"?

> Если с правильного конца взять тот же m4 или bison - можно ещё круче наворотить. Только вот к языку это будет иметь такое же отношение, как и родные (казалось бы) шаблоны c++. Т.е. "синтаксический сахар". Полезный или бесполезный - это уже другой вопрос. Для упрощения печатания кода - наверное полезный. Для понимания "как оно работает" - скорее вредный =)

Родной (безо всяких "казалось бы") механизм шаблонов помогает писать более правильный, краткий и понятный (!) код, но как уже неоднократно и справедливо было замечено - это не run-time фича. И мне непонятны аргументы типа "Это не run-time? Фтопку!". О людях, мыслящих в пределах собственных ментальных моделей, у меня крайне низкое мнение.

> Тоже самое - относительно сериализации данных, есть даже вроде бы успешные реализации сериализации объектов.

URL на описание сериализации в C++ (в языке, не в библиотеке, безо всяких костылей типа DECLARE_METHOD/DECLARE_ATTRIBUTE или встравивания методов Serialize)

>Шаблонизацию классов (пример чего кидал Absurd), я так понимаю, макросами будет сложнее реализовать? :)

ессно, сложнее

>Как я уже выше отписал мне представляется проблематичным замена шаблонов классов другими средствами.

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

=)

>Я правильно понял, что "инстанциацию и ABI шаблонов" следует трактовать как поддержку механизмов плагинов и сериализации/десериализации?

неправильно. Хотя отсутствие интроспекции в плюсах - это тоже ограниченность.

>Механизмы поддержки плагинов в C++ давно реализованы.

>Родной (безо всяких "казалось бы") механизм шаблонов

да не родной он. Так же как #define и #include не являются родными для С. Это _надстройка_ со своим синтаксисом и ограниченным временем жизни (на стадии компиляции). Мощи языку шаблоны не прибавляют.

>помогает писать более правильный, краткий и понятный (!) код

спорно. Краткий может быть. Но понятный ли?

>И мне непонятны аргументы типа "Это не run-time? Фтопку!"

Велосипеды для трансконтинентальных перелётов не годятся - фтопку их :)

>О людях, мыслящих в пределах собственных ментальных моделей, у меня крайне низкое мнение.

гм-гм. Пойми одну простую вещь - ты не можешь оценить плюсы адекватно, пока ты не знаешь других языков. Где вещи, которые в плюсы запихивают долго, мучительно, со скрипом и коверкая по дороге - есть изначально. А объяснить тебе, что именно не так в плюсах можно только если ты узнаешь эти другие языки. Замкнутый круг =) Если тебе это не надо - да пожалуйста. Если тебе плюсы удобны - да пожалуйста опять-таки. Нравится тебе считать этот неудачный в общем-то язык серебрянной пулей - считай. Только никому не говори :)

"Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе"

:)

>Вот, кстати, библиотеку коллекций на vala уже наваяли (libgee). Можно использовать со всем, что gobject умеет.

в gtk maillist пробегало предложение gtk на Vala переписать

<_<

>_>

я этого не говорил :)

> И мне непонятны аргументы типа "Это не run-time? Фтопку!". О людях, мыслящих в пределах собственных ментальных моделей, у меня крайне низкое мнение.

Если речь заходит о нормальном метапрограммировании, то без некоторых возможностей в рантайме приходится менять подход к разработке софта, т.е. изобретать костыли, что мы и видем в вагоне библиотек, которые типа делают маршаллинг/демаршаллинг, рантаймное связывание сигналов с обработчиками и т.п. Многим не нравится засорять код подпорками.

> URL на описание сериализации в C++ (в языке, не в библиотеке

Нормальная сериализация всегда делается библиотекой на основании предоставляемых реализацией языка метаданных. Эти метаданные могут быть стандартизированы (наверное, это случая Явы и Лиспа), а могут быть нестандартизированными (как DWARF2 в Си++). Дать тебе URL на DWARF2? 8)

> в gtk maillist пробегало предложение gtk на Vala переписать

Погода назад синтаксис в Vala шатало, как пьяную корову, плюс страшные глюки в парсере находились. Рано ещё :)

> Нормальная сериализация всегда делается библиотекой на основании предоставляемых реализацией языка метаданных.

А что ты понимаешь под "нормальной сериализацией", и почему она должна быть сделана в библиотеке? В CLOS по метаданным можно ходить средставми самого CLOS. Для неCLOS части CL стандартного подхода получить метаданые нет, поэтому есть библиотеки типа cl-walker.

>Дать тебе URL на DWARF2?

дай мне пример использования. С той же Qt

> а могут быть нестандартизированными (как DWARF2 в Си++)

Ну нестандартизованно люди и мультиметоды к плюсам прикручивают, толку-то? :)

> А что ты понимаешь под "нормальной сериализацией"

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

> и почему она должна быть сделана в библиотеке?

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

>> а могут быть нестандартизированными (как DWARF2 в Си++)

> Ну нестандартизованно люди и мультиметоды к плюсам прикручивают, толку-то? :)

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