Klotzkopp

Die übermäßige Verwendung ist oft ein Zeichen für schlechtes Design. Wenn man immer wieder prüfen muss, welchen Typ ein Objekt denn nun wirklich hat, dann meist deswegen, weil eine Vererbungsbeziehung besteht, die eigentlich keine ist, sondern nur der Wiederverwendung von Code dient. static_cast.

Letzteren hat C++ von C geerbt, daher wird er auch "C-Style-Cast" genannt. Der macht je nach Situation komplett unterschiedliche Dinge, daher hat man in C++ neue Cast-Operatoren eingeführt, die einen klar abgegrenzenten Aufgabenbereich haben. Diese sind static_cast, dynamic_cast, reinterpret_cast und const_cast. static_cast kann beispielsweise von einem Zeiger auf eine Basis- in einen Zeiger auf eine abgeleitete Klasse konvertieren. Dabei wird allerdings nicht geprüft, ob der Zeiger wirklich auf ein Objekt der abgeleiteten Klasse zeigt, der Programmierer muss also wissen, was er tut. Wenn man eine solche Prüfung braucht, kann man dynamic_cast benutzten. Da wird der Typ zur Laufzeit geprüft, und falls er nicht passt, ist das Ergebnis des Cast-Ausdrucks null. Die übermäßige Verwendung von dynamic_cast ist allerdings oft ein Zeichen für schlechtes Design. const_cast kann const und volatile von einem Typ entfernen (oder hinzufügen). reinterpret_cast ist sozusagen der Holzhammer, er wandelt um, indem die Speicherrepräsentation einfach als der neue Typ interpretiert wird. Hier kann der Compiler nichts prüfen, wenn's knallt, ist der Programmierer schuld.

Du übergibst nicht das Ergebnis des Vergleichs. Du übergibst den Zeiger auf eine Funktion, die zwei Einträge vergleichen kann. Diese Funktion kennt deine Elemente natürlich. Die übergebene Funktion wird in addItemToList vermutlich mehrfach aufgerufen, um den neuen Eintrag richtig einzuordnen.

Wenn dein Funktionstemplate so funktioniert, wie es da steht, ist CDialogitem* implizit (also ohne Cast) in T konvertierbar. Das erreichst du auch mit einer einzigen Funktion, die CDialogitem* zurückgibt. Und selbst wenn du einen Cast brauchen solltest, kannst du die Funktion einfach zerlegen, in den Such-Teil (der ist immer gleich) und den Typumwandlungs-Teil (nur der hängt von T ab). Und dann wirst du feststellen, dass der Typumwandlungsteil dasselbe tut wie static_cast. Und damit tut's das hier auch: // get_DialogitemByCustomID ist kein Template und gibt CDialogItem* zurück ety::CButton* p = static_cast<ety::CButton*>(m_mapDialogs["bla"].get_DialogitemByCustomID("blubb"));[/code] Ein Template ist hier unnötig, und bläht dein Programm nur sinnlos auf.

Aufteilen kannst du es nur, wenn du vorher genau weißt, für welche Templateparameter du das Template brauchst. Dann kannst du es nämlich explizit instantiieren. Ich bin allerdings der Meinung, dass du für die einfache Konvertierung zwischen zwei Zeigertypen, die ohnehin implizit konvertierbar sind, gar kein Template brauchst.

Die Definition eines Funktionstemplates muss dort bekannt sei, wo das Template instanziiert wird. Kurz gesagt heißt das, dass du Templates normalerweise nicht in Header- und Quellcodedatei aufteilst, sondern direkt im Header definierst.

Verschoben -> Windows

Und warum hast du es nicht getan? Im Ernst, hol deine eigentliche Frage aus der zweilagigen Metafragen-Verpackung und stell sie. Und am besten erzählst du auch noch, für welches Problem die Antwort auf diese Frage deiner Meinung nach eine Lösung darstellt. Dann können wir beurteilen, ob du hier im richtigen Forum bist, und gezielt helfen.

Das Handle ist nicht ungültig. Es ist ein gültiges Monitor-Handle. Nur kann eine Funktion, die ein Fenster-Handle erwartet, damit einfach nichts anfangen. Das Problem ist eigentlich die Verwendung von GetDesktopWindow, denn diese Funktion beschränkt sich selbst aus Kompatibilitätsgründen auf den Primären Monitor. Wenn du deinen Desktop auf weitere Monitore erweiterst, ist deine Desktopfläche dementsprechend größer.

Die Case-Blöcke schließen sich nicht gegenseitig aus (also nur if, kein else if), und die Einzelergebnisse werden zum Sortierkriterium zusammengezählt. Die erste Sortierung muss außerdem absteigend sein, und die zweite fehlt ganz, wenn ich das richtig sehe.

Nein, damit kopierst du nur das erste Zeichen. Du kannst in C einen String nicht durch eine einfache Zuweisung kopieren, du musst strcpy benutzen.

Du setzt den data-Zeiger deiner Struktur immer wieder auf die Speicheradresse des Arrays puffer in main. Alle deine data-Zeiger verweisen also auf denselben Speicherbereich. Daher ändert jede neue Eingabe alle Einträge im Baum.

Überleg mal genau, wohin der Zeiger in deiner Struktur zeigt.

D.h. du surfst immer ohne JavaScript, ohne Cookies, ohne Flash usw.? Ich glaube, du hast keine Ahnung, wieviele Informationen ein Webseitenbetreiber über dich sammeln kann. Und du hast so viel Vertrauen in deinen Provider, dass er sich in einem Rechtsstreit für dich und deine Rechte stark macht? Du hoffst, dass alle Onlinedienstanbieter, mit denen du so zu tun hast, entweder nichts von dir wissen (das ist naiv) oder sich im Zweifel für dein Recht einsetzen (das ist auch naiv).

Das Web ist voll mit Aufklärung, aber ich heb mal einen wichtigen Teil für dich hervor: Na, was fehlt da? Stell dir vor, du stellst hier einen Text oder ein Bild ein, der irgendeinem Rechteinhaber sauer aufstößt. Dann kann der sich direkt an den Boardbetreiber wenden, um Informationen über dich abzufragen. Sicherlich steht das ganze immer noch auf rechtlicher Basis, aber ein rechtsstaatliches Organ ist an dem ganzen Vorgang überhaupt nicht mehr beteiligt. Der Rechteinhaber und der Onlineanbieter klären das also zunächst unter sich. Vergleiche jetzt mal das juristische Durchhaltevermögen einen durchschnittlichen Rechteinhabers mit dem eines Webforenbetreibers, dann kannst du dir ausrechnen, was bei der rechtlichen Prüfung, ob da wirklich gegen die Rechte des Rechteinhabers verstoßen wurde, herauskommt: Dass der Onlinedienstanbieter nachgibt, weil er es sich nicht erlauben kann, sich auf einen Rechtsstreit einzulassen. Im Endeffekt findet eine rechtliche Prüfung nicht statt, sondern der juristisch und finanziell besser aufgestellte Rechteinhaber kann unliebsame Inhalte entfernen lassen und Daten über vermeintliche Rechtsverletzer sammeln.

Wenn's ohne Optimierung läuft, und mit nicht, liegt es fast immer an schlampiger Programmierung. Unintialisierte Variablen, Arraybereichsüberschreitung, falsche oder fehlende Threadsynchronisierung. Den Debugger hast du schon versucht?

Kann es sein, dass du von C kommst? Verbesserungsvorschlag: void vergleichen(char* dateiname, char* vergleichsdatei) { ifstream datei1(dateiname); string zeile1; while(getline(datei1, zeile1)) { bool gefunden = false; ifstream datei2(vergleichsdatei); string zeile2; while(getline(datei2, zeile2)) { if(zeile1 == zeile2) { gefunden = true; break; } } if(!gefunden) cout<<zeile1<<"\nZeile nicht vorhanden\n\n"; } }[/code] Wenn die Dateien nicht riesengroß sind, könntest du sie auch komplett in den Speicher laden, dann musst du die Vergleichsdatei nicht mehrfach einlesen.

"Will irgendwie nicht klappen" ist keine ausreichende Fehlerbeschreibung. Was mir aber auffällt: eof eignet sich nicht als Schleifenbedingung, weil es erst dann true liefert, wenn das Lesen schon einmal fehlgeschlagen ist. Benutz die Leseoperation selbst als Schleifenbedingung.Wenn du beim Lesen am Dateiende angekommen bist, musst du erst den Fehlerstatus zurücksetzen, bevor du damit weiterarbeiten kannst. Relative Positionierung (also seekg mit 2 Parametern) funktioniert nicht bei Textdateien. Die Verwendung von open/close ist in C++ unüblich, darum kümmern sich Konstruktor und Destruktor.

Ohne das jetzt im Detail zu prüfen: Es reicht nicht, bei der Erkennung einer Kollision die Richtung zu ändern. Du musst auch die Position neu berechnen. Zur Berechnung: Math.sin((Math.PI / 2.0)) ist eine umständliche Schreibweise für 1, deine Koordinatenberechnung ließe sich vereinfachen zu koord.x = (int) (koord.x + maxspeed * Math.cos(richtung)); koord.y = (int) (koord.y + maxspeed * Math.sin(richtung)); [/code]

createTestData kann nie aufgerufen werden, weil die Eingabe 9 in der Funktion menu bereits abgefangen wird.

Dann zeig doch mal, wie du diesen Code aufrufst.

Der Code tut ja auch nichts beobachtbares. Was sollte denn deiner Meinung nach passieren? Zunächst sollte man sich vergegenwärtigen, dass strncpy nicht die "sichere" Version von strcpy ist. strncpy dient dazu, Ziel-Arrays mit fester Länge mit Nullbytes aufzufüllen. Falsch benutzt, hat strncpy dieselben Sicherheitsprobleme wie strcpy, und bringt sogar noch zusätzliche Risiken mit. Der zusätzliche Parameter von strncpy soll angeben, wie viel Platz im Ziel-Array ist. Wenn man da, wie du, einfach nur angibt, wie lang der Quellstring ist, hat man nichts gewonnen. Zudem hat strncpy die Eigenschaft, dass es keine Nullterminierung anhängt, wenn nicht genug Platz ist. Der Programmierer muss also genau wie bei strcpy sicherstellen, dass im Zielarray genug Platz ist. Der Unterschied ist nur, dass bei unzureichendem Platz bei strcpy sofort beim Schreiben undefiniertes Verhalten auftritt, und bei strncpy erst beim nächsten Lesen. Ich sehe in deinem Code keinen Grund, überhaupt strncpy zu benutzen.

"Funktioniert nicht" ist keine ausreichende Fehlerbeschreibung. So, wie du strncpy benutzt, wird keine Nullterminierung geschrieben.

Wenn du die Datei nicht ändern kannst, bleibt dir nur die Möglichkeit, sie zur Laufzeit einzulesen.

Es ist genau das, was der Wortlaut der Warnung aussagt: Da fehlen die geschweiften Klammern. So muss das aussehen: {"Finnland","SF ","FIM",0.301,0},