Problem mit Aufruf von templates in einer Funktion

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.

Rafzahn

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Plus die allseits gelobte Plattformunabhänigkeit.

Zeus

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ein Taxi ist auch besser als ein eigenes Auto

Rafzahn

Zeus schrieb:

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ein Taxi ist auch besser als ein eigenes Auto

Da will ich nicht widersprechen und das Taxi kostet in dem Fall nichtmal was

XSpille

Rafzahn schrieb:

Man muß nicht eine Zeile Code fürs aufräumen aufbringen.

Ich liebe diese Einstellung

Java macht ja allea selbstständig

Lass du mal schön wenn du z. B. irgendetwas schließt dein Object in
in irgendwelchen Listenern hängen...

Es räumt sich ja alles von alleine auf
Das Objekt wird ja (eigentlich) nicht mehr gebraucht

Ich will nicht wissen wie viele Java-N00bs sowas einfach nicht berücksichtigen.
Ein C++-Progger kennt solche Gefahren (spätestens nach leidigen Speicherzugriffsfehlern).

EDIT: Mich würd ja mal das Verhältnis zwischen Gebrauch von addListener und
removeListener eines (durchschnittlichen) Java-Programmierers interessieren

volkard

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen.

Aber in Java wird nur der Speicher automatisch verwaltet. Alle anderen Ressourcen, die stark beschränkt sind wie Datenbankverbindungen, oder kollidieren können wie offene Schreibdateien muß man per Hand verwalten.

Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen.

In C++ geschehen eigentlich auch keine Speicherlöcher. Ok, man muß ein wenig üben dafür.

Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen.

Fürs Aufräumen des Speichers.

Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ja, die soll mal egal sein.

Aber diese Art der Sicherheit halte ich für ein Anfängerproblem.

Ist man Profi, gilt wohl: Beide Sprachen sind sicher. In C++ sichert man per RAII http://de.wikipedia.org/wiki/Ressourcenbelegung_ist_Initialisierung und in Java? Ich weiß nicht genau. So? http://accu.org/index.php/journals/236
Hmm, das fände ich recht lästig.