Problem mit Aufruf von templates in einer Funktion

SeppJ

Rafzahn schrieb:

traversal.h(10) : error C2061: Syntaxfehler: Bezeichner 'TraversableGraph'

Ist das die ganze Fehlermeldung? Was für ein armseliger Compiler ist das denn?

mgaeckler

Rafzahn schrieb:

Wenn ich die version mit eingesetztem Typ benutze, die ja am ehesten gehen müsste:
virtual void visit(TraversableGraph<char> *g, unsigned int id) = 0;
dann kommt der Fehler:

traversal.h(10) : error C2061: Syntaxfehler: Bezeichner 'TraversableGraph'

Ist bestimmt wieder so eine verflixte Kleinigkeit...

Schau mal, was Dein Präprozessor daraus gemacht hat. Vielleicht irgendein Macro, das dazwischen funkt.

Ansonsten ist eine beliebte Ursache für solche Scheißfehler: Irgendwo ein Semikolon vergessen?

mfg Martin

Roger Wilco

SeppJ schrieb:

Rafzahn schrieb:

traversal.h(10) : error C2061: Syntaxfehler: Bezeichner 'TraversableGraph'

Ist das die ganze Fehlermeldung? Was für ein armseliger Compiler ist das denn?

Sieht nach MSVC aus.

Rafzahn

Jop ist der Compiler von Visual Studio 2008. Ist schämen angebracht?

Hab wieder bissl rumprobiert und jetzt wirds echt witzig. Hab über der main()-Funktion folgende Funktion eingefügt:

void asdf(TraversableGraph<char> *g)  {}

Funktioniert. Wird vom Compiler akzeptiert. Dann hab ich einfach mal diese Funktion per copy/paste in meine Klasse in der ich diesen visit-Aufruf brauch hin verschoben.

Restulat, in der Klasse bringt der Compiler obige Fehlermeldung in der main gehts, so lol.

Roger Wilco

Haste denn die Header-Datei in der TraversableGraph deklariert wird auch inkludiert?

Rafzahn

So Problem gelöst. Wenns jemand noch interessiert was los war, es scheint ein Problem mit dem Compiler zu sein. Habe eine Komplett neue Klasse, also auch mit neuem Namen erstellt und dann gings auf einmal.

Des Ding ist auch, wenn ich die alte Klasse restlos lösche und sie neu erstelle kommt der Fehler wieder. Auch ein "Projekt bereinigen", was im visual studio im menü zur Verfügung steht, ändert nichts dran. Muss daher einfach einen anderen Namen für die Klasse benutzen und dann passts.

Kann es sein, daß der Compiler von Microsoft müll ist?

SeppJ

Rafzahn schrieb:

Kann es sein, daß der Compiler von Microsoft müll ist?

Ohne den MS Compiler zu kennen: Nein, das ist kein Fehler im Compiler. Da ist noch irgend etwas anderes im Gange.

Nexus

Rafzahn schrieb:

Kann es sein, daß der Compiler von Microsoft müll ist?

Weniger. Aber es ist natürlich einfacher, dem Compiler die Schuld in die Schuhe zu schieben.

Ist vielleicht ein Namensraum im Spiel, der einmal ausgeleert wurde und einmal nicht? Oder irgendwelche Sonderzeichen, die beim Kompilieren nicht richtig erkannt werden (z.B. bei kopiertem Quellcode)? Versuch doch, ein Minimalbeispiel hinzukriegen, das den Fehler immer noch aufzeigt.

Rafzahn

Ja, gut möglich. Muss die Übung heute mal abschließen und dann geh ich dem Fehler auf den Grund.

cu all und danke für die Anteilnahme.

Rafzahn

Fehler endgültig gefunden!

War ein Problem mit dem Präprozessor!
In der TraversableGraph.h hatte ich das hier:

#include "Traversal.h"

und in der Traversal.h

#include "TraversableGraph.h"

Die haben sich gegenseitig includiert und das hat der Compiler nicht vertragen.

Ist meiner Meinung nach wirklich eine Compilerschwäche. Der könnte ruhig mitzählen wie oft eine Header-Datei angefasst wird. Bin normalerweise Java gewohnt und dort hatte ich noch nie Probleme mit imports.

SeppJ

Rafzahn schrieb:

Fehler endgültig gefunden!

War ein Problem mit dem Präprozessor!
In der TraversableGraph.h hatte ich das hier:
#include "Traversal.h"
und in der Traversal.h
#include "TraversableGraph.h"
Die haben sich gegenseitig includiert und das hat der Compiler nicht vertragen.

Ist meiner Meinung nach wirklich eine Compilerschwäche. Der könnte ruhig mitzählen wie oft eine Header-Datei angefasst wird. Bin normalerweise Java gewohnt und dort hatte ich noch nie Probleme mit imports.

Wieso sollte er? Das wäre ganz komisch wenn er das von sich aus täte. Wenn du willst, dass er das tut, nimm so etwas wie #pragma once . Vor Zirkularinklusion schützt dich dies jedoch auch nicht, weil dies ein Fehler in deinem Programmaufbau ist.

Ich bin jedoch noch immer entgeistert von der knappen Fehlermeldung. War das wirklich alles?

Nexus

Rafzahn schrieb:

Ist meiner Meinung nach wirklich eine Compilerschwäche. Der könnte ruhig mitzählen wie oft eine Header-Datei angefasst wird.

Das nennt sich Include-Guards und geht auch auf Sprachebene. Allerdings steckt da keine Magie dahinter, sondern es wird nur die mehrfache Inkludierung des gleichen Headers innerhalb einer Übersetzungseinheit verhindert. Bei falscher Anwendung wie zirkulären #include s nützt auch das nichts. Denn das ist ein Logik-/Designfehler, wobei es nicht die Aufgabe des Compilers ist, diesen zu beheben.

Rafzahn schrieb:

Bin normalerweise Java gewohnt und dort hatte ich noch nie Probleme mit imports.

Das Modulsystem von Java funktioniert komplett anders als die Header- und Implementierungsdateien in C++, das kannst du nicht vergleichen. Hier musst du eben etwas mehr selbst überlegen, besonders was die Trennung von Deklaration und Definition angeht. Entsprechend kannst du nicht davon ausgehen, dass modulare Programmierung in C++ gleich wie in Java abläuft. Ein #include ist nicht mehr als eine Textersetzung.

Rafzahn

@SeppJ: Ja, das war wirklich alles. Traurig aber wahr.

@Nexus: Vor allem wenn man vorher Java benutzt hat, merkt man dass cpp einfach aelter ist. Was die Objektorientierung angeht ist Java um einiges komfortabler. Man kann den Machern aber keinen Vorwurf machen, Sie haben ja damals schließlich Neuland betreten und die Java-Leute mussten es nur nachbauen und verbessern.

Michael E.

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

drakon

Michael E. schrieb:

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

Weil es eingeschränkter ist. Man hat nicht so viele Möglichkeiten es falsch zu machen und merkwürdiges Verhalten zu bekommen.
Java ist darauf ausgelegt, dass man z.B Vererbung polymorph benutzt und somit verhält es sich genau so, wie man es vom OOP Standpunkt her aus kennt.

volkard

drakon schrieb:

Michael E. schrieb:

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

Weil es eingeschränkter ist.

Wenn man nicht autofahren kann, ist das Fahrrad komfortabler.

drakon

volkard schrieb:

drakon schrieb:

Michael E. schrieb:

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

Weil es eingeschränkter ist.

Wenn man nicht autofahren kann, ist das Fahrrad komfortabler.

Ich hätts jetzt nicht so ausgedrückt, aber im Prinzip ja.

unskilled

SeppJ schrieb:

Ich bin jedoch noch immer entgeistert von der knappen Fehlermeldung. War das wirklich alles?

Was hätte er denn noch schreiben sollen?
Er kannte den Typ nicht - und das hat er uns auch gesagt - wüsste nicht, was er noch ausgeben sollte...

Rafzahn

drakon schrieb:

volkard schrieb:

drakon schrieb:

Michael E. schrieb:

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

Weil es eingeschränkter ist.

Wenn man nicht autofahren kann, ist das Fahrrad komfortabler.

Ich hätts jetzt nicht so ausgedrückt, aber im Prinzip ja.

Komisch, immer wenns um den Vergleich von java und cpp geht, läufts immer auf solche Bemerkungen hinaus

Michael E.

Rafzahn schrieb:

Komisch, immer wenns um den Vergleich von java und cpp geht, läufts immer auf solche Bemerkungen hinaus

Du musst aber zugeben, dass dein Post ziemlich trollig war. Du stellst eine gewagte These ohne Begründung in den Raum, die Java besser erscheinen lässt als C++. Ich kenne mich mit Java nicht aus, aber hinsichtlich der Unterstützung von OOP sind sich die beiden doch sehr ähnlich. Mir fallen nur kleinere Unterschiede auf bzgl. Mehrfachvererbung, ABC/Interfaces, Name Hiding etc. Ja gut, nicht-statische Memberfunktionen sind in Java automatisch virtual, aber das ist auch nicht das Riesending. Deshalb weiß ich immer noch nicht, was dich zu deiner Annahme verleitet.