Templates mit Basisklassen

Mr. N

Was glaubst Du denn braucht Humes Hack großartig an CPU-Zeit? Lies Dir den Code doch mal genau durch!
Äh... der Compiler ist ja magisch...
Und warum zum Geier soll das die Mozilla-Compilezeit in die Höhe treiben?
... Wenn das in mehreren Header verwendet wird (Mozilla is C++), schließlich lassen sich templates nich exporten, dann sind das bei den paar wenigen source files ein bisschen was. Zugegeben keine Stunde :D.
> Was findest Du denn an der Implementierung so unhübsch? Sie ist gut verständlich und funktioniert völlig ohne Laufzeitkosten, was ist daran nicht gut?
GUT VERSTÄNDLICH? Gut verständlich heißt, beim ersten Anschauen verständlich. Dieser Hack mit sizeof und (T *)0 ist für meine Augen nicht sofort verständlich.

Gerard

Original erstellt von Mr. N:
*GUT VERSTÄNDLICH? Gut verständlich heißt, beim ersten Anschauen verständlich. Dieser Hack mit sizeof und (T )0 ist für meine Augen nicht sofort verständlich.

Welches c++ Konstrukt ist den beim ersten mal verständlich?
Ich finde das Template zeugs ist eine zweite Sprache, die man seperat lernen kann wenn man es will.

Für jemand der mal Modern C++ Desing gelesen hat ist das hier doch ein klacks. Verzweifle nicht wenn du die ganzen Keywörter kennst aber nicht weist was sie in diesen Zusammenhang bewirken, es sind nur ein paar neue Sachen + den Skill duch die <> duch zu blicken.

Zu der Sache das es von der Sprache direkt unterstützt werden sollte:
Ein paar Nachteile:
Die Sparche wird immer dicker und unlenbar.
So eine lib wird nie alles können was du brauchst, dann muss du wieder zu den Hacks greifen.
volkard meinte mal das er sich eine Sprache wüncht die nur goto kann, while for und co. gibts implementiert mit hilfe von goto in einen Modul der Standard Lib

Trift dieses hier nicht genau den Gedanken?

Zu der Sache mit der Compilierzeit:
lohnt es sich dafür c++ umzukrämpeln?,
es steckt noch ne menge potenzial in den compiliern
jeden monat gibt es ein cpu der 100 mhz mehr hat

*wieder mal c++ schön geredet*

[ Dieser Beitrag wurde am 06.04.2003 um 04:35 Uhr von Dimah editiert. ]

PMrogan

OK, Danke!

Werds mal implementieren...

MfG PMrogan

PMrogan

Nachdem sich meine Problemstellung geringfügig geändert hatte,
musste ich das ganze noch etwas modifizieren:

Nun werden nur abgeleitete Klassen akzeptiert:

template <class T, class U>
struct IsDerived
{
    typedef char no;
    struct yes {char d[2];};
    static yes checkD(const volatile U*); //Is derived?
    static no checkD(...);
    static yes checkB(const volatile T*); //Is base class?
    static no checkB(...);
    enum {value = sizeof( checkD((T*)0)) == sizeof(yes) && sizeof( checkB((U*)0)) == sizeof(no)};
};

MfG PMrogan

HumeSikkins

@Mr.N
Irgendwie ist mir deine Aggressivität nicht ganz klar. Wie auch immer. Hier meine 0.02 Euro:

Ich aber nicht.

Warum du es nicht ellegant findest, hast du noch nicht beantwortet. Ist aber auch nicht so wichtig.

Solche fancy Sachen gehören in die Sprache.

Das halte ich für nichts sagend. Definiere "fancy Sachen". Was für dich fancy ist, mag für mich trivial sein und andersherum. Da musst du schon konkreter weredn. Und selbst wenn wir dann wissen was du mit "fancy Sachen" meinst. Wo willst du aufhören. Was soll in die Sprache und was nicht? Der Stroustrup hat mittlerweile mehr als 1000 Seiten. Wie groß soll er noch werden?

Wenn du damit meinst, dass sowas wie ein Type-Traits-System (oder mindestens ein typeof) in die Sprache soll, ok damit könnte ich mich auch anfreunden. Aber alle Tempalate-Tricks von z.B. boost in die Sprache integrieren? Das kann wirklich nicht dein ernst sein.

GUT VERSTÄNDLICH? Gut verständlich heißt, beim ersten Anschauen verständlich

Gust verständlich ist einzig eine Frage der Ausbildung. Wenn jedes zweite C++ Buch einem Anfänger veraltetes kaputtes Pre-Standard-C++ beibringt, ist es kein wunder, dass für die Leser solcher Bücher Templatecode oder die STL nicht gut verständlich ist. Fängst du allerdings z.B. mit "Accelerated C++" an, dann sieht das schon etwas anders aus. Sicher, Templates werden in C++ sicher nie den "schöne-Syntax-Preis"-Gewinnen, dazu sind sie zu spät in die Sprache integriert wurden, Templatecode aber als generell unverständlich zu bezeichnen halte ich für Ignoranz.

Templatecode wird mit der Komplexität der zu lösenden Aufgabe immer schwieriger. Vergleicht man aber mal die Komplexität der hier gestellten Aufgabe mit der Komplexität der Lösung (nimm noch eine Bibliothek hinzu), dann finde ich das Verhältnis noch sehr erträglich.

Äh... der Compiler ist ja magisch...

Nein. Natürlich nicht. Nur steht es zu erwarten, dass Compiler die Optimierungen die sie an anderen Stellen schon seit Jahrhunderten benutzen irgendwann auch in der Templategenerierung einsetzen werden. Zumindest wenn Templates in C++ weiter so beliebt bleiben.

Für mich ist das mit den Templates ein bischen wie mit der OOP. Derjenige der die krassen Bibliotheken schreibt, muss mit einer großen Komplexität kämpfen. Anwender einer Bibliothek erhalten aber sehr mächtige Werkzeuge die dennoch relativ leicht zu verwenden sind.

[ Dieser Beitrag wurde am 06.04.2003 um 11:55 Uhr von HumeSikkins editiert. ]

Mr. N

templates selber verstehe ich ja. verstehen kann ich

template <bool> class CompileTimeAssert;
template <> class CompileTimeAssert<true> {};

template <class T, class U>
struct IsDerived
{
    typedef char no;
    struct yes {char d[2];};
    static yes check(const volatile U*);
    static no check(...);
    enum {value = sizeof( check((T*)0)) == sizeof(yes)};
};

auch. aber erst nachdem ich 5 minuten darüber nachgedacht habe. typkompatibilitätskeywords auf der anderen seite fände ich nicht zuviel verlangt:

X sametype Y // X und Y sind genau der gleiche typ
X derivtype Y // X ist ein von Y abgeleiteter typ

ist finde ich besser verständlich

ps: kA warum ich manchmal so aggressiv bin

HumeSikkins

typkompatibilitätskeywords auf der anderen seite fände ich nicht zuviel verlangt:

Das wäre in meine Augen zu speziell. Es gibt nahezu unendlich viele Fragen die man stellen kann bzw. Relationen in denen zwei Typen stehen können.

Ein Type-Traits-Geschichte fest in die Sprache integriert hingegen fände ich wie gesagt keine schlechte Idee. Damit könnte man sich die komplexen Sachen dann leicht selbst basteln. Man wäre nicht so festgelegt wie bei neuen Keywords.

sowas wäre toll: (schon wieder ein neues sprachkonstrukt :D)

relation <class A, class B> 
derived { class A : public B }

relation <class A, class B>
member_class { class A { class B; } }

template <class T>
relation <class A, class B, class C>
siblings_classes { class A : public T && class B : public T && class C : public T }

template <class T, class U>
relation <class A, class B, class C, class D>
complex_relation { 
     class A : public T, public U
&&   class B : public A, public U
&&   class C : public A, public B
&&   class D : private C
}

template <class A, class B>
class X {
    relation <A, B> == member_class<A, B> ;
    relation <A, B, my_class, blub> == complex_relation <my_class, A, B, blub> ;
};

Sieht doch verständlich aus
ist aber unüberdacht :p
aber sieht nicht nach viel Mehraufwand aus
und
sieht erweiterbar aus
nehmt es auseinander

k.A.

warum funzen die smilies nicht?