Здравствуйте, alexeiz, Вы писали:

A>В данном случае C++ аналогом будет не define, а шаблонная функция. Проще и
A>понятнее, чем mixin.

В данном случае да.

Но вот из реальной жизни пример, имплементация intrusive list

//|
//| tree_element - mixin template - implemetation
//| of tree node
//|
template tree_element(NODE) 
{
    NODE _parent;
    NODE _next;
    NODE _prev;
    NODE _firstchild;

    void tree_element_initialize() { _next = _prev = this; }
}

//|
//| access methods/properties likely to be public
//| 
template tree_element_methods(NODE) 
{
    bool detached() { return (_parent is null); }
    bool attached() { return !(_parent is null); }

    // sibling ops
    NODE nextSibling()  { return (_parent is null)? null: (this is _parent.lastChild()? null: _next); }
    NODE prevSibling()  { return (_parent is null)? null: (this is _parent.firstChild()? null: _prev); }
    NODE firstSibling() { return _parent is null? null: _parent.firstChild(); }
    NODE lastSibling()  { return _parent is null? null: _parent.lastChild(); }

    ....
 
}

// class - tree node

class MyTreeNode {

  private:
     mixin tree_element!(MyTreeNode); 

  public:
     this() { tree_element_initialize(); }

     mixin tree_element_methods!(MyTreeNode); // standard tree methods

     ....
}

"c-smile" <13953@users.rsdn.ru> wrote in message
news:1159339@news.rsdn.ru
> Здравствуйте, alexeiz, Вы писали:
>
>> В данном случае C++ аналогом будет не define, а шаблонная функция.
>> Проще и понятнее, чем mixin.
>
> В данном случае да.
>
> Но вот из реальной жизни пример, имплементация intrusive list

На C++ такое тоже можно. Curiously recurring template называется. Опять не #define, но, может быть, не так чисто, как в D.

Здравствуйте, uw, Вы писали:

uw, а не могли бы Вы послать мне
письмо на news@terrainformatica.com ?
Это по поводу thor...

Здравствуйте, alexeiz, Вы писали:

A>"c-smile" <13953@users.rsdn.ru> wrote in message
A>news:1159339@news.rsdn.ru
>> Здравствуйте, alexeiz, Вы писали:
>>
>>> В данном случае C++ аналогом будет не define, а шаблонная функция.
>>> Проще и понятнее, чем mixin.
>>
>> В данном случае да.
>>
>> Но вот из реальной жизни пример, имплементация intrusive list

A>На C++ такое тоже можно. Curiously recurring template называется. Опять не #define, но, может быть, не так чисто, как в D.

А причем здесь curiously recurring templates скажи на милость?
В моем примере mixin использованы именно как defines только правильные

Кстати D тоже поддерживает curiously recurring templates
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

and the D Programming Language implementation of it:

class ArithmeticType(T)
{
    T opAdd(T other)
    {
        T result = new T(this);
        result += other;
        return result;
    }
}

class Quaternion: ArithmeticType!(Quaternion)
{
    this() { }
    this(ArithmeticType!(Quaternion) t) { }

    Quaternion opAddAssign(Quaternion other)
    {
         // etc.
    }
}

So now there are two languages that can do the CRTP <g>. (Walter)

"c-smile" <13953@users.rsdn.ru> wrote in message
> Здравствуйте, alexeiz, Вы писали:
>
>> "c-smile" <13953@users.rsdn.ru> wrote in message

>>> Но вот из реальной жизни пример, имплементация intrusive list
>
>> На C++ такое тоже можно. Curiously recurring template называется.
>> Опять не #define, но, может быть, не так чисто, как в D.
>
> А причем здесь curiously recurring templates скажи на милость?

Таким образом mixins эмулируются на C++. Вот, примерно так я бы реализовал это с помощью curiously recurring templates:

template <typename NODE>
struct tree_element
{
    NODE * parent_;
    NODE * next_;
    NODE * prev_;
    NODE * firstchild_;

    tree_element()
    {
        next_ = prev_ = static_cast<NODE *>(this);
    }
};

template <typename NODE>
struct tree_element_methods
{
private:
    NODE * derived()
    {
        return static_cast<NODE *>(this);
    }

public:
    bool detached() { return derived()->parent_ == NULL; }
    bool attached() { return !detached(); }

    // sibling ops
    NODE * nextSibling() 
    {
        NODE * d = derived();
        return d ? NULL : (d == d->parent_->lastChild() ? NULL : d->next_);
    }
};

class MyTreeNode
    : private tree_element<MyTreeNode>
    , public tree_element_methods<MyTreeNode>
{
public:
    MyTreeNode() {}
};

> В моем примере mixin использованы именно как defines только
> правильные

Я же хотел сказать, что если есть возможность сделать что-либо без использования #define, то так и нужно поступать.

Тут нужен посложнее пример, типа message crackers из MFC, чтобы показать приемущество прямой поддержки mixin'ов в языке. Хотя, в принципе, и message crackers тоже совсем даже неплохо реализуются без define'ов.

>
> Кстати D тоже поддерживает curiously recurring templates


Woo-hoo! Way to go D!

Полезна для быстрого ознакомления: что есть D как язык.

http://uvsc.freshsources.com/D.ppt

CS>В настоящее время готовлю к выпуску
CS>Harmonia GUI framework for D.
CS>screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
CS>Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
CS>Собственно D здесь: http://www.digitalmars.com/d/

Андрей, а почему ты придерживаешься HTML в GUI?

Здравствуйте, Кодёнок, Вы писали:

CS>>В настоящее время готовлю к выпуску
CS>>Harmonia GUI framework for D.
CS>>screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
CS>>Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
CS>>Собственно D здесь: http://www.digitalmars.com/d/

Кё>Андрей, а почему ты придерживаешься HTML в GUI?

Хороший вопрос. Но непонятно как на него отвечать.

Прежде всего зачем язык разметки в GUI?:
HTML выполняет три базовых функции: 1) layout manager
( в Harmonia нет layout managers в чистом виде вообще кроме HTML )
и 2) renderer всякой текстовой информации и оформления и
3) удобное средсво локализации

смотри имеем две версии:

<P>Please input amount of money: <INPUT id=amount /> and select currency <INPUT type=select /></P>

и

<P>Пожалуйста введите сумму денюжек: <INPUT id=amount /> и выберите тип валюты <INPUT type=select /></P>

Понятно что форма/диалог настраиваемая таким образом в разы лучше чем то что нам предлагает resource editor.

Почему именно HTML?

1) Зачем изобретать велосипед (XAML/XUL) когда уже все (почти) есть ? (XAML/XUL это нечто более чем просто разметка, но это мы опускаем пока)
2) Short learning curve.
3) Набор готовых средств для его создания.
4) Прверенность временем и много еще всякого.

В Harmonia HTML это скорее XHTML так как допускает только well-formed XML.
И еще одно "но" и принципиальное весьма — Проценты.
Проценты здесь это "проценты от свободного места" т.е. скажем нам надо
чтобы фраза

<P>Please input amount of money: <INPUT id=amount width=70% /> and select currency <INPUT type=select width=30%/></P>

занимала всю строку и размеры input устанавливались исходя из соотношения 7/3 — так и пишем (width attribute).
В живую как это "пружинится" можно посмотерть в Demo (закладка Basic Control Test — первые два edit box)

То же справедливо и для вертикальных контейнеров типа DIV.

Ну и потом HTML позволяет хорошо и естесвенно разделить оформительскую часть
от собсвенно логики UI.

Вот примерно так.

Да, еще...я не стал нагружать HTML функциями обработки событий как в XUL/XAML потому как
так считаю эти функции больше кода приложения чем деклараций. В коде оброботку событий
и логику *всегда* делать удобнее и эффективнее.
Но ничего не мешает приделать к Harmonia тот же DMDScript или LUA если задача того требует...

Кё>>Андрей, а почему ты придерживаешься HTML в GUI?

CS>Хороший вопрос. Но непонятно как на него отвечать.

CS>1) Зачем изобретать велосипед (XAML/XUL) когда уже все (почти) есть ? (XAML/XUL это нечто более чем просто разметка, но это мы опускаем пока)
CS>2) Short learning curve.
CS>3) Набор готовых средств для его создания.
CS>4) Прверенность временем и много еще всякого.

Собственно, я про XML-разметку с поддержкой behavior не через стили, а путём биндинга к определённому XML-тэгу. Всё-таки, поведение — это не стиль оформления.

<!-- вместо -->
<input style="behaviour:trackbar" id="trackerA" />
<input style="behaviour:trackbar" id="trackerB" />

<!-- это -->
<trackbar id="trackerA" />

<!-- вместо -->
<P> <input/> <BR/> <input/> <BR/> </P>

<!-- это -->
<vbox> <input/> <input/> </vbox>

Здравствуйте, Кодёнок, Вы писали:

Кё>Собственно, я про XML-разметку с поддержкой behavior не через стили, а путём биндинга к определённому XML-тэгу. Всё-таки, поведение — это не стиль оформления.

Кё>

Кё><!-- вместо -->
Кё><input style="behaviour:trackbar" id="trackerA" />
Кё><input style="behaviour:trackbar" id="trackerB" />

Кё><!-- это -->
Кё><trackbar id="trackerA" />
Кё>

Кё>

Кё><!-- вместо -->
Кё><P> <input/> <BR/> <input/> <BR/> </P>

Кё><!-- это -->
Кё><vbox> <input/> <input/> </vbox>
Кё>

Я не понял в общем и целом что ты имеешь ввиду.
"Всё-таки, поведение — это не стиль оформления." это да, я тоже так считаю.

К слову: в Harmonia <input/> это и inline и block элемент.
Внутри <p> это inline, а если так:
<div> <input/> <input/> </div>
то блочный — растягивается на ширину контейнера и
div их укладывает один под другим.

Здравствуйте, c-smile, Вы писали:

CS>1) Зачем изобретать велосипед (XAML/XUL) когда уже все (почти) есть ? (XAML/XUL это нечто более чем просто разметка, но это мы опускаем пока)

Интересная статья в продолжение этого тезиса: Will AJAX help Google clean up?

Start-ups and industry giants such as Microsoft continue to devise newfangled systems for delivering desktop-like applications over the Web. But search giant Google has taken a different path, using older technology to build its newest applications such as Google Maps and Gmail.

That's prompted developers to take a second look at old-hat technologies that have been kicking around on the Web since the 1990s, such as JavaScript and Dynamic HTML.

[...]

The interest isn't driven by some dot-com nostalgia. Proponents argue that these older technologies are good enough to do the job and that support for them is already embedded in common Web browsers.
...

Здравствуйте, c-smile, Вы писали:

CS>Мысли (спорадические) по поводу D.

CS>В настоящее время готовлю к выпуску
CS>Harmonia GUI framework for D.
CS>screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
CS>Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
CS>Собственно D здесь: http://www.digitalmars.com/d/

CS>Т.е. определенный опыт приобрел. С чего бы начать? С классификации пожалуй.

Можно пару практических вопросов, есть ли средства для автоматической или полуавтоматической интеграции с com, то есть на входе com объект на выходе модуль для D? Или хотя бы утилита для перевода сишных заголовков в D модули? Все это к тому что например хотелось бы пользоватся DitrctX9 из D.
Кроме того интересует сериализация, насколько это проще или сложнее сделать чем на плюсах.

Здравствуйте, c-smile, Вы писали:

skip...

Вас тут начитаешься, действительно на D перейдешь, я вот уже скачал примочки к нему...
Вообщем D — это то, что я хотел... (а именно GarbageCollector + возможность саомму управлять памятью)