Klotzkopp

Du musst die kleinste der drei Geschwindigkeiten zum Ausrechnen der Dauer benutzen. Da ändert sich an der Rechnung gar nichts.

Der vom Objekt verwaltete Speicher liegt nicht auf dem Stack, egal wo du es anlegst. Kann auch gar nicht, weil die Größe von Stackvariablen zur Compilezeit feststeht. Lass dir mal sizeof(Bitmap) ausgeben, dann siehst du, wieviel Stackspeicher das verbraucht. Die Klasse selbst legt den Speicher für die Daten auf dem Heap an. Hat er auch, der Code tut nur nicht das, was du erwartest. Der wundersame Komma-Operator wertet seine Operanden aus und gibt den rechten zurück. Du hast da ein new ohne delete -> Leak. Vermutet oder geprüft? Soweit ich weiß, kopiert GetHBITMAP die Bilddaten.

Hörbar sind elektromagnetische Wellen niemals, egal welche Frequenz. Was du meinst, sind Schallwellen.

Sie wäre unvollständig. Die USB-Übertragungsgeschwindigkeit stellt eine obere Grenze dar. Die Lesegeschwindigkeit von Platte A und die Schreibgeschwindigkeit von Platte B allerdings auch. Die niedrigste dieser drei bestimmt die Dauer.

Using-Direktiven sollten nicht im Header stehen. Abgesehen davon, dass du es ohne Grund mit new anlegst, zeigt dieses Handle niemals auf eine tatsächlich existierende GDI-Palette. Wozu ist das überhaupt drin? Wozu dieser bool und Release()? Warum macht das nicht einfach der Destruktor? wird geleakt. Warum überhaupt mit new, und nicht auf dem Stack? Damit gibst du nur palette frei. Der delete-operator bindet stärker als der Kommaoperator. Wenn es andersherum wäre, würde übrigens nur bmp freigegeben. Du kommst nicht drumherum, zweimal delete zu schreiben. Warum new? Ganz allgemein ist in C++ jedes new, das nicht sofort in einem Smartpointer landet, verdächtig.

Mein Eindruck ist, dass das Testmethoden sind, die im Fall des Fehlschlags detaillierte Fehlerinformationen liefern. Wenn das Ziel wirklich ist, grundsätzlich alle aufzurufen, auch wenn eine fehlschlägt (und man wirklich nur die Fehlerinformationen vom ersten Fehlschlag haben will), kommt man mit Exceptions nicht weit.

Ich würde da eine LastError-Klasse basteln, die die Rückgabewerte entgegennimmt, sich den letzten von null verschiedenen merkt und zurückgeben kann.

Das sind Linkerfehler, also ist der Compiler schon mal zufrieden. Die Ursache ist, dass du die GDI+-Bibliothek nicht dazugelinkt hast. GDI+ ist ein C++-API. Es verwendet Klassen, kann also mit C gar nicht genutzt werden. Da ich allerdings das ref in deinem Code sehe: Verwendest du das mit C++/CLI?

Hast du irgendwo WIN32_LEAN_AND_MEAN definiert? Falls ja, wirf das raus.

Verrätst du uns ein paar von den 204, oder muss ich die Kristallkugel rausholen?

Ich hab mal nach einem Bespiel gesucht. Da steht #include <windows.h> ganz am Anfang. "Überall" stimmt also schon mal nicht.

Zumindest behauptet das die Doku: Image.FromHbitmap Method (IntPtr) (System.Drawing) Ok, das war missverständlich formuliert. Mit "direkt" meinte ich nicht innerhalb deiner C++-Funktion, sondern direkt aus .NET, ohne den Umweg über einen Wrapper. Der richtige Zeitpunkt dafür wäre nach FromHBitmap.

Das Handle wird dort erstellt. Die Bitmapdaten befinden sich nicht auf dem Stack. FromHBitmap kopiert die Bilddaten, das Image-Objekt enthält danach keinen Verweis auf die GDI-Bilddaten. Wenn du Dispose aufrufst, wird die Kopie freigegeben, die FromHBitmap erzeugt hat. Da kein Verweis auf die ursprünglichen Daten besteht, kann auch nicht mehr passieren. Warum rufst du nicht direkt DeleteObject auf?

Weder noch. Von 33 bis 159.

Vermutlich soll diese Schreibweise ermöglichen, dass man den Minimal- und Maximalwert direkt ablesen kann, aber wie man an den Ergebnissen sieht, hat das nicht ganz geklappt. Das wäre besser: (int)((126-34+1)*random()+34)Dasselbe Ergebnis, aber die Randwerte stehen direkt im Code.

Die runde Klammer in der Intervallschreibweise bedeutet, dass diese Grenze nicht dazugehört. [34, 127) heißt also, eine Zahl >= 34 und < 127. Die 127 selbst gehört also nicht dazu. Die höchste Zahl, die dabei auftreten kann, ist irgendwas in der Art von 126,999999. Beim Cast auf int wird der nicht-ganzzahlige Anteil (also die Nachkommastellen) abgeschnitten, also kommt als höchstmögliches Ergebnis 126 heraus.

random() // Zahl aus dem Intervall [0,1) (126-33)*random() // Zahl aus dem Intervall [0, 93) (126-33)*random()+33+1 // Zahl aus dem Intervall [34, 127) (int)((126-33)*random()+33+1) // ganze Zahl zwischen 34 und 126 (einschließlich)[/code]

Lös dich doch mal von der Annahme, dass die Funktion eine ganze Zahl zurückgibt

Stimmt die Aufrufkonvention überein?

Du brauchst keine weiteren Handles. Die Benennung des Handles des Vorgängers mit "ende" ist nur sehr ungewöhnlich und verwirrend. Bei diesem Namen würde man erwarten, dass das Handle eben auf das Listenende verweist, nicht auf das jeweilige Vorgängerelement. Der "übliche" Name dafür wäre prev (als Gegenstück zu next).

Die saubere Lösung wäre, das Programm zu teilen: Der Dienst prüft die Datenbank, und ein Anwenderprogramm, das sich mit dem Dienst verbindet, zeigt die Meldung an.

Ja, wenn man seinen Domänennamen dadurch verbrennt, dass man nur durch Spam und nicht durch Leistung auffällt, muss man sich solche URLs zulegen. Traurig.

Ein oder mehrere Trennzeichen am Anfang werden übersprungen. strtok würde also beim ersten Aufruf "Hermann" zurückgeben. Ich würde dir empfehlen, nicht strtok zu benutzen. Diese Funktion hat ein paar unangenehme Eigenschaften, wie z.B. dass sie den verarbeiteten String verändert und nicht ablaufinvariant ist.

Der Fehler liegt nicht an strtok, sondern daran, was du mit dem Rückgabewert machst. strtok hat die Eigenschaft, Trennzeichenwiederholungen zu überspringen. Wenn du das nicht willst, solltest du den String nicht so zusammensetzen oder nicht strtok benutzen.

Vermutlich ist j an dieser Stelle dann bereits größer als 7. Leider fehlt im gezeigten Code die Initialisierung von j, und auch der Wertebereich von wTag wäre interessant.