expected primary-expression before "int"



  • Hallo,

    Was soll das hier

    sList<class T> test;
    

    bewirken?
    Du must hier schon den Type angeben für den deine sList spezielisiert werden soll (z.Bsp. int).



  • slist<int> test;
    test.insertAtFront(18);
    

  • Mod

    Es ist im Prinzip so ziemlich alles falsch, was man falsch machen kann. Darf ich dir nahelegen, zuerst einmal etwas mehr über Templates und Klassen zu lesen, bevor du weitermachst?



  • ahhhhh so geht das mit dem da...
    vielen Dank euch

    @SeppJ
    Klassen sind nicht das Problem, nur diese Templates sind mir vollkommen unklar.


  • Mod

    benny111 schrieb:

    @SeppJ
    Klassen sind nicht das Problem, nur diese Templates sind mir vollkommen unklar.

    Wie kommt es dann zu solchen Kuriositäten?

    template <class T>
    class sList
    {
     // ...
      listElement<T>* sList<T>::insertAtFront( T key )
     // ...
    }:
    

    Bei einem Nicht-Template würdest du das doch nicht so machen.



  • Das stand zugegebener Maßen so auf den Folien aus unserer Uni...
    Ich habs einfach mal rein kopiert und versucht so zum laufen zu bekommen um es darüber zu verstehen. 🙄

    Is nicht gut?


  • Mod

    benny111 schrieb:

    Das stand zugegebener Maßen so auf den Folien aus unserer Uni...
    Ich habs einfach mal rein kopiert und versucht so zum laufen zu bekommen um es darüber zu verstehen. 🙄

    Au weia. Entweder ist das tatsächlich der schlechteste C++-Kurs von dem ich je gehört habe (und das will was heißen!) oder du hast da irgendwo was falsch abgeschrieben/verstanden.

    Is nicht gut?

    Zusammen mit deinem Wissen über Klassen und den Compilerfehlermeldungen die du bekommen musst, solltest du eigentlich beantworten können, was damit nicht stimmt.



  • ich habs per copy and paste rüber gezogen...
    was die Listen angeht würde ich ja auch gerne mit push und pull arbeiten... aber das geht ja über das Template nicht (vermute ich mal, wenn ichs wüste wär ich net hier!)



  • SeppJ schrieb:

    Au weia. Entweder ist das tatsächlich der schlechteste C++-Kurs von dem ich je gehört habe (und das will was heißen!)

    Echt? Ich gehe eigentlich davon aus, dass Unis mit C++ in der Regel überfordert sind. (Und das ist nicht wirklich nur Schuld der Unis)

    Zusammen mit deinem Wissen über Klassen und den Compilerfehlermeldungen die du bekommen musst, solltest du eigentlich beantworten können, was damit nicht stimmt.

    Gibt das überhaupt Compilerfehler? Bei Nicht-Template-Klassen ist das erlaubt:

    class A {
      public:
       void A::foo() { ... }
    };
    

  • Mod

    benny111 schrieb:

    ich habs per copy and paste rüber gezogen...

    War das vielleicht eine Aufgabe, die Fehler zu suchen?

    was die Listen angeht würde ich ja auch gerne mit push und pull arbeiten... aber das geht ja über das Template nicht (vermute ich mal, wenn ichs wüste wär ich net hier!)

    😕 Ich weiß zwar nicht was du meinst, aber wieso solltest du mit Templates etwas nicht machen können, was ohne geht? Das ist doch der ganze Sinn an der Geschichte, dass das nicht so ist!


  • Mod

    Bashar schrieb:

    Gibt das überhaupt Compilerfehler? Bei Nicht-Template-Klassen ist das erlaubt:

    class A {
      public:
       void A::foo() { ... }
    };
    

    Bei mir schon. In beiden Fällen. Wo hast du her, dass das erlaubt ist? Ich wüsste nichts davon.

    edit: Im Standard steht auch nichts davon, dass dies erlaubt wäre. Ich finde zwar kein explizites Verbot, aber die Deklaration einer Memberfunktion hat anders auszuschauen.



  • SeppJ schrieb:

    benny111 schrieb:

    ich habs per copy and paste rüber gezogen...

    War das vielleicht eine Aufgabe, die Fehler zu suchen?

    Nein, die ganz normale Vorlesungsfolie. Weiß gerade leider nicht ob ich die zur allgemeinen Belustigung hochladen darf.


  • Mod

    benny111 schrieb:

    Nein, die ganz normale Vorlesungsfolie. Weiß gerade leider nicht ob ich die zur allgemeinen Belustigung hochladen darf.

    Nach Bashars Einwurf habe ich mal recherchiert. Anscheinend akzeptieren alte Compiler diesen Code. Insofern ist es dann bloß genau so schlimm wie die anderen schlimmen C++-Kurse. Ich dachte schon, dass man euch Code vorsetzt, der nicht einmal beim Dozenten selbst compiliert. Aber er hat wohl bloß einen sehr toleranten Compiler und weiß es nicht besser.

    Ist natürlich trotzdem schlichtweg falsch und unportabel.



  • SeppJ schrieb:

    Wo hast du her, dass das erlaubt ist? Ich wüsste nichts davon.

    Ich hab das mal in unserem Code ausgegraben, war wohl ein alter Copy&Paste-Fehler.



  • aber gut das wir dabei sind... nächstes Problem (selber Quellcode)

    Fehler:
    21 'class sList<int>' has no member named 'begin'
    21 'class sList<int>' has no member named 'end'

    Ich hab die Ausgabefunktion mal mit test.ausgabe(test); angesprochen (weiß selbst das das nicht schön aussieht...)

    list ist included
    wo ist also das Problem?


  • Mod

    benny111 schrieb:

    list ist included
    wo ist also das Problem?

    Nur weil list und sList ähnlich heißen, haben sie nichts miteinander zu tun. Dein sList hat keine Member namens begin oder end. Ich weiß nicht, was man dazu noch mehr sagen soll.

    edit: Vielleicht ist der Kurs doch noch schlechter als vermutet. 🙄



  • das würde ja bedeuten das dieser programmierter scheiß nicht equivalent mit einer normalen Liste ist - weil bei ner normalen Liste springt begin und end doch an.

    Das meinte ich mit "list included".



  • benny111 schrieb:

    das würde ja bedeuten das dieser programmierter scheiß nicht equivalent mit einer normalen Liste ist - weil bei ner normalen Liste springt begin und end doch an.

    Aber nicht durch Magie, sondern weil list Methoden namens begin und end hat. Wenn du äquivalente Funktionalität haben willst, musst du die bei deiner Liste logischerweise auch implementieren.



  • Was mir noch auf die schnelle zu dem Code auffällt:

    • Memberdefinitionen sollte man nicht in die Klassendefinitionen packen
    • using namespace std; ist hässlich (Geschmackssache) und kann Namenskollisionen verursachen
    • listElement sollte ein struct sein (Geschmackssache)
    • begin() und end() werden genutzt, ohne dass sie deklariert sind
    • new wirft, wenn es fehlschlägt. Das mit dem Vergleich nach dem Aufruf ist Quatsch
    • Kein DTor -> Speicherlecks
    • Wieso ignore und get ? get genügt.
    • Wieso wird key kopiert statt einfach eine Referenz zu machen?

Anmelden zum Antworten