Problem mit (*Iterator)
-
Oha! Ich schaue in VS2008 immer in der "Fehlerliste" nach, dort steht das nicht. In der "Ausgabe" steht es jedoch... Und wieder was gelernt^^
-
Hmmm, stimmt, es gibt ja noch eine Fehlerliste
Die benutze ich persönlich eigentlich nie, weil sie eben nicht alle Informationen anzeigt. Zudem kannst du in der Ausgabe auch einen Doppelklick auf den Fehler machen und kommst zur entsprechenden Stelle. Die Fehlerliste ist eigentlich total überflüssig, sie stellt es höchstens ein wenig schöner dar und lässt ein paar Sortierungen zu. Habe ich aber noch nie benötigt.Grüssli
-
Huch, Fehlerliste. Wusste gar nicht, dass es die gibt, aber konnte bisher trotzdem Fehler beheben.
In MSVC++ gibt es sowieso einige Menüs, die ich noch nie verwendet habe...
-
Nexus schrieb:
Huch, Fehlerliste. Wusste gar nicht, dass es die gibt, aber konnte bisher trotzdem Fehler beheben.
In MSVC++ gibt es sowieso einige Menüs, die ich noch nie verwendet habe...
Dito. Imo braucht man eh keine grosse Filterung der Probleme/Warnungen. Fehler muss man sowieso beim ersten beginngen abarbeiten und Warnungen.. Naja.. Die sollten einen eh ständig nerven, dass man etwas dagegen tut.
-
drakon schrieb:
[...] und Warnungen.. Naja.. Die sollten einen eh ständig nerven, dass man etwas dagegen tut.
Hm, manchmal gibt es aber schon so eine Versuchung zu
#pragma warning(disable: )- zum Beispiel bei "Zuweisungsoperator konnte nicht generiert werden" - das weiss ich, wenn ichconst-Member habe, und jetzt?
-
Nexus schrieb:
drakon schrieb:
[...] und Warnungen.. Naja.. Die sollten einen eh ständig nerven, dass man etwas dagegen tut.
Hm, manchmal gibt es aber schon so eine Versuchung zu
#pragma warning(disable: )- zum Beispiel bei "Zuweisungsoperator konnte nicht generiert werden" - das weiss ich, wenn ichconst-Member habe, und jetzt?Ja, klar, das kann man natürlich machen, aber nicht gerade beim ersten mal, sondenr erst, wenn die Warnung wirklich nervt. Allerdings würde ich da eh nicht die Warnung ausschalten, sondern den Zuweisungsoperator halt privat deklarieren.
-
drakon schrieb:
Ja, klar, das kann man natürlich machen, aber nicht gerade beim ersten mal, sondenr erst, wenn die Warnung wirklich nervt. Allerdings würde ich da eh nicht die Warnung ausschalten, sondern den Zuweisungsoperator halt privat deklarieren.
Es ist allerdings problematisch, wenn die Klasse aus einer anderen Bibliothek stammt. Habe ich zum Beispiel bei Boost.Fusion erlebt und weil das noch riesige Templatekonstrukte sind, hast du zu jeder Warnung noch die Erklärungen, von welcher Instantiierung mit welchen Parametern
Grüssli
-
Hehe. Dann schalt halt die Warnung aus.. :p
-
Dravere schrieb:
drakon schrieb:
Ja, klar, das kann man natürlich machen, aber nicht gerade beim ersten mal, sondenr erst, wenn die Warnung wirklich nervt. Allerdings würde ich da eh nicht die Warnung ausschalten, sondern den Zuweisungsoperator halt privat deklarieren.
Es ist allerdings problematisch, wenn die Klasse aus einer anderen Bibliothek stammt. Habe ich zum Beispiel bei Boost.Fusion erlebt und weil das noch riesige Templatekonstrukte sind, hast du zu jeder Warnung noch die Erklärungen, von welcher Instantiierung mit welchen Parametern
Grüssli
Ich geh dann eher dazu über, die Bibliotheksklasse zu wrappen, da ich sowieso meist die Schnittstelle an meine Bedürfnisse anpassen muss - dann ist der private op= nur eine Fingerübung
-
pumuckl schrieb:
Ich geh dann eher dazu über, die Bibliotheksklasse zu wrappen, da ich sowieso meist die Schnittstelle an meine Bedürfnisse anpassen muss - dann ist der private op= nur eine Fingerübung
Boost.Fusion wrappen ... öhm, wozu? Das ist ein TMP Tuple Boost.MPL Konstrukt. Nicht nur das es extrem Anpassungsfähig ist, es dürfte wohl auch recht viel Aufwand sein, das Zeug zu wrappen
Und also irgendwo hat es ja Grenzen. Eine Woche (vielleicht mehr?) einen Wrapper schreiben gegenüber einem simplen
disable warning?Grüssli
