Erste Stelle:

typedef char(&yes_t)[1];
typedef char(&no_t)[2];

yes_t is_policy_cons_test(const null_type&);
template<class H, class T>
yes_t is_policy_cons_test(const policy_cons<H,T>&);
no_t is_policy_cons_test(...);

template<class T>
struct is_policy_cons
{
	static const T& t;
	BOOST_STATIC_CONSTANT(bool, value = sizeof(is_policy_cons_test(t)) == sizeof(yes_t));

	typedef boost::mpl::bool_<value> type;
};

Kann man das nicht eigentlich auch mit einer einfachen Spezialisierung regeln? Ich nehme mal an nicht und da frage ich euch, welche zusätzlichen Fälle bedient dieses komische Konstrukt?

yes_t is_policy_cons_test(const policy_cons<H,T>&);

?
Dann wi5rd sie genommen.
Falls nicht, wird die

no_t is_policy_cons_test(...);

genommen.

Und der Trick ist nur, den Rückgabetyp anzuschauen.
Hab ich ein Objekt t, dann ist

sizeof(is_policy_cons_test(t))

je nach dem 1 oder 2.

welche zusätzlichen Fälle bedient dieses komische Konstrukt?

Ähm, es gibt die Anzwort als Compilezeit-Konstante. Zu verwenden für static_assert oder als Template-Parameter für weitere Template-Rechnungen. Oder zum sicheren Wegoptimieren von Fallunterscheidungen.

template<class T>
struct is_policy_cons
{
    static const bool value = false;
};

template< typename H, typename T >
struct is_policy_cons< policy_cons<H,T> >
{
  static const bool value = true;
};

template< >
struct is_policy_cons< null_type >
{
  static const bool value = true;
};

Edit: Das wäre jetzt die Variante, die ich erstmal intuitiv zur Lösung des Problems gewählt hätte, aber die muss ja offenbar der Variante da oben unterlegen sein.
Edit #2: Oh, die Variante da oben catched auch alle abgelittenen Klassen und mein Template so erstmal nicht, oder?

Okay: Diesen Trick klassifiziere ich unter "Matche den speziellen Template-Typ und alle abgelittenen Typen. Fällt mir auch erstmal keine elegante andere Lösung ein. (Wobei man aber sagen muss, dass diese Lösung hässlich ist und eine schwäche des Template-Systems darstellt, hehe)

template< typename D, template<typename,typename> class B, typename B1, typename B2 >
// B ist also ein unspezialisiertes Template mit 2 Parametern
struct is_template_base_of< D, B<B1,B2> >
{
};

template< typename T >
struct is_policy_cons3 : public is_template_base_of< T, policy_cons >
{
};

Gibt es denn eigentlich irgendeinen Grund, aus dem man folgendes Konstrukt nicht erlaubt hat?

Jo, is sogar ziemlich simpel: Es macht keinen Sinn. Oder nach welchem Verfahren soll der Compiler B1 und B2 erraten?

[...] ich meinte vor allem, was ist der Unterschied zu folgendem:
[...]

Es tut etwas völlig anderes?

Decimad schrieb:

Edit #2: Oh, die Variante da oben catched auch alle abgelittenen Klassen und mein Template so erstmal nicht, oder?

Genau das ist der Sinn, ja...

Decimad schrieb:

Dieser Funktionstrick ist irgendwie so hässlich, da muss es doch was von Ratiopharm geben.

Was findest du daran denn so hässlich, ich find den eigentlich vergleichsweise elegant!?

Kannst ja auch mal einen Blick auf std::is_base_of werfen...

Und hässlich daran ist folgendes: Das Templete-System ist "zu schwach" und dann fängt man an, hinter der Template-Fassade freie Template-Funktionen zu deklarieren um auf das Überladungs-System auszuweichen zum Zwecke der statischen Typanalyse.

Da steht natürlich noch die Frage im Raum, wozu dieser spezielle Check dienen soll, und ob man mit ihm nicht versucht, die leider noch fehlenden Concepts zu simulieren...

Na aber is_base_of kann auch nicht mit unspezialisierten Template-Klassen umgehen.

Du meinst Klassentemplates? Wie genau sollte das auch funktionieren, ein Template ist keine Klasse (sondern eben ein Template), da von einer Basisklasse zu sprechen, macht also gar keinen Sinn!?

Davon zu sprechen, dass die Spezialisierung eines Klassentemplates Basis einer anderen Klasse ist, ergibt in meiner Logik irgendwie Sinn.

Dafür ist es aber auch eine der coolsten Bibliotheken (aus Anwendersicht), mit denen ich je gearbeitet hab.

Davon zu sprechen, dass die Spezialisierung eines Klassentemplates Basis einer anderen Klasse ist, ergibt in meiner Logik irgendwie Sinn.

Meinst du mit "Spezialisierung eines Klassentemplate" eine Instanz desselben?

Edit: Mit Ja. meinte ich eine beliebige Instanz desselben, nicht eine bestimmte.

Dort liegt das Problem. Das Konstrukt, dass ich in meinem OP aus den luabind-Quellen kopiert habe, löst genau das Problem.
Edit: Und es löst das Problem auf eine Art und Weise, die nicht generalisierbar ist. Für jedes Klassentemplate muss man einen neuen Satz von Funktionen definieren.

Also: Was genau ist deine Frage?

Im Gegensatz zu der von dir vorgeschlagenen Syntax, überprüft der Code aus dem OP, ob eine Klasse von einer konkreten Instanz eines konkreten Template abgeleitet ist.

Nein. Es prüft ob die Klasse von einer beliebigen instanz abgeleitet ist. Der Compiler ist nur smart genug zu bestimmen, welche möglicheen instanzparameter dafür in betracht kommen.

Semantisch ist das Ding: "ist X von einem Foo<T> mit beliebigem T abgeleitet"?
Und Decimad hängt sich zurecht daran auf, dass der Ansatz nicht auf beliebige Foo generalisierbar ohne für jedes Foo einen konkreten Satz an Funktionen/Klassen zu verwenden. Und ja, das ist Schade und eine Schwäche des Typsystems, denn ich verwende "is_base_of" fast nie, im Gegensatz zu einem "is_derived_from_some_arbitraryFooT"

//edit um Konstruktiv zu sein Keine Ahnung ob das compiliert, müsste aber gehen:

template<class T, class template<class> Foo>
struct is_derived_from_unary_arg_template_base
{
    template<class H>
    yes_t test(const Foo<H>&);
    no_t test(...);

    static const T& t;
    BOOST_STATIC_CONSTANT(bool, value = sizeof(test(t)) == sizeof(yes_t));

    typedef boost::mpl::bool_<value> type;
};

template<class H>
class Foo{};

class Bar:public Foo<int>{};

is_derived_from_unary_arg_template_base<Bar, Foo>::value

interessant wirds dann aber herauszufinden, welches Foo<H> es genau ist...

Ich probiere das mal aus. Sieht auf den ersten Blick auf jeden Fall so aus, dass man besser versteht, was das ganze eigentlich machen soll!