Klotzkopp

Ohne jetzt zu sehr auf Theoriekram rumreiten zu wollen: Sagt dir der Begriff "Normalisierung" etwas?

Der Unterschied ist der zwischen direkter Initialisierung und Default-Initialisierung mit anschließender Zuweisung. Je nach Typ des Members kann das ein großer Unterschied sein, beispielsweise wenn der Zuweisungsoperator sehr "teuer" ist. Bei Destruktoren muss ich da widersprechen, dazu habe ich zu oft gesehen, wie einer Klasse reflexartig ein virtueller Destruktor mit leerem Rumpf verpasst wurde. Eine Klasse sollte nur dann einen Destruktor bekommen, wenn sie ihn braucht. Und wenn sie ihn braucht, braucht sie auch einen Copy-Konstruktor und einen Copy-Zuweisungsoperator, oder muss unkopierbar gemacht werden. Destruktoren von Basisklassen sollten public virtual oder protected und nicht virtual sein.

C++ Standard (1998 oder 2003, den neuesten habe ich noch nicht), Punkt 12.1.5. Wenn es keinen benutzerdefinierten Destruktor gibt, wird ein impliziter erzeugt. Punkt 12.4.3. Wenn du const-Member oder Referenzmember hast, geht es gar nicht ohne Initialisierungsliste. Ich finde, man sollte sich das gleich richtig angewöhnen. Standard (98/03), Punkt 3.5.5. Keine. Wenn der Compiler am Ende der main-Funktion keine return-Anweisung findet, nimmt er return 0; an. Ein Compiler, der da warnt, ist kaputt . Ich hatte es auch nur angemerkt, weil ich den Eindruck hatte, dass du die fehlende Return-Anweisung als Fehler angesehen hast.

Durch eine explizite Typumwandlung, auf neudeutsch "Cast". Siehe Casting Operators.

Der Compiler erzeugt nur dann einen Default-Konstruktor, wenn der Benutzer überhaupt keinen Konstruktor definiert. Letzteres ist das, was man Überladen nennt Bei main darf man die return-Anweisung weglassen, das ist dann gleichbedeutend mit return 0;

Nein. Wenn du eine Operation, die eine Million Mal ausgeführt werden muss, in zwei verschachtelte Schleifen mit je 1000 Iterationen umsetzt, und die Tastatur nur in der äußeren Schleife abfragst, geschieht diese Abfrage logischerweise nur 1000 Mal. Je seltener du die Abfrage machst, desto schlechter ist natürlich die Reaktionszeit auf den Tastendruck. Auch jede andere Möglichkeit muss letztendlich dasselbe tun: Beim Betriebssystem nachfragen, ob ein Tastendruck im Tastaturpuffer liegt. Da kannst du nicht viel Geschwindigkeit rausholen. Selbst wenn du die Abfrage in einen anderen Thread auslagerst: Die reine Prüfung, ob etwas passiert ist, kostet dich viel Zeit, wenn du sie bei jedem Durchlauf machst.

Für cout kannst du dir selbst einen Ausgabeoperator schreiben. Anscheinend ist das eine recht neue Erweiterung des GCC, und ist auch nur für 64-Bit-Plattformen verfügbar. Ich vermute, die Entwickler sind einfach noch nicht soweit, oder behandeln das mit niedriger Priorität. Eine Spezialisierung von std::numeric_limits gibt's dafür offenbar auch noch nicht. Bei diesen Datentypen stand vermutlich die Berechnung im Vordergrund, nicht die Ein- und Ausgabe als Text. Ein Mensch kann mit Zahlen dieser Größenordnung ohnehin nicht viel anfangen. Da wäre mir bei Open Source aber schon Eigenartigeres begegnet Ich hab auf Anhieb auch nichts gefunden, nur ein paar Leute, die dasselbe Problem haben, aber auch da keine Antwort.

Das ist doch eine Grundübung: Wiederholtes Dividieren durch 10 liefert dir als Divisionsrest die einzelnen Ziffern. Die musst du dann nur noch in umgekehrter Reihenfolge ausgeben. Das kannst du erreichen, indem du die Ziffern in einem Puffer sammelst, oder durch Rekursion.

Dir muss klar sein, dass so eine Abfrage bei jedem Schleifendurchlauf, gerade wenn ansonsten in der Schleife praktisch nichts passiert, dein Programm locker mal eben um einen Faktor 100 verlangsamen kann. Eben genau soviel, wie die Ausführung von my_kbhit und die Prüfung des Ergebnisses länger dauert als das Inkrementieren eines Integers. Je länger die eigentliche Verarbeitung in der Schleife dauert, desto geringer wird die relative Verlangsamung durch die Tastaturabfrage. Nein, darum geht's dir nicht, das hast du schon gelöst. Du hast jetzt nur noch die nichtfunktionale Anforderung, dass dir die aktuelle Implementierung zu langsam ist. Zerleg die Berechnung in zwei verschachtelte Schleifen, und frag die Tastatur nur in der äußeren ab.

Wenn das Makro durch ein Stringliteral ersetzt wird, passt das. Hintereinanderstehende Stringliterale werden einfach verbunden. @DITTY: Diese Datentypen sind nicht Bestandteil des Standards, sondern ein Zusatzfeature deines Compilers. Insofern solltest du deine Compilerdokumentation bemühen. Falls dein Compiler zwar mit dem 128-Bit-Typ rechnen, aber ihn (noch) nicht ausgeben kann, kannst du dir natürlich auch eine Ausgabefunktion selbst schreiben.

Ich vermute, dass der Compiler in diesem Fall die Schleife komplett wegoptimiert, weil er erkennt, dass sie nichts bewirkt.

Regex.Replace(String, String, String) ist static ("Shared" in VB), daher braucht man keine Regex-Instanz: text = Regex.Replace(text, regex, "")

Kann auch nicht funktionieren, wenn man den Funktionsrückgabewert hintenüber fallen lässt: text = SearchAnd.Replace(text, regex, "")

Ja, das merkt man. Alle deine Fragen werden dort beantwortet. Ok, von mir erhältst du keine Hilfe mehr. Viel Erfolg noch.

Das bedeutet, dass vorher ein erfolgreicher Aufruf von WSAStartup stattfinden muss. Was WSAStartup ist, verrät dir ebenfalls die Dokumentation: WSAStartup function (Windows) Das googelt man eigentlich in 30 Sekunden. Erster Treffer für WSAStartup ist doch die Doku :confused:

Doku lesen hilft: WSANOTINITIALISED: A successful WSAStartup call must occur before using this function. Quelle: gethostbyname Function (Windows)

while(!(cin >> radius)) { cout << "Falsche Eingabe, bitte wiederholen: "; // Fehlerstatus des Eingabestreams zurücksetzen cin.clear(); // Unverarbeitete Zeichen aus dem Stream entfernen cin.ignore(numeric_limits<streamsize>::max(), '\n'); } [/code] Du brauchst dafür noch [code]#include <limits>

Wenn du die Operanden vertauschst, kannst du > durch < ersetzen. Oder du negierst den Ausdruck und ersetzt > durch <=. Aber die Frage nach dem Sinn steht immer noch im Raum. Warum soll denn da kein > stehen? Was genau funktioniert nicht, wenn da > steht? Was ist das Problem, für das das Ersetzen von > die Lösung sein soll? Oder ist das eine Knobelaufgabe ohne tieferen Sinn?

Ja, machen wir. Nö, machst du nicht.

Die Kompetenz der Forenbenutzer hier in Frage zu stellen, scheint ein Hobby von dir zu sein. Nein, ist es nicht. Bommesdieder hat ein Problem X, und glaubt, dass Vorgehensweise Y dieses Problem löst. Er fragt hier, wie er Y bewerkstelligt, verschweigt aber, was X ist. Daher besteht die Möglichkeit, dass Y völlig ungeeignet ist, um X zu lösen. Ob das der Fall ist, können wir aber erst sagen, wenn er sagt, was X ist. Faustregel: Beschreib das Problem, nicht, was du für die Lösung hältst. Das heißt, deine "kompetente" Antwort wäre "Geht nicht" und fertig?

Geh bitte mal einen Schritt zurück: Welches Problem hoffst du damit zu lösen?

Überschreibe OnCtlColor in deiner Dialogklasse.

Was genau hast du denn vor? Willst du einmal beim Start eine andere Farbe festlegen, oder willst du zur Laufzeit die Farbe wechseln? Und was für eine Art Fenster hast du? Dialog oder nicht?

Der Code ist Unsinn. SetWindowLong und GCL_HBRBACKGROUND passen nicht zusammen. GCL_HBRBACKGROUND ist für SetClassLong, ändert also die Eigenschaften einer Fensterklasse, nicht eines einzelnen Fensters.

Du bist arrogant, weil du völlig überzeugt bist, dass der Fehler beim Compiler liegt und nicht bei dir, weil du meinst, über den Hersteller herziehen zu müssen, und weil du die hier angebotene Hilfe als inkompetent bezeichnest. Beratungsresistent bist du, weil du es trotz vielfacher Aufforderung immer noch nicht geschafft hast, die Fehlermeldung zu posten. Wenn in deinem nächsten Beitrag nicht die Fehlermeldung steht, mache ich den Thread zu, denn das führt zu nichts.