Klotzkopp

lfFaceName, da steht der Name der Schriftart drin. Ich glaube, das sollte egal sein. Versuch macht kluch.

Kaum. VS6.0 ist inzwischen fast 11 Jahre alt. Die aktuellste Version, Visual Studio 2008, ist schon fast 1 1/2 Jahre alt. Tja, funktioniert der Spaß wohl doch nicht. Mit einer aktuellen Version von Visual C++ klappt das problemlos. Selbst mit Visual C++ 2003 sollte es gehen. Wenn du nicht umsteigen kannst oder willst, könntest du es mit printf/scanf versuchen.

Oh, Steinzeitsoftware . Hat das einen bestimmten Grund? Benutz mal __int64 (zwei Unterstriche). Kein Grund für multiple Ausrufezeichen, das geht.

Die Größe der Datentypen ist in C und C++ gar nicht festgelegt. Für so ziemlich jeden aktuellen Compiler für Desktopplattformen gibt es aber eine Unterstützung für 64-Bit-Integer. Wenn du nur endlich mal verraten würdest, was du benutzt. Sagt das der Compiler? "Ist nicht möglich"? Oder kommt da vielleicht doch eine ordentliche Fehlermeldung? Diese Information ist auch ziemlich nutzlos, wenn du nicht erwähnst, welche Bibliotheken das sind, und du wieder nur "kennt er nicht" als Fehlerbeschreibung lieferst. Je genauer deine Problembeschreibung, desto gezielter die Hilfe.

Du musst für diese Aufgabe weder Strings zerstückeln noch zusammensetzen. Sowohl die Kontonummer als auch die Bankleitzahl sollten doch problemlos in einen 64-Bit-Integer passen. Wandle beide um, z.B. mit Stringstreams, und wende dann die Modulo-Rechenregeln auf deine Formel an.

Ich glaube eher, du verstehst meine Antwort nicht. Wie bereits gesagt: Nein. Du kannst auch direkt eine LOGFONT-Struktur mit den richtigen Daten füllen. Das Enumerieren dient nur dazu, dir richtig befüllte LOGFONT-Strukturen zu liefern.

Du könntest auch nur einmal enumerieren, dir merken, welche Inhalte die Logfont-Struktur für die gewünschte Schriftart hat, und dann diese Werte sofort setzen.

Nur insofern, als du CreateFontIndirect aufrufst. Du sollst dir nicht selbst eine Schriftart "ausdenken", sondern die Geräteschriftarten des Druckers enumerieren, und dann die passende in den DC selektieren.

Nein, CreateFontIndirect, wie in dem Beispiel, auf das du verlinkt hast.

Was kombinieren? Wenn du mit einer bestimmten Schriftart drucken willst, musst du sie in den Drucker-DC selektieren. http://msdn.microsoft.com/en-us/library/dd162957(VS.85).aspx

Ich sehe leider keine Frage :confused:

Man könnte eine ordentliche Fehlerbeschreibung beschaffen. Mit "lässt sich nicht ausführen" und "hat nicht geklappt" ist die Diagnose ziemlich schwierig. Da kommt doch bestimmt eine Fehlermeldung. Sag deinen Freunden, sie möchten bitte ihr antrainiertes Fehlermeldung-Wegklicken kurz unterdrücken und die Fehlermeldung abschreiben.

Das Problem dürfte sein, dass es für weite Teile der WinAPI schlicht keine "entsprechenden POSIX-Funktionen der gleichen Funktionalität" gibt. Du kannst aber bei konkreten Funktionen gern hier nachfragen.

Ich habe dich nicht als dumm hingestellt. Ich habe versucht, dir zu erklären, warum deine Herangehensweise nicht zielführend ist. Wenn du das nicht möchtest, lass ich es eben. Das ist das erst Mal, dass du mit solchen Informationen rausrückst. Wenn dieses "andere Protokoll" nicht gerade auf UDP basiert, wirst du mit Sockets sowieso nicht viel erreichen können. Wenn es UDP-basiert ist, versuchst du dir gerade Wissen zu Stream-Sockets anzueignen, obwohl du hinterher Datagram-Sockets benutzen musst. Du kannst aus einem Programm, das Problem A löst, nicht sonderlich viel darüber lernen, wie man Problem B löst. In so manchem Fall liegt das an Beratungsresistenz oder ausgeprägter Dünnhäutigkeit. Du machst aber doch noch gar nichts. Du kannst dir jetzt natürlich lang und breit darüber Gedanken machen, wie du Daten am besten verarbeitest, die gar nicht verarbeitet werden müssen, weil es sich um einen reinen Geschwindigkeit- oder Lasttest handelt. Erwarte aber bitte nicht, dass du dabei etwas lernst, das du auf ein Protokoll mit echtem Kontext übertragen könntest.

Beide Varianten funktionieren nur für x > 0. So könnte man es auch machen: int digit_count( int x ) { static const int table[] = { 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000 }; return std::upper_bound( table, table + 9, abs(x) ) - table + 1; } [/code] Das klappt so allerdings nur, wenn int höchstens 32 Bit hat. Man könnte die Tabelle aber auf 64 Bit erweitern.

Bevor jetzt hier einzelne DLLs runtergeladen werden: Downloaddetails: Visual C++*2008 Redistributable Package (x86) Die Laufzeitumgebung statisch zu linken, sollte auch helfen.

Eine fertige Funktion gibt's nicht, du musst das ausprogrammieren. Weitere Vorschläge: Pragmatisch: Mitzählen, wie oft du durch 10 teilen musst, bis 0 herauskommt. Simpel, aber verschwenderisch: In einen String umwandeln und dessen Länge ermitteln. Performant: Binäre Suche in einer Lookup-Tabelle.

Bitte ein Thema nur in einem Unterforum posten, siehe Boardregeln. Hier geht's weiter: http://forum.fachinformatiker.de/c-c/127024-problem-vererbung-klassen.html -> Thread geschlossen.

Ein Programm, das zur Messung der Übertragungsgeschwindigkeit dient, ist so ziemlich der einzige Anwendungsfall, wo der eigentliche Inhalt der Daten egal ist. Es geht darum, dass dein Programm keinen Sinn hat, wenn man mal von der Geschwindigkeitsmessung absieht. Die Datenübertragung erfüllt keinen Zweck, also ist es auch sinnlos, sich über die richtige Verarbeitung dieser Daten Gedanken zu machen. Das hast du aber nicht gemessen. Du hast nur gemessen, was send tut: Die Daten beim Betriebsystem abliefern. Es gibt keinen "tatsächlichen" oder "realen" Wert. Es gibt nur Durchschnittswerte, und die hängen davon ab, auf welcher Ebene und mit welchem Intervall du misst. Wie gesagt, "reale" Werte gibt's sowieso nicht, weil die Daten nicht kontinuierlich übertragen werden. Wenn du die Werte "schönrechnen" möchtest, mach das Messintervall größer.

Indem sie die bisher übertragene Datenmenge durch die verstrichene Zeit teilen. Datenübertragungsraten sind immer Durchschnittswerte über bestimmte Zeitspannen. Das hat nichts damit zu tun, wie deine Empfangsfunktion aussieht. Wer sind denn "die"? Nur weil das Protokoll nicht sofort offensichtlich ist, heißt das nicht, dass da "irgendwas" gesendet wird. Es gibt nicht die einzig wahre Art und Weise, einen Netzwerkclient zu implementieren. Es kommt auf das Protokoll an. Üblicherweise trennt man die Datenübertragung von der Verarbeitung, und implementiert einen endlichen Automaten. Solange nicht klar ist, was du eigentlich machen willst, ist es nicht sinnvoll, sich darüber Gedanken zu machen, wie du es machst.

Aber auch nur deshalb, weil du bei Auslaufen des Timeouts den Empfang abbrichst. Das ist beim Empfangen eher unüblich. Normalerweise hat man aber auch irgendein Protokoll in dem Bytestrom, so dass man anhand der Daten selbst erkennen kann, wann Schluss ist. Innerhalb dieses Protokolls mag es dann Zustände geben, bei denen innerhalb einer bestimmten Zeit Daten empfangen werden müssen. Aber wenn man einfach nur auf Daten wartet, ist diese Vorgehensweise merkwürdig. Was heißt denn "wegmachen"? Wenn du hier nicht select benutzt, und einfach nur recv aufrufst, wartet das eben, bis Daten da sind. Das hat mit einer Zeitmessung recht wenig zu tun. Das ist wieder so eine Reifenfrage. Klar kann man fork in Clients anwenden. Die Frage ist, ob und wann das sinnvoll ist. fork dupliziert den aufrufenden Prozess, d.h. du hast danach 2 Clients. Was in deinem Fall totaler Blödsinn wäre. Ich würde dir raten, dir ein Client/Server-Beispiel zu suchen, das auch einen Sinn hat. Einfach nur sinnlose Daten an einen Server zu senden, der dieselben Daten wieder zurückschickt, ist nicht gerade praxisrelevant, denn damit sind sowohl Client und Server als auch die Kommunikation zwischen ihnen zustandslos.

Du wolltest wahrscheinlich nicht die Funktion SetDlgItemInt benutzen, sondern die Methode CWnd::SetDlgItemInt, die hat nur drei Parameter, weil sich das Dialoghandle aus dem this-Zeiger der Instanz ergibt. Diese Methode darfst du allerdings nur aus dem Thread aufrufen, der das Fenster auch erstellt hat. Das gilt für alle CWnd-Methoden. An ein Handle für die Funktion SetDlgItemInt kommst du über die m_hWnd-Membervariable deines Dialogs. Und weil das nichts mit Standard-C++ zu tun hat: Verschoben -> C++: Compiler, IDEs, APIs

NetworkStream.BeginRead Method (System.Net.Sockets)

Ich weiß nicht, wie du die "Größe" einer Schleife bemisst, aber das ist zunächst mal Unsinn. Schon wieder diese "große Schleife". Dass dein Programm die CPU auslastet, ist nicht verständlich. Welcher Thread erzeugt denn die hohe Last? Tritt das Problem auch auf, wenn du den Receive-Thread nicht startest? Das hier ist zumindest ungewöhnlich: while ((bytes < frameSize)) { bytes = send(client, cBuffer, frameSize, 0); [/code]Wenn send irgendwann einmal nicht alle Bytes auf einmal loswird, schickst du den gesamten Puffer nochmal. Normalerweise würde man nur den nicht versendeten Teil der Daten nochmals abschicken.

Dann benutz den Debugger. Dafür ist er da. Dieser "blöde Spruch" sollte verdeutlichen, dass die Antwort auf deine Frage dich nicht weiterbringt. Die Frage, ob Winterreifen oder nicht ist sicherlich wichtig, aber sie bringt dich nicht weiter, wenn dein Auto nicht anspringt. Die Antwort auf diese Frage ist aber nicht unabhängig von deinem Code. Wenn grundsätzlich eine Funktion "besser" wäre als die andere, hätte die andere keine Daseinsberechtigung. Auch hier: Sind Winterreifen oder Sommerreifen besser? Das soll kein "blöder Spruch" sein, sondern dir klarmachen, dass manche Fragen ohne Kontext nicht beantwortet werden können. Asynchrone Funktionen und Threads sind zwei Mechanismen dafür, dass ein Programm weiterlaufen kann (z.B. auf Benutzereingaben reagieren), während es auf etwas anderes wartet. Beides zu benutzen, klingt erst mal seltsam. Aber wie gesagt, ohne genauere Informationen über den Zweck und Aufbau deines Programms kann man das nicht beantworten.