ich habe in meinem Programm eine polymorphe Hierarchie, wobei ich meist nur Basisklassenzeiger speichere. Was ich nun haben möchte, ist, dass ich deep Copies von beliebigen Instanzen machen kann, nur anhand ihres Basisklassenzeigers. Die kanonische Lösung, einfach einen smart Pointer zurückzugeben, ist nicht zufriedenstellend, weil ich unterschiedliche Allokatoren verwenden möchte. Die kommenden, polymorphen Allokatoren entschärfen dieses Problem weitgehend, aber auf Kosten von zusätzlicher Komplexität.
Da wir C++-Leute künstliche Einschränkungen (Java) ablehnen, verstehe ich nicht, wieso virtuelle Template-Methoden, die dieses und alle anderen Probleme dieser Gattung elegant lösten, nicht bereits Teil des Standards sind. Eine Lösung die mir vorschwebt, sähe in Etwa so aus:

struct foo
{
	template< typename allocator_t >
	virtual std::unique_ptr< foo, wrapper< allocator_t > > clone( allocator_t&& allocator ) const
	{
		// alloziert Speicher für foo
	}	
	template< typename allocator_t >
	std::unique_ptr< foo, allocator_t > clone() const
	{
		return clone< allocator_t >( {} );
	}
};
struct bar : foo
{
	template< typename allocator_t >
	virtual std::unique_ptr< foo, wrapper< allocator_t > > clone( allocator_t&& allocator ) const override
	{
		// alloziert Speicher für bar
	}
};

Und wenn ich nun foo{}->clone< logging_alloc_t >(); und bar{}->clone< pool_alloc_t >(); aufrufe, dann würde der Compiler zwei virtuelle Funktionen / Funktionszeiger in der Basisklasse generieren, eine mit der Signatur ( foo::* )( logging_alloc_t&& ) const und die andere ( foo::* )( pool_alloc_t&& ) const . Das Template wäre dann nur dazu da, virtuelle Funktionen automatisch zu definieren.

Genereller betrachtet beläuft sich das Problem darauf, dass man im Moment gezwungen ist, Interfaces zu schreiben, wenn man Laufzeitpolymorphie und Template-Code mischt. Ein weiteres Beispiel:

struct foo
{
	template< typename char_t, typename traits_t >
	virtual std::basic_ostream< char_t, traits_t >& print( std::basic_ostream< char_t, traits_t >& destination ) const
	{
		// ...
	}
};
struct bar : foo
{
	template< typename char_t, typename traits_t >
	virtual std::basic_ostream< char_t, traits_t >& print( std::basic_ostream< char_t, traits_t >& destination ) const override
	{
		// ...
	}
};

Statt für jedes unterstütztes Encoding manuell eine weitere virtuelle Methode zu schreiben, würde diese Variante zur Compilezeit die passenden virtuellen Methoden generieren, abhängig davon, wie print im Code tatsächlich instantiiert wird. Die Alternative hierzu ist ein weiteres Interface zu schreiben, das vom statischen Typensystem unabhängig ist. Für dieses Problem insbesondere existiert glücklicherweise bereits eine Lösung: std::u32string , der dann von der Funktion zurückgegeben würde. Der zusätzliche Adapter, dieses Typensystem-unabhängige Interface, den std::u32string , dann letztendlich in die Zielcodierung zu konvertieren, ist minimal. Aber auch diese Lösung birgt Probleme: die gesamte Ausgabe in einem zusammenhängenden (contiguous) Speichersegment zwischenzuspeichern, und dann noch in UTF-32, ist, insbesondere bei größeren Ausgaben, inakzeptabel.

Das ist dann erst die Spitze des Eisbergs, denn für viele andere Probleme existiert kein so komfortables, vorgefertigtes Interface, wie im folgendem Falle:
Es existiert ein Vektor von std::unique_ptr< filter_base > . Es gibt verschiedene Klassen, die von filter_base abgeleitet sind, aber sie haben alle gemeinsam, dass sie auf Matrizen (hier: 2D-Pixelmatrizen, resp. Bilder) anwendbar sind. Nun möchte ich während der Laufzeit meine Bildmatrix von 24-bit RGB zu floating point RGB ändern. Wie ist es nun möglich, dass der Vektor an Filtern ungeändert bleibt, die einzelnen Filter aber dennoch auf die neue Bildmatrix mit einem anderen statischen Dateityp angewandt werden können? Dazu müsste ich also manuell eine neue virtuelle Methode in filter_base einführen:

struct filter_base
{
	virtual ~filter_base() = default;

	virtual void apply( matrix_24bit_rgb& ) const = 0;
	virtual void apply( matrix_flt_rgb& ) const = 0;
};
struct darken : filter_base
{
	virtual void apply( matrix_24bit_rgb& mat ) const
	{
		for( auto& i : mat )
			i /= 2;
	}
	virtual void apply( matrix_flt_rgb& mat ) const
	{
		for( auto& i : mat )
			i /= 2;
	}
};

Für jeden weiteren Matrizentyp, den ich mit den Filtern unterstützen will, muss ich sowohl in der Basisklasse, als auch in jeder einzelnen abgeleiteten Klasse manuell eine weitere Überladung einfügen, auch wenn die Implementierungen identisch sind. Diese Variante hat den weiteren Nachteil, dass in jedem Fall ein vtable-Eintrag erstellt wird, unabhängig davon, ob eine bestimmte Überladung dann im finalen Programm tatsächlich verwendet wird. Dies wäre nicht der Fall mit Templates, die wirklich nur dann instantiiert werden, wenn sie gebraucht werden.

Mir ist bewusst, das dieses Sprachwerkzeug unweigerlich auch Risiken mit sich bringt. Beispielsweise würden die Leute früher oder später definitiv dazu verleitet, Iteratoren oder Ranges mittels dieses Mechanismus zu übergeben, was dazu führt, dass die vtable komplett zugemüllt wird. Meine Vorstellung beläuft sich darauf, dieses Sprachmittel nur einzusetzen, wenn weniger als ca. ein Dutzend Instantiierungen zu erwarten sind: 1 von ~5 Encodings, 1 von ~10 arithmetischen Typen, 1 von ~10 Containern, 1 von ~5 Layouts etc.

Zur Implementierung: Ich bin mir auch über die Implikation im Klaren, dass die Größe einer Klasse davon abhängt, wie ihre Methoden (und die, der abgeleiteten Klassen) instantiiert werden, wobei ich auf die Schnelle kein Problem damit sehe.

Wieso gibt es das nicht bereits? Und wie soll man das Problem mit filter_base zufriedenstellend lösen, ohne dass besagtes Sprachmittel zur Verfügung steht?

Da wir C++-Leute künstliche Einschränkungen (Java) ablehnen, verstehe ich nicht, wieso virtuelle Template-Methoden, die dieses und alle anderen Probleme dieser Gattung elegant lösten, nicht bereits Teil des Standards sind.

Die vtable der Klasse, die das Template enthält, muss sich je nach den Instantiierungen des Membertemplates anpassen: In zwei Übersetzungseinheiten kann eine übereinstimmend definierte Klasse unterschiedliche vtables haben. Das ist einfach total inkompatibel mit der ODR.

Ich habe das vage Gefühl, dass du die Idee von "Klassentemplates mit virtuellen Funktionen" mit "Klassen mit virtuellen Funktionstemplates" vermischst; ersteres macht Sinn und ist auch wohlgeformt.

Für jeden weiteren Matrizentyp, den ich mit den Filtern unterstützen will, muss ich sowohl in der Basisklasse, als auch in jeder einzelnen abgeleiteten Klasse manuell eine weitere Überladung einfügen, auch wenn die Implementierungen identisch sind.

Na hier liegt doch dein Problem: Du hättest die Matrizentypen polymorph machen müssen, sodass virtuelle Funktionen in einer abstrakten Basisklasse Matrix die implementierungs-unabhängige Funktionalität bereitstellen.

Edit:

Ist der Post zu lange oder zu unverständlich?

Ja, er ist recht lang. Du hättest dein Problem vielleicht etwas prägnanter formulieren können. Ausschweifende Darstellungen sind für Antworten klasse, und für Fragen IMO ein no-go, wenn nicht nötig.

Edit²: Nur ein Satzzeichen ergänzt. Ist das übertrieben? Oder ist meine Rechtfertigung dieses Edits übertrieben? Wer weiß. Wahrscheinlich beides.

Na hier liegt doch dein Problem: Du hättest die Matrizentypen polymorph machen müssen, sodass virtuelle Funktionen in einer abstrakten Basisklasse Matrix die implementierungs-unabhängige Funktionalität bereitstellen.

Daran hatte ich natürlich auch gedacht, aber um z.B. darken wie im OP zu implementieren, müsste ich dann auch einen polymorphen Wrapper um die Skalare basteln. Und das schlüge dann erst richtig auf die Laufzeit.

um z.B. darken wie im OP zu implementieren, müsste ich dann auch einen polymorphen Wrapper um die Skalare basteln.

Warum das?

Warum das?

Ups, hab' dich falsch verstanden.
Aber dann muss ich noch immer die Base-Klasse von Matrix mit CRPT implementeren, sonst muss ich den Filter doch wieder in jeder abgeleiteten Klasse einzeln implementieren. Und wenn ich das mache, dann kann ich wieder keine Methodenzeiger auf die Basisklasse in einem homogenen Vektor speichern.

Zur Implementierung: Ich bin mir auch über die Implikation im Klaren, dass die Größe einer Klasse davon abhängt, wie ihre Methoden (und die, der abgeleiteten Klassen) instantiiert werden, wobei ich auf die Schnelle kein Problem damit sehe.

Weiss nicht was du mit "Grösse einer Klasse" meinst. Die grösse der Objekte der Klasse hängt auf jeden Fall nicht davon ab, sondern nur davon ob es überhaupt virtuelle Funktionen gibt oder eben gar keine.

autismo schrieb:

Wieso gibt es das nicht bereits?

Also erstmal wäre es denke ich relativ kompliziert und aufwendig zu implementieren.

Dabei müsste erstmal das ganze Programm (d.h. sämtliche Translation Units!) "compiliert" werden (evtl. ohne Code-Generierung), um festzustellen welche Instanzierungen von virtuellen Funktionstemplates benötigt werden. Dann müssten diese instanziert werden. Dabei können weitere Instanzierungen von virtuellen Funktionstemplates dazukommen, d.h. man müsste so lange loopen bis die "Queue" der benötigten Instanzierungen leer ist.
Erst danach weiss man welche VTable-Slots überhaupt benötigt werden und kann dann mit der Code-Generierung anfangen, bzw. damit die ganzen Vtable-Indexe in den generierten Code "hineinzupatchen".

Nebenbei erfordert das auch ein Feature das in C++98 vorhanden war, und dann, weil es bis auf einen Compiler (Comeau C++) keiner implementiert hatte, im 2011er Standard wieder entfernt wurde. Nämlich "Exported Templates".

autismo schrieb:

Und wie soll man das Problem mit filter_base zufriedenstellend lösen, ohne dass besagtes Sprachmittel zur Verfügung steht?

Indem man das, was du vollautomatisch haben willst, halbautomatisch macht:

struct filter_base
{
    virtual ~filter_base() = default;

    virtual void apply( matrix_24bit_rgb& ) const = 0;
    virtual void apply( matrix_flt_rgb& ) const = 0;
};

template <class T>
struct template_filter_impl : public T
{
    virtual void apply( matrix_24bit_rgb& mat ) const
    {
        T::apply_impl(mat);
    }

    virtual void apply( matrix_flt_rgb& mat ) const
    {
        T::apply_impl(mat);
    }
};

struct darken_impl : public filter_base
{
    template <class MAT>
    void apply_impl( MAT& mat ) const
    {
        for( auto& i : mat )
            i /= 2;
    }
};

struct darken : public template_filter_impl<darken_impl>
{
};

Theoretisch kannst du hier auch das CRTP verwenden, dann könntest du dir die "Zwischenklassen" ( darken_impl & Co) sparen:

struct filter_base
{
    virtual ~filter_base() = default;

    virtual void apply( matrix_24bit_rgb& ) const = 0;
    virtual void apply( matrix_flt_rgb& ) const = 0;
};

template <class T>
struct template_filter_base : public filter_base
{
    virtual void apply( matrix_24bit_rgb& mat ) const
    {
        static_cast<T const*>(this)->apply_impl(mat);
    }

    virtual void apply( matrix_flt_rgb& mat ) const
    {
        static_cast<T const*>(this)->apply_impl(mat);
    }
};

struct darken : template_filter_base<darken>
{
    template <class MAT>
    void apply_impl( MAT& mat ) const
    {
        for( auto& i : mat )
            i /= 2;
    }
};