Style - class template specializations && one class per file

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Style - class template specializations && one class per

Beitrag von kaiserludi »

CodingCat hat geschrieben:Wo muss der Benutzer denn casten? Schreibt der Benutzer wirklich permanent Templates mit Typdeduktion?
Ich hätte jetzt antworten wollen, "wenn er einen *const als Parameter in eine Funktion rein bekommt und die Funktion dann diesen Parameter an den Container weitergeben will":

Code: Alles auswählen

void bar(const int* const arr, short arrSize)
{
// do some unrelated stuff
    Foo<const int*>((const int*)arr, arrSize);
// do more unrelated stuff
}
Mir fällt allerdings gerade auf, dass dort gar kein Cast erforderlich ist, weil im Gegensatz zu dem Wert, auf den der Zeiger zeigt, der Zeiger selbst hier ja per Kopie übergeben wird und so im Inneren des Containers eh nicht relevant ist, ob der Originalpointer mal const war. :oops:

Damit fällt mir jetzt kein Grund mehr für eine *const Spezialisierung (oder den Einsatz der von dir genannten Alternativen) ein.

Fazit: Du hattest recht - ich brauche gar keine *const Spezialisierung :oops:
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Style - class template specializations && one class per

Beitrag von kaiserludi »

CodingCat hat geschrieben: Wieso brauchst du Spezialisierungen für einzelne Datentypen? Sonderbehandlungen lassen sich in der Regel problemlos in Traits (implizit wie explizit) oder sogar einfach überladene Funktionen auslagern. Deine Beschreibung der Spezialisierung von Funktoren geht wohl in die Richtung impliziter Traits, dennoch machst du dir das eventuell einfach zu kompliziert. Wenn das einfache Aufrufen einer überladenen Funktion für die Sonderbehandlung nicht ausreicht, empfiehlt sich ein einfaches Template für den jeweiligen Aufgabenbereich:.
Um darauf noch einzugehen:
Einfache überladene Funktionen reichen nich aus, weil ich damit, durch den Unterschied in der Anzahl der nich spezialisierten Parameter des Klassentemplates, welches mit den privaten einfachen Funktionsüberladungen umgangen werden soll, zwischen partiellen Spezialisierungen und der generischen Version des Klassentemplates, verschieden viele Parameter in den unterschiedlichen Funktionsüberladungen hätte, wodurch ich ohne Traits einen Switch über die übergebenen Typen und runtime-overhead via RTTI bräuchte, um den korrekten Overload aufzurufen. Da erschienen mir Traits als das kleinere Übel.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Style - class template specializations && one class per

Beitrag von kaiserludi »

Im Zusammenhang mit Spezialisierung für Zeiger habe ich noch eine weitere Frage.

Ich habe ein Containerklassentemplate in einer generischen Version

Code: Alles auswählen

template<typename Etype>
class Foo
{
public:
	Foo(Etype data);
	// more constructors, operators and functions  come here 
};
und dazu eine partielle Spezialisierung, die ein- oder- mehrdimensionale C-Arrays als Nutzlast im Konstruktor in Empfang nimmt

Code: Alles auswählen

template<typename Etype>
class Foo<Etype*>
{
public:
	Foo(Etype* const data, short size);
	Foo(Etype*const data, const short* const sizes);
	// the rest is the same like in generic version
};
Bis auf den Konstruktor kann ich den Rest des Codes in beiden Versionen identisch halten: gleiche API und auch gleiche Implementation - da ich einzelne Objekte einfach genauso wie 1-dimensionale Arrays der Größe 1 behandeln kann.

Ich habe also mit der Spezialisierungslösung der ganzen Klasse bis auf diese 1-2 Konstruktoren, die sich unterscheiden, 2 komplett identische, redundante Implementationen der Klasse rumliegen, was natürlich eher unschön ist, auch wenn es sich größtenteils nur um Einzeiler handelt.

Gemeinsame Funktionalität in eine nicht generische Basisklasse auszulagern, hilft nur begrenzt, da Konsturktoren und Operatoren ja damit immer noch doppelt implementiert werden müssten (ja, die beiden Implementationen müssten dann jeweils nur die der Basisklasse explizit aufrufen, aber viele der Funktionen sind eh nur Einzeiler, da bingt das dann auch nicht viel).

Wie würdet ihr das lösen?
Ideal in meinen Augen ist, wenn ich für Etype Konstruktor A habe, nicht aber B und C, für Etype* hignegen Konstruktor B und C, nicht aber A, wähend der ganze Rest der API sowohl der generischen Version als auch der Pointer Spezialisierung aus dem selben Source generiert wird.

Mir ist dabei schon wichtig, dass man als Nutzer des Tempaltes einfach Foo<int>(myInt); oder Foo<int*>(myIntArray, arrSize); schreiben kann und nicht immer sowas umständliches schreiben muss wie Foo<int>(FooCreator<int>(myInt)); Foo<int*>(FooCreator<int*>(myIntArr, arrSize));

Danke im Voraus für eure Vorschläge.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Style - class template specializations && one class per

Beitrag von CodingCat »

kaiserludi hat geschrieben:Ich habe also mit der Spezialisierungslösung der ganzen Klasse bis auf diese 1-2 Konstruktoren, die sich unterscheiden, 2 komplett identische, redundante Implementationen der Klasse rumliegen, was natürlich eher unschön ist, auch wenn es sich größtenteils nur um Einzeiler handelt.
Dann brauchst du eigentlich überhaupt keine Spezialisierung, sondern einfach nur die drei Konstruktoren. Wenn du unbedingt unterschiedliche Typen durch den zusätzlichen Zeigertypkonstruktor erzwingen willst, dann nimm static_assert (musst du pre-C++11 selber schreiben):

Code: Alles auswählen

template<typename EOrPtype>
class Foo
{
public:
        typedef typename remove_pointer<EOrPType>::type EType;
        static const bool IsPointer = is_pointer<EOrPType>::value;

        Foo(Etype data)
        {
            static_assert(!IsPointer, "Unavailable in the array version. Remove '*' for single-value version.");
            ...
        }
        Foo(Etype* const data, short size)
        {
            static_assert(IsPointer, "Unavailable in the single-value version. Add '*' for array version.");
            ...
        }
        Foo(Etype*const data, const short* const sizes)
        {
            static_assert(IsPointer, "Unavailable in the single-value version. Add '*' for array version.");
            ...
        }

        ...
};
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Style - class template specializations && one class per

Beitrag von kaiserludi »

Ah, natülich. Ich wusste doch, dass es eine Lösung gibt, die alle meine Wünsche abdeckt und die ich nicht sehe :)

Ich würde ja sagen, du hast langsam echt ein Bier bei mir gut, aber ich glaube, eine Maus sagt dir eher zu ;)
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Antworten