Klotzkopp

Nein. Windows räumt auf, wenn ein Prozess beendet wird, d.h. belegter Heap- und Freestorespeicher wird freigegeben, offene Handles werden geschlossen, geladene DLLs entladen (wenn kein anderer Prozess darauf zugreift) usw. Dabei ist es egal, ob der Prozess normal terminiert hat, durch Abbrechen des Debuggers "abgewürgt" oder durch den Taskmanager, eine API-Funktion oder eine unbehandelte Ausnahme "abgeschossen" wurde.

Das Betriebssystem kümmert sich darum, hinter einem beendeten Prozess aufzuräumen. Das passiert unabhängig davon, wie der Prozess beendet wurde, normal oder durch Beenden des Debuggers.

Das sind aber zwei Hauptsätze, also muss da ein Komma hin (alt) bzw. es ist dem Schreiber überlassen (neu). Oder sollten meine Grammatikkenntnisse mich trügen? :confused:

Hier bei mir zumindest nicht.

Ein einfacher Vergleich der Audiodaten reicht da auf keinen Fall. Du musst auch Abweichungen in der Tonhöhe oder Sprechgeschwindigkeit zulassen, was sich in einer Verschiebung des Spektrums oder in einem geänderten zeitlichen Verlauf auswirkt. Das könnte interessant sein: http://www.spracherkennung.de

Willst du die digitalen Informationen vergleichen, oder willst du herausfinden, ob die beiden Dateien sich für den Menschen "ähnlich" anhören? In letzterem Fall solltest du die Frequenzspektren vergleich. Stichwort Fourier-Transformation.

Nein, das ist kein Problem, nur solltest du diese Methoden ausschließlich über CClose::getInstance()->MethodenName() aufrufen. Zur Sicherheit empfehle ich, den CTor private zu machen, damit die nur die Klasse selbst in der statischen Methode die Instanz erstellen kann.

Neben jedem deiner Beiträge? Da steht glaub ich "Registriert seit...".

Nein, alle Threads eines Prozesses teilen sich den Adressraum. Ich denke, hier ist das Problem. CClose::getInstance ist statisch (sonst könntest du es im Format-Aufruf nicht so benutzen). Es macht also hier keinen Sinn, eine neue Instanz von CClose zu erstellen. Das widerspricht ja auch dem Sinn eines Singleton. Üblicherweise sind Singletons so implementiert, dass getInstance die Singleton-Instanz erstellt, wenn das noch nicht passiert ist, ansonsten wird einfach ein Zeiger oder eine Referenz auf die Instanz zurückgegeben. Du brauchst also kein CClose-Objekt anzulegen.

Ehrlich gesagt, ich verstehe nicht, was du willst. Ich wüsste nicht, warum der Zugriff auf ein Singleton vom Threadkontext abhängen sollte, und was das mit Namespaces zu tun hat. Kannst du das etwas genauer erläutern oder ein Minimal-Codebeispiel posten?

Also in meiner MSDN Library steht: Unicode: Implemented as Unicode and ANSI versions. Laut MSDN Library soll als letzter Parameter die Adresse einer Variablen übergeben werden. Es wäre also wohl gut, wenn dieser Zeiger auf eine gültige DWORD-Variable zeigen würde, und nicht irgendwohin, wie das ein uninitialisierter Zeiger nun mal tut. Du solltest auch den Rückgabewert der Funktionen prüfen.

Die DLL bietet zwei Versionen dieser Funktion an, eine für ANSI und eine für UNICODE. Die Namen sind WTSOpenServerA bzw. WTSOpenServerW. Den Typ des Parameters musst du dann entsprechend auf LPSTR bzw. LPWSTR ändern. So etwas kannst du mit Depends oder einem ähnlichen Tool leicht selbst herausfinden. Und da das ganze nichs mit Standard-C++ zu tun hat: --> Verschoben.

CAsyncSocket::GetPeerName liefert WSAENOTCONN, wenn der Socket nicht verbunden ist.

Wenn dein Dialog schon einen Defaultbutton hat, wird der ausgelöst, wenn du Enter drückst. Dadurch verliert dein Eingabefeld den Fokus, was du über die Nachricht WM_KILLFOCUS mitbekommst. Falls dein Dialog keinen Defaultbutton hat, mach einfach einen drauf und mach ihn unsichtbar.

Nein, denn da LPCTSTR keine Klasse, sondern nur ein typedef eines Zeiger ist, wird das schiefgehen.

Hint: Es gibt hier ganz in der Nähe ein Forum, das steht sogar "API" drin. Ich schieb dich da mal hin.... Ach ja: http://msdn.microsoft.com/library/en-us/dhcp/dhcp/dhcp_server_api.asp http://msdn.microsoft.com/library/en-us/dhcp/dhcp/dhcp_server_management_api.asp

Die Frage lässt sich so nicht beantworten, aber es sind mit Sicherheit mehr als drei Ctor-Aufrufe. Die ersten beiden Aufrufe bewirken jeweils einen Aufruf, der dritte mindestens zwei. Auf jeden Fall wird eine temporäre Bruch-Instanz erzeugt, um den Rückgabewert des operator* aufzunehmen. Diese temporäre Instanz wird an den Copy-Ctor von Bruch übergeben, um c zu initialisieren. Das sind zusammen schonmal vier Aufrufe. Dazu können noch die Ctor-Aufrufe für weitere temporäre Instanzen kommen. Wie viele das sind, hängt davon ab, wie operator* implementiert ist, und ob der Compiler z.B. "named return value optimization" durchführt. Siehe auch: Exceptional C++, Item 42

Vielleicht solltest du so was demnächst vorher erwähnen, damit ersparst du Anderen unnötige Arbeit. Schreib doch eine Mail an den Freecom-Support.

www.freecom.de -> Treiber -> Ältere Serien -> Power CD

InitInstance (als überschriebene Memberfunktion einer von CWinApp abgeleiteten Klasse) gibt es nur bei MFC-Anwendungen. Die Prüfung muss auch nicht dort erfolgen. Es ist nur sinnvoll, weil man das Programm einfach und sicher beenden kann, indem man FALSE zurückgibt.

Ich bin mir auch ziemlich sicher, dass es nicht geht.

Jaja. Ich hätte den ersten Thread mit diesem Rätsel raussuchen sollen.

:mod: http://forum.fachinformatiker.de/showthread.php?s=&threadid=22510