Klotzkopp

PATCH

Ja, ich kann sehen, was es ist. Ich fragte, was du machen willst. Muss ja nicht dasselbe sein

Schön. Wenn du jetzt noch meine Frage beantwortest, weiß ich auch, wohin ich deine Threads schieben muss

Ja dann setz doch die Klassendefinition vor main. Willst du eigentlich C++ machen, oder C++/CLI?

Richtig. Aber im Verlauf der ersten Heap-Erstellung sind A und E niemals in einer Nachfolger-Beziehung. Warum sollten sie also vertauscht werden? Die Heap-Erstellung ist nur ein Teilschritt, der mehrfach durchgeführt werden muss, um das Array zu sortieren. Wenn der Heap erstellt wurde, steht das größte Element ganz vorn. Dann wird durch Vertauschen ein Element aus der untersten Ebene des Heaps an die Wurzel geholt und muss neu versickert werden. Und das kann durchaus mehrfach dasselbe sein.

Deserialisiert du denn wieder in einen String? Ich glaube nicht, dass das für binäre Daten der richtige Typ ist.

In welchem Kontext steht dieser Code denn? Was steht drumherum? Bei solchen Ratschlägen bitte auch immer eine Begründung mitliefern. Und wenn es nur eine persönliche Vorliebe ist.

Ich vermute, die Frage ist hier nicht C++ oder Microsoft Visual C++, sondern C++ oder C++/CLI, was zwei unterschiedliche Sprachen sind. Was benutzt du denn jetzt genau?

Wir sind hier aber in .NET Foo^ fooInstance = gcnew Foo("bar");

Das sieht doch schon ganz gut aus. Ich hätte den Instanzzeiger als static-Member umgesetzt, aber so geht es auch. Allerdings solltest du dir nochmal klarmachen, was static bewirkt, wenn es nicht innerhalb einer Klasse oder Funktion steht. Du hast Obj01_WriteInLogFile als static (auf Dateiebene) deklariert. Dadurch hat jede Übersetzungseinheit ( = .cpp-Datei), in der diese Deklaration auftaucht, eine eigene Variable Obj01_WriteInLogFile. Es gibt also ein Obj01_WriteInLogFile für Object.cpp, und eins für LogErrorDlg.cpp, und diese beiden haben nichts miteinander zu tun. Wenn du also in LogErrorDlg.cpp den Funktionszeiger setzt, ist der in Object.cpp immer noch NULL. Du musst Obj01_WriteInLogFile in Object.h nicht als static, sondern als extern deklarieren, und dann noch in Object.cpp ohne irgendeinen Speicherklassenspezifizierer definieren.

Was heißt denn "anders"? Wie sieht 0xff0000 aus? Rot oder Blau? Es könnte sein, dass die Codierung einfach nicht RGB, sondern BGR ist.

Wieviele Instanzen deiner Klasse existieren denn gleichzeitig? Spricht etwas dagegen, einen statischen Instanzzeiger zu benutzen, über den du dann in der statischen Methode an die Instanz herankommst? Wenn dieses "Objekt" in C geschrieben ist, kann es mit einer C++-Klassendefinition sowieso nichts anfangen.

Das wird dir nicht viel nützen, außer als Entwurfsskizze. Das Zeichnen selbst muss im Programm stattfinden. Meiner Meinung nach hast du dir mit Pong einen nicht ganz einfachen Einstieg ausgesucht. Spiele dieser Art haben einige Aspekte, die normale Programme nicht haben: Die Eigenschaft, ständig auf Benutzereingaben reagieren zu müssen, und die Eigenschaft, dass auch dann etwas passieren muss, wenn der Benutzer nichts tut. Vielleicht wäre Tic Tac Toe für den Anfang besser.

Du musst mehr Informationen liefern. Funktioniert es, wenn die Teilnehmer auf demselben Rechner laufen, oder im LAN? Sitzt einer der Teilnehmer vielleicht hinter einem NAT-Router?

Wenn du nicht genug Bytes zum Codieren hast, wird mit = aufgefüllt. Siehe auch Base64 ? Wikipedia Base64 ist keine Verschlüsselung.

char const * und const char * ist dasselbe. Etwas anderes wäre char * const.

Das bedeutet einfach, dass du diese Methode nicht definiert hast. Vermutlich hast du bei der Definition einfach das Mensch:: vergessen. Du solltest dich übrigens entscheiden, ob du bool oder den enum Mensch::GEschlecht benutzt. Dieser Mischmasch ist nicht so toll.

Nein. Kann auch gar nicht sein, weil Define-Direktiven Neues nur auf bereits Bestehendes zurückführen können. Irgendetwas muss also schon vorher da sein. Dafür brauchst du keine Define-Direktive, da tut's eine Struktur- oder Klassendefinition oder ein Typedef. Ja, kann man, aber glaub mir, das willst du nicht. Präprozessormakros können wie Funktionen eine Parameterliste haben, wobei die Parameter natürlich nur Namen und keine Typen haben. Im Rumpf des Makros kann dann auf diese Parameter Bezug genommen werden. Siehe das a in Crushs Beispiel. Am Besten gar nicht. Das geht zwar mit Makros, aber so etwas sollte man sich nicht antun. Makros sind Dumm. Sie kennen keinen Scope, sie erlauben keine Typprüfung, man kann sie nicht überladen, sie erschweren das Debugging. Fehler in Makros sind zum Teil sehr schwer zu finden. Von seltene benötigten Ausnahmen abgesehen, gibt es nur einen einzigen Einsatzzweck von Makros in C++: Include-Guards für Headerdateien, also das #ifndef/#define/#endif-Gerüst, das Mehrfacheinbindungen desselben Headers verhindert. Von allen anderen Anwendungen von Makros sollten gerade Anfänger meiner Meinung nach die Finger lassen.

Es gibt jede Menge vorstellbarer Situationen, in denen ein Cast auf double* notwendig sein kann. Merk dir einfach, dass so ein Cast niemals notwendig ist, wenn malloc und verwandte Funktionen im Spiel sind

Bei Buttons gibt's nichts zu initialisieren. Und was soll uns dieser große Brocken Code sagen? Hast du dazu eine Frage? Dann solltest du sie stellen. Meldet der Compiler einen Fehler? Dann solltest du sagen, welcher das ist. Tut der Code nicht, was er soll? Dann solltest du sagen, was das gewünschte und das beobachtete Verhalten ist. Einfach nur kommentarlos ein Stück Code abzuladen, bringt nichts.

Nein. Die Funktion malloc gibt einen void-Zeiger zurück. Du weist das einem double-Zeiger zu. Die Umwandlung von void* nach double* ist in C implizit, das heißt, sie passiert automatisch. Die explizite Typumwandlung mit dem Cast ist daher überflüssig, weil ohne genau dasselbe passiert.

Eine fertige Lösung wird hier niemand für dich machen. Du wirst ein wenig Eigeninitiative zeigen müssen. Bei konkreten Problemen helfen wir dann gern weiter. Nachtrag: Ich bin ein wenig überrascht über den Inhalt. So etwas wird noch unterrichtet? Das ist schon mehr als ein wenig veraltet.

Ich kann's auch: sas1=[COLOR="Red"](double*)[/COLOR] malloc(22*sizeof(double)) Der rot markierte Teil ist überflüssig, und kann in ganz bestimmten Situationen sogar dafür sorgen, dass statt eines (leicht zu behebenden) Compilezeitfehlers ein unangenehmer Laufzeitfehler auftritt. Und wenn du jetzt sagst, dass dein Compiler den Code ohne diesen roten Teil nicht akzeptiert, muss ich dir antworten, dass du deinen C-Code durch einen C++-Compiler jagst

Ich glaube nicht, dass das eine gute Idee für eine Anfängerübung ist. Chat bedeutet Netzwerkprogrammierung, und das sind zunächst mal Sockets. Sockets sind C. Da gibt's keine Klassen, und du musst mit Zeigern und Puffern hantieren, es sei denn, du benutzt ein Framework wie Boost.Asio, das ist aber auch nicht gerade Anfängerstoff.

...und aus dem && ein || machen: !(A && B ) <=> !A || !B