Klotzkopp

Naja, ganz so trivial ist der Unterschied nicht. Der Interpreter muss nur den gerade aktuellen Code ausführen und den Status vorhalten, der Compiler muss etwas erstellen, das später auch ohne ihn selbst läuft. Du schreibst den Compiler, führst ihn mit dem Interpreter aus und lässt ihn seinen eigenen Quellcode verarbeiten. Ein Compiler kann sich nicht aus dem eigenen Quellcode selbst erzeugen. Dazu brauchst du immer ein anderes Programm, sei es eine ältere Version oder ein Übersetzungsprogramm für eine andere Sprache - in deinem Basic-Compiler-Beispiel eben einen Basic-Interpreter. Am Anfang steht immer ein in Maschinensprache geschriebenes Programm, vermutlich ein Assembler. Und darauf wird dann aufgebaut.

Dass man den Befehlssatz kennt, bedeutet aber nicht, dass man den Schadcode in einem Compiler entdecken kann, indem man den Assemblercode prüft. Dazu gehört nun doch etwas mehr. Und die Größe des Befehlssatzes hat nichts mit der Rechenleistung zu tun. Was den Schutz vor einem "verseuchten" Compiler angeht, ist da IMHO weder die Größe des Befehlssatzes noch die Rechenleistung relevant. Man schützt sich, indem man Programme nur aus zuverlässigen Quellen bezieht.

Man kann einen Compiler nur dann mit sich selbst kompilieren, wenn man ihn vorher mit einem anderen Compiler kompiliert hat. Wenn man beispielsweise neue Optimierungen zu einem Compiler hinzugefügt hat, muss man ihn zweimal kompilieren (einmal mit der alten, dann nochmal mit der dabei gebauten neuen Version), um eine optimierte Version des neuen Compilers zu erhalten. Vielleicht ist das damit gemeint. Ich sehe nicht, was das mit der Rechenleistung zu tun hat. Üblicherweise schütz man sich vor Manipulation, indem man den Compiler als signiertes Binärpaket von einer vertrauenswürdigen Quelle bezieht.

Die Jahreszeiten hängen nur von der Neigung der Erdachse zu ihrer Umlaufbahn um die Sonne ab. Wenn du nur die Entfernung änderst, wird sich daran nichts ändern, es wird eben nur global wärmer oder kälter. Das wiederum kann natürlich massive Auswirkungen auf globale und lokale Wetterphänomene und damit auch auf die Jahreszeiten haben. Aber man kann nicht pauschal sagen: Ist die Erde weiter von der Sonne entfernt, werden die Jahreszeiten stärker oder schwächer. Will man solche Aussagen, muss man das ganze schon etwas differenzierter betrachten, und die Auswirkungen werden auch nicht überall auf der Erde gleich sein. Es soll ja Gegenden auf der Erde geben, die gar keine Jahreszeiten haben, wie wir sie kennen

Das sieht man auch aus dem Code. Die Frage ist, wie soll der String hinterher aussehen? Willst du "102"? Willst du "0x66"? Willst du "f" (ASCII 102)? Willst du einen String mit 102 Leerzeichen? Der Code macht ersteres. Wenn das ist, was du willst: Prima

Was heißt OK für dich? Syntaktisch ist das in Ordnung. _bstr_t hat einen Konstruktor für _variant_t, und _variant_t wiederum einen für long. Der Code wird also etwas tun. Ob das das ist, was du willst, kann niemand sagen, weil du das nicht verraten hast.

Wie wär's mit "Roentgenstrahlung"?

Stichwort: Bucketsort.

Das ist sehr allgemein formuliert. Der Jahreszeiten-Artikel bei Wikipedia ist da etwas deutlicher. Nein, eigentlich nicht. Die Jahreszeiten werden ja nicht durch die schwankende Entfernung zur Sonne verursacht.

Was sind denn "hoch 3"-Gesetze? Glaubst du, alles, was mit Körpern zu tun hat, muss irgendwo ein 3 im Exponenten haben? Da muss ich dich enttäuschen. Wenn die Erde eine der Sonne zugewandte Scheibe wäre, würde sie dieselbe Menge an Strahlungsenergie abbekommen. Alle Punkte, die dieselbe Entfernung von der Sonne haben, bilden eine Fläche (vereinfacht eine Kugeloberfläche). Diese Fläche bekommt, unabhängig von der Entfernung, die gesamte Strahlung ab. Die Größe dieser Fläche steigt mit dem Quadrat der Entfernung. Relevant für die Strahlung ist nur die Projektion der Erde auf diese Fläche, die bestimmt den Anteil der Strahlung, die die Erde trifft.

Die ankommende Strahlungsenergie hängt vom Quadrat der Entfernung ab. 10% Änderung bei der Entfernung entsprechen also 21% bei der Energie.

CreateActCtx ist in kernel32.dll, aber erst ab Windows XP und Server 2003. Möglicherweise wurde da irgendeine Software falsch aktualisiert.

Getting the System Version

Warum musst du überhaupt im Internet nach einer Anleitung suchen? Ist nicht genau das Bestandteil des Unterrichts in diesem Fach gewesen? Zu 1: Konstruktion eines Automaten aus einem regulären Ausdruck Zu 2: Potenzmengenkonstruktion - Wikipedia

Der zweite Parameter von substr bestimmt aber die Anzahl der Zeichen, nicht die Endposition. Deshalb kann man da den Rückgabewert von find nicht direkt verwenden.

Ich würde zuerst die Jahre vergleichen. Ist die Differenz ungleich 18, ist der Fall klar. Bei 18 muss man eben noch Monat und Tag vergleichen. In etwa so (Pseudocode): bool aelterals18( datum, heute ) { if( heute.jahr - datum.jahr != 18 ) { return heute.jahr - datum.jahr > 18; } if( heute.monat != datum.monat ) { return heute.monat > datum.monat; } if( heute.tag != datum.tag ) { return heute.tag > datum.tag; } cout << "Herzlichen Glückwunsch!"; return true; }[/code]

unsigned char b[4] = { 107, 251, 179, 175 }; ostringstream st; st << hex << setfill('0'); for( int i=0; i<4; ++i ) { st << setw(2) << static_cast<unsigned int>( b[i] ); } string s = st.str();[/code] Der Cast nach unsigned int ist notwendig, weil unsigned char für die Ausgabe normalerweise als Zeichen interpretiert wird. Das wollen wir hier aber nicht.

Du kannst ein Array von Bytes nicht "als Hex" zurückbekommen! "Hex" ist eine Darstellungsart! Byte-Arrays tragen diese Eigenschaft nicht in sich. Sie kommt erst zum Tragen, wenn du die Bytes anzeigst oder ausgibst. Mal ein Vergleich: Wenn dir dein Gehalt überwiesen wird, bekommst du das in großen oder kleinen Scheinen? Weder noch, in welcher Form du das Geld später in den Händen hältst, hängt davon ab, was dir der Automat ausspuckt. Das ist keine Eigenschaft, die das dir überwiesene Gehalt in sich trägt. Genauso ist es mit binär und hex bei Zahlenwerten. Erst wenn du einen Wert darstellst (ausgibst, als Text speicherst), ist das relevant. Vorher ist diese Eigenschaft nicht vorhanden. Deswegen kannst du Zahlenwerte nicht "als Hex" zurückbekommen, genauso, wie dir dein Gehalt nicht in 10-Euro-Scheinen überwiesen werden kann. Ich hoffe, das ist jetzt klar geworden. In welcher Form? Kennst du die Werte, die dabei herauskommen sollen, zumindest ungefähr? Zeig doch mal 4 Beispielbytes.

Als binär oder dual bezeichnet man die Darstellung einer Zahl im System zur Basis 2, also nur mit den Ziffern 1 und 0. Hexadezimal (eigentlich: sedezimal) ist die Darstellung eines Wertes im System zur Basis 16. Wichtig ist, dass beides Darstellungen, also textuelle Repräsentationen von Werten sind. Ein und derselbe Wert hat mehrere Darstellungen, je nachdem, welches System man benutzt. Man spricht übrigens auch von binär, wenn man von Daten redet, die nicht als Text interpretierbar sind. Das eine hat aber mit dem anderen nichts zu tun. Der Wert ist zu groß für ein Byte. Kann es sein, dass du ein Array von Bytes hast, oder einen Zeiger? Ein paar mehr Details wären hier hilfreich. Der Wert liegt außerhalb des Bereichs der ASCII-Codierung, die geht nur bis 127. Ich glaube aber, das ist gar nicht, was du willst. Du willst wahrscheinlich einen String, der die hexadezimale Darstellung des Wertes enthält, der sich ergibt, wenn man 4 im Speicher hintereinander liegende Byte-Werte als einen 32-Bit-Wert interpretiert. Stimmt's? Da wäre aber vorher noch zu klären, ob die Bytes in Little- oder Big-Endian-Reihenfolge vorliegen, also ob das erste Byte das mit der niedrigsten oder höchsten Wertigkeit ist.

Flags sollte man nicht addieren, sondern mit dem bitweise-oder-Operator zusammenfügen: TVIF_PARAM | TVIF_TEXT

Hast du etwa TVIF_TEXT entfernt? Du brauchst schon beide Flags.

Es reicht nicht, einfach nur lParam einen Wert zuzuweisen. Du musst zusätzlich bei mask TVIF_PARAM angeben.

Das geht sogar ohne getString()-Methode: Du musst nur einen Ausgabeoperator für deine Klasse schreiben: std::ostream& operator<<(std::ostream& stream, const Vector2D& v ) { stream << '(' << v.x() << ',' << v.y() << ')'; return stream; }[/code] Dann kannst du deine Objekte einfach so ausgeben: [code]cout << "vector1=" << vector1 << " in cm" << endl;

Das ist keine ausreichende Fehlerbeschreibung. chiBuffer[i].Char.AsciiChar

Wie wär's mit chiBuffer.AsciiChar?