Не пойму оператор ","(запятая)

[EUGY]

В конечном итоге я конечно сделал так:

typedef void* RTTI;
tempate <class T> RTTI _stamp()
{
    static char r;
    return &r;
}

Но альтернативой рассматривал вариант со статиком в хидере.
Так что, как бы, ничего криминального...

[_Bers]

Сообщение от EUGY

В конечном итоге я конечно сделал так:

typedef void* RTTI;
tempate <class T> RTTI _stamp()
{
    static char r;
    return &r;
}

Но альтернативой рассматривал вариант со статиком в хидере.
Так что, как бы, ничего криминального...

Эм... а как следует использовать данную конструкцию?

[EUGY]

В одной из работ мне нужно было создать иерархию классов имеющих в основе один базовый, и при этом осуществить как down-cast, так и up-cast между ними.
Оператор dynamic_cast в этом случае не помогал.
Ну, а _stamp просто одна из впомогательных функций, выдающая уникальный номер для класса в параметре шаблона.

[_Bers]

Идею не вполне угадываю. Наверное, потому что не вижу всю картинку в "целом"
А так вообще, для динамической идентификации типов (а так же для статической проверки "особенностей" типа), лично я использую объекты-мемберы безымянных статических структур.

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

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

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

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

[EUGY]

Я видел посты где Вы описывали это. Интересно.
У меня была довольно геморная задача. Воду лить не стану, но пришлось писать "с-нуля" весь кастинг иерархии и освобождение от циклических ссылок с обходом периметра.
При этом объекты должны иметь только публичные интерфейсные методы или публичные поля в виде других объектов и поддерживать бейсикоподобный синтаксис типа:

	
	win W = New;  //class win : public object
	frm F = New;  // class frm : public win
	win Z = F;    // Good Casting
	frm X = W;    // Error: Bad Casting
	frm Y = Z;    // Good Casting
	Y.parent = W; // parent  is class win
	W = NULL;