Suchergebnisse
Suchergebnisse 1-20 von insgesamt 266.
Vorweg: ich kenne das MD2_Model-Format nicht selbst, darum kann ich nur was über die technischen Hintergründe der I/O Operationen sagen. Du wirst schon davon ausgehen können, dass es auch für die Frames einen Offset gibt, aber man muss nur dann mit fseek in der Datei herumspringen, wenn man sie nicht linear von vorne bis hinten einlesen will. Konkret: beim Lesen aus einer Datei wird ein Index verwaltet, der die aktuelle Leseposition speichert. Diesen Index kann man mit einem seek an eine andere ...
Zitat von »"unsigned long"« Du nimmst anscheinend Laxoberal? Was auch immer das jetzt ist... also nein.
Meine Devise ist da immer: "Soviel wie nötig, so wenig wie möglich." Das gilt besonders für große Projekte, in denen die Compile-Zeit ein wesentlicher Faktor ist. Außerdem ist ein Refactoring hinterher leichter, weil man einfach mal einen Header entfernen kann, ohne dass gleich alles nicht mehr compiliert. Bei kleinen Projekten, die man im Alleingang programmiert, ist das allerdings wirklich nicht so wichtig, aber früh übt sich, wer ein Meister sein will.
Hrhr, bei Threads denke ich immer etwas puristisch. Denn im Vergleich zu einem Dead-Lock ist eine Race-Condition so richtig ekelig (Originalausdruck von der Redaktion ausgetauscht ). Also: lieber gleich richtig programmieren und später nicht ärgern. Aber es stimmt schon, ein Mutex ist schon ein schweres Geschütz und sollte nicht unnütz eingesetzt werden. Speicheroperationen aus C++ (und anderen Hochsprachen) sind in der Regel übrigends nicht atomar. Das ist fast immer Load - Modify - Store = 3 O...
Hi, wenn man das richtig programmiert, funktioniert das auch mit Conditions hervorragend. C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 // Thread 1 class T1 { public: T1 () : _continue (false), _c (&m) // zu jeder Condition gehört ein Mutex { } void setContinueFlag () { _m.lock (); // Zugriff sichern. _continue = true; // Status ändern. _c.signal (); // ggf. einen Schläf...
Ich möchte hier auch noch ein paar Punkte in die Runde werfen: 1) viele Leute haben Schwierigkeiten mit Vektoren, weil sie die entweder als Punkt oder als Richtung interpretieren. Vektoren sind aber beides. Normalenvektoren fallen in die Kategorie Richtung, genau wie die Seiten deines Dreieck. 2) Eigentlich müssten Normalenvektoren "Orthogonalenvektoren" heißen, da sie prinzipiell jede Länge haben können. Wenn man sie auch noch normalisiert, wären es "Orthonormalenvektoren." Macht aber leider ke...
Zitat von »"Jonathan_Klein"« Du kannst aber mit select oder so prüfen ob ein connect Aufruf blockieren würde. Für nen "select" brauchst du schon den fertigen Socket, den du im "connect" erst bekommst. Klappt also nicht... Vorher ist der Socket noch unverbunden, und select kann gar nicht wissen, mit wem es reden soll. Wenn das Blockieren stört, kannst du den Socket vorher non-blocking machen. Dann kehrt "connect" auch sofort zurück und meldet "EWOUDBLOCK" als Ergebnis, was bedeutet, dass der Ver...
Der Ergebnisvergleich sollte vieleicht besser auf != testen und nicht auf <. Denn: false < true aber eben nicht umgekehrt.
Wenn ich das richtig in Erinnerung habe, haben Logarithmen nicht so besonders viele Schnittstellen (außer es ist zweimal die selbe Funktion). Die eine, die mir ohne lange nachzudenken einfällt ist log_b (1) = 0... und zwar für jede Basis b. Mehr gibts nicht, denn mit z.B. ln als dem natürlichen Logarithmus gilt (ohne Beweis ): log_b (x) = ln (x) / ln (b) insgesamt also: log_a (x) = log_b (x) <==> ln (x) / ln (a) = ln (x) / ln (b) <==> 0 = ln (x) / ln (b) - ln (x) / ln (a) <==> 0 = ln (x) (1 / ln...
Da für diesen Fall vermultich immer beide Applikationen auf dem selben Rechner stehen, bieten sich auch Named Pipes an.
kannst ja auch std::fill (begin, end, value) nehmen... da kommt am Ende dann auch ein ::memset bei raus, sagt jedenfalls mein Profiler. Wie auch immer der Compiler gemerkt hat, dass meine Iteratoren tatsächlich echte Zeiger sind
Ach was, du muss nur die Kreuz 5 neu anmalen, dann passt es schon
Ich wollte eigentlich nur nochmal rausstellen, dass es da immer leicht Verwirrungen gibt. Denn: wäre es eine Mitgliedsmethode gewesen, hätte er für diese Anwendung ein static gebraucht. Wenn es keine sein soll, darf sie für diese Anwendung nicht static sein.
Genau, warum so umständlich... Hier muss man auch aufpassen, weil das evtl. gar nicht das ist, was du haben willst. Einen Functor (eine Klasse, die "operator ()" definiert) könntest du hier nämlich nicht benutzen. So wie du es schreibst, ist das kein Typen-Templateparameter, sondern etwas wie ein int. Und bei diesen Konstanten gibt es einige Einschränkungen, wie z.B. "external linkage." (ich muss mir dazu mal eine verständliche Definition raussuchen, das ist nicht besonders intuitiv) C-/C++-Quel...
Eigentlich wollte ich nur sagen, dass man die Fläche gut berechnen kann, wenn man nur zwei Kreise hat, die sich wirklich schneiden. Damit kann man sich dann eine (hinreichend) exakte Lösung für Testfälle basteln Als Sonderfall im Algorithmus macht das vermutlich nicht viel Sinn, weil das bei bis zu 10000 Kreisen ein sehr seltener Randfall sein wird. Schaden kann es aber auch nicht
Die Schittfläche zweier Kreise lässt sich mit einer geschlossenen Formel berechnen: Weisstein, Eric W. "Circle-Circle Intersection." From MathWorld--A Wolfram Web Resource. http://mathworld.wolfram.com/Circle-CircleIntersection.html Damit ist der Fall einfach.
Hier mal die drei großen Testfälle, mit denen ich so rumexperimentiere: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 TestCase tc_concentric_shrink; for (int c = 0; c < 10000; ++c) tc_concentric_shrink.circles.push_back (Circle (0.0, 0.0, MAX_RADIUS - double (c) * MAX_RADIUS / 10000.0)); tc_concentric_shrink.correct_result = PI * 1.0e-4; test_cases.push_back (tc_concentric_shrink); TestCase tc_concentric_grow; for (int c = 1; c <= 10000; ++c) tc_concentric_grow.circles.p...
@grek40: ich sollte so früh nix mehr an Quelltext produzieren Aber ich glaube, es ist trotzdem klar geworden, was ich meine... :idea:
Wichtig: GetLastError gibt immer irgendwas zurück. Das muss nicht zwangsläufig ein Fehler sein, der aus dem letzten WinAPI Aufruf stammt. Wenn dieser erfolgreich war, kann der Fehler schon älter sein. Es ist nicht genau definiert, wie eine Funktion mit dem Fehlercode verfährt, wenn sie erfolgreich ist. Referenz: GetLastError - Return Code Was mir auch noch aufgefallen ist: der Fehlercode wird für deinen Fall eher aus dem SendMessageW Aufruf stammen als aus der Behandlung der WM_MDICREATE Message...
Hmm, so wie du das geschrieben hast, vergleichst du zwei Zeiger miteinander. Das ist erlaubt, aber vermutlich nicht das, was du machen willst. Sonst darfst du auch alle Objekte vergleichen, aber bei denen mit dynamisch angeforderten Zeigern drin (oder etwas allgemeiner: dynamischen Elementen), wird ohne selbst definierten Vergleich wieder nicht das gewünschte Ergebnis rauskommen. Ein kleines Beispiel: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <iostream> int *p1 = new int (...
23.04.2024, 19:49
Zum Seitenanfang
