• Du befindest Dich hier:
• Community
• »
• Mitglieder
• »
• Traumzauberbaum
• »
• Beiträge von Traumzauberbaum

Wärs nicht irgendwie cleverer die Potenzen und die Fakultät gleich mit der Schleife auszurechnen? Damit brauchst du schonmal keine Pow Funktion und die Präzesion sollte darunter nicht leiden.

potx = x;
x = x*x;
facn = 1;
sign = 1;

while(true)
{
    sin1 += sign * x / facn;
    if (n > 12 || System.Math.Abs(sinalt - sin1) < grenze)
        break;

    ++n;
    facn *= n;
    ++n;
    facn *= n;
    potx *= x;
    sign *= -1;

    sinalt = sin1;
}

Naja dafür würde sich eigentlich eine Datenbank anbieten.

Alles andere läuft darauf hinaus, dass du etwas Datenbankähnliches nachbaust (z.B. ISAM). Wird imo zu aufwändig.

Aber 5000 oder auch 100000 Dateinamen mit nem Farbwert sind eigentlich auch nicht so massig viele Daten (geschätze 10 MB). Die könntest du auch einfach in ein Dictionary/Hashtable im Speicher halten. Oder du benutzt ein DataSet zum Arbeiten, und lässt das dann serialisieren zum Speichern. Musst ja nicht bei jeder Änderung direkt auf Platte schreiben.

Prinzipiell heißt Arbeiten mit Datein Arbeiten mit Streams. Und das heißt immer alles umwälzen um eines zu ändern.

Die Nebenobjekte können aber auch einfach so mal nicht mehr gebraucht werden, weil sie ihre Funktion erfüllt haben. Und da würde dann erst gewartet werden, bis die Methode ausgelöst wird, bevor der GC sich die holen kann, weil ja im Hauptobjekt noch Referenzen darauf existieren. Es ist ja eigentlich sogar eher die Ausnahme, dass sich etwas so ändert, dass ich die Nebenobjekte abknipsen muss.

Wie gesagt, die einzige Möglichkeit die ich bei diesem Ansatz sehe ist, die Verantwortung dem Benutzer des Objekts zu übergeben. Wenn er es nicht abmeldet wird es eventuell erst viel später bis garnicht gesammelt.


Die andere Variante wäre eben eine Id mitzuführen und zu Vergleichen und die Verantwortung zum deaktivieren direkt beim Nebenobjekt lassen, statt das Hauptobjekt überhaupt erst damit zu belasten.


Und ich hab mich eigentlich gefragt ob ich vieleicht damit völlig auf dem Holzweg bin, ob es für das Problem vieleicht eine Standardlösung gibt, und wenn nichts davon welche Lösung ihr bevorzugen würdet

Ja das ist mir schon klar. Ich will ja auch nur die Nebenobjekte vom GC sammeln lassen, das Hauptobjekt ist sehr langlebig, um nicht zu sagen es wird mit Programmstart instanziert und beim Programmende beerdigt.

Vieleicht stelle ich mir das auch einfach zu umständlich vor. Vieleicht sollte ich einfach den Zugriff auf die Liste der Nebenobjekte nach außen hin zulassen. Dann ist man einfach selbst verantwortlich sein Objekt dort zu deaktivieren, wenn man es loswerden will. Und falls man das nicht tut ist es immerhin kein Leak, man kommt noch von außen ran. Ein Memory Leak zeichnet sich ja dadurch aus, dass das Objekt im Speicher (bei OOP) nicht mehr zugreifbar ist.

Wie soll das denn durch Events entkoppelt werden?

Ich könnte alle Funktionen die vom Hauptobjekt benötigt werden als Delegate übergeben, aber das ändert ja am Problem nichts.

Oder ich könnte die Nebenobjekte in ein Event vom Hauptobjekt registrieren lassen, aber auch das ändert am Problem nichts, die Nebenobjekte landen trotzdem nicht beim GC.


Der Grund warum die alle ein gemeinsames Objekt kennen ist Synchronisation mehrerer Threads. Das Hauptobjekt war vorher da und hat den Zugriff auf bestimmte Resourcen threadsicher gemacht. Die Nebenobjekte sind neu und enthalten kompilierten Code der den Zugriff auf die Resourcen performanter macht. Nur wenn sich etwas am Hauptobjekt ändert, funktioniert dieser Code nicht mehr. Das ist nicht weiter tragisch, es passiert selten und es wäre kein Problem das dann zu handhaben. Aber ich muss es handhaben können, und dazu muss ich es merken.
Ein statisches Objekt zur Synchronisation ist auch keine Lösung, denn es sollen jeweils nur Gruppen untereinander synchronisiert sein und nicht immer alle.

Ich habe ein Hauptobjekt, dass von vielen Nebenobjekten verwendet wird.
Eigentlich reicht es aus, dass die Nebenobjekte das Hauptobjekt kennen um ihre Funktion zu erfüllen.
Dieses Hauptobjekt hat aber eine Eigenschaft, die bei Änderung alle Nebenobjekte funktionsunfähig macht.

Und damit hätte ich dann den Kreis gebaut. Das Hauptobjekt müsste sich irgendwie eine Liste der Nebenobjekte merken und diese dann benachrichtigen, dass sie nutzlos sind.

Mein Problem dabei ist der GC.
Dadurch, dass das Hauptobjekt die Nebenobjekte irgendwo gespeichert hat, werden diese nicht mehr vom GC gesammelt. Ich hätte quasi trotz GC ne Möglichkeit für Memory Leaks gefunden...
Ich könnte höchstens mit IDisposable die Verantwortung für das Memory Leak an den Benutzer der Nebenobjekte übertragen. Der Anwender muss dann dafür sorgen, dass Dispose auch aufgerufen wird, wenn er speicher freigeben will. Das läuft mir aber irgendwie gegen den Sinn einer Umgebung mit GC. Dispose sollte ja eher dazu da sein Resourcen zu einem kontrollierten Zeitpunkt freizugeben, und nicht um überhaupt Resourcen freizugeben.

WeakReferences wären auch keine Lösung die mir gefallen würde. Entweder ich hab dann den MemoryLeak eben mit WeakReferences statt mit den Nebenobjekten, oder ich müsste irgendwie regelmäßig durch die Liste gehen und schauen ob ich eine WeakReference loswerden kann. Und die Regelmäßigkeit könnte ich nur garantieren, indem ich alle Befehle das ausführen lasse (schlecht) oder einen zusätzlichen Thread beauftrage das zu tun (schlechter).


Eine Alternative wäre eine Art Identifikator (z.B. GUID), der sich immer ändert wenn die Eigenschaft sich ändert. Wenn der Identifikator in den Nebenobjekten nicht mehr mit dem des Hauptobjekts übereinstimmt, wissen diese dann dass sie entwertet wurden. Es interessiert mich ja auch nicht wie sich die Eigenschaft geändert hat, sondern nur dass er sich geändert hat. Der Overhead wäre auf jeden Fall vernachlässigbar.


Was meint ihr denn dazu? Es geht hier auch nicht hauptsächlich um Performance, sondern um ein gutes Design ohne Löcher.

Vieleicht irre ich mich, aber da XNA ja nichts an der CLR ändert, müsste man doch eigentlich nur die richtigen Referenzen setzen. Sprich man kompiliert mit der .NET 2.0 CLR nur eben mit extra Bibliotheken im GAC.

Nur um das mal zu übersetzen:
\p{Ll} "Letter, Lowecase"
\p{Lu} "Letter, Uppercase"
\p{Lt} "Letter, Titlecase"
\p{Lo} "Letter, Other"
\p{Lm} "Letter, Modifier"
\p{Nd} "Number, Decimal Digit"
\p{Pc} "Punctuation, Connector"

Also alle Arten von Buchstaben, Ziffern und "Verbinder"

Also bei normalen Strings das gleiche wie [a-zA-Z_0-9], nur bei Unicode Strings sind es noch mehr. Wird nur fälschlicherweise oft (und wohl auch hier von einigen) als Buchstabe angenommen.

\w ist übrigens das gleiche wie [A-Za-z0-9\_]

Sprich alphanumerische Zeichen und Unterstrich

Würde mich ehrlich gesagt wundern, wenn man mit dem Select Befehl vom DataSet eine Tabelle löschen könnte

Na immerhin ists kein Französisch, da muss man ab 70 dann richtig rechnen

Also im Destruktor ist mit Sicherheit der falsche Platz, aber aus nem anderen Grund. Früher oder später wird der mit Sicherheit aufgerufen, aber die Frage ist viel mehr, ob sqlCon nicht schon vorher vom Garbage Collector behandelt wurde.
Das IDisposable Interface gibt es ja nicht, weil der Garbage Collector sonst die Resourcen nicht freigeben würde. Bei ner ordentlichen Implementation der Klasse sollte das zumindest nicht so sein. IDisposable gibt es um den Zeitpunkt der Freigabe zu kontrollieren.
Also nicht ob, sondern wann.

Die Regel lautet ja: im Destruktor (Finalizer) nicht auf managed Resources zugreifen!
Oder anders: der Garbage Collector garantiert nicht die Reihenfolge in der verlorene Objekte gelöscht werden.

Das bedeutet aber im Umkehrschluss nicht, dass der Garbage Collector keine Resourcen freigibt...

Das Close sollte im Dispose von MyClass kommen, oder in vergleichbaren Methoden, aber nie im Destruktor.

Naja, ich finde gerade das Beispiel Linux zeigt doch sehr deutlich, dass man die Zahl der Zeitschriften nicht überbewerten sollte.

Und für den Privatanwender ist kostenlose Software vieleicht toll, aber für Firmen ist sie oft sogar teurer...

Ohne Interface nicht zu empfehlen, weil man sonst im Prinzip die Polymorphie aufgibt.

Irgendwie fällts schwer sich bei dem Userbild auf die Frage zu konzentrieren

Wie war die gleich? Achja, Serialisieren.

Serialisiert wird dann, wenn ein Objekt die AppDomain verlässt.

Beispiele dafür sind:

• Das Speichern des Objekts auf der Festplatte
• Das kopieren in eine andere AppDomain (siehe AppDomain Klasse)
• Senden des Objekts an eine andere Applikation (z.B. per TCP über ein Netzwerk)

Alle möglichen Additionen wo je ein Element höchstens 1 mal drin vor kommt?

Das ist das Teilmengenproblem. Du willst im Prinzip alle möglichen Teilmengen der Artikel wissen, den Preis darüber zu berechnen ist dann im Prinzip trivial. Das gehört in die Klasse der O(2^n) Probleme, also schlimmer gehts eigentlich nicht mehr.
Das heißt eben, mit einem Element mehr hat selbst ein idealer Algorithmus schon doppelte Laufzeit (und wenn man sich alle Ergebnisse speichern will auch doppelten Speicher).

Allerdings verstehe ich dann nicht, wie du die Preise als Key hernehmen kannst. Man kann doch die gleiche Summe auf unterschiedlichen Wegen erreichen...

Mein Vorschlag wäre das Speichern der Ergebnisse zu ändern. Im Prinzip musst du doch nur wissen, ob ein Element enthalten ist oder nicht. Das lässt sich relativ unaufwändig in einem BitArray speichern. Der i-te Wert im BitArray sagt aus, ob der Preis mit Index i ein Teil der Summe ist oder nicht. Also nimmst du ein BitArray mit Länge n, statt eine Liste.
Damit verbesserst du gleich eine Reihe von Aspekten:
1. die "einkauf.Value.Contains(preis.Key)" Operation reduziert sich zu einem "einkauf.Value" (hier empfielt sich dann mit ner for Schleife über die Preise zu iterieren um den Index zu bekommen)
2. Der Speicherbedarf sollte sich verkleinern
Was du noch etwas verbessern kannst, indem du beim BitArray am Ende alle 'false' abschneidest. Also eine Liste könnte so aussehen: 010010000
Da ist nur das 2. und das 5. Element enthalten. Da schneidest du dann am Ende ab so dass 01001 draus wird. Und wenn der Index für den Preis größer als die Länge des Arrays ist, wäre der Wert dann automatisch 'false' (ich hoffe man kann mir folgen )
3. Du könntest das Aufzählen der Möglichkeiten etwas verändern. Im Prinzip ist das BitArray ja eine große binäre Zahl mit n Stellen (für jeden Preis eine). Du musst dann einfach nur von 00000....0 immer eins addieren bis hin zu 11111...1 und du hast alle möglichen Kombinationen erfasst.

Dabei belasse ich es erstmal, bevor ich noch mehr Fragezeichen erzeuge


Was aber immer bleiben wird aufgrund der Natur des Problems ist eben, dass die Laufzeit und der Speicherbedarf mit der Anzahl der Preise extrem schnell ansteigt, sich mit jedem zusätzlichen Element verdoppelt.

Eine Möglichkeit wären Stored Procedures wie in diesem Beispiel

Für die andere Möglichkeit finde ich nur VB.NET Beispiele.

Prinzipiel läuft es so, dass du ein SqlCommand hast, mit dem Befehl "SELECT @@IDENTITY", womit du über ExecuteScalar direkt die zuletzt verwendete ID herausfindest.

Dann benutzt du das RowUpdated Event. Dort fragst du ab, ob es überhaupt eine Insert-Operation war (sollte irgendwo in den EventArgs stehen). Dann findest du mit dem oben beschriebenen SqlCommand die verwendete ID raus, und setzt das Feld der Zeile (an die kommst du auch über die EventArgs) auf eben diesen wert. Dann noch AcceptChanges auf die Zeile aufrufen, damit die Zeile den Unchanged Status bekommt.

Nur an dem Code kann man nicht sagen wie es effizienter geht, weil ich glaub ich auch nicht der Einzige bin der nicht versteht, welches Problem der Code lösen soll. Also ein rein formales Gegeben-Gesucht würde da weiterhelfen

Leider werden die Vorschläge von yngwie solltest du dir nicht zu viel versprechen. Am Ende bringt es vieleicht etwas, aber bei dem aktuellen Algorithmus wird sich da nicht viel an der Laufzeit tun.
1.) Addition ist im Vergleich zu den anderen Operationen vom Aufwand her vernachlässigbar.

2.) Der Unterschied zwischen Einkäufe und _Einkäufe ist, dass das eine im Moment nicht veränderbar ist, weil man sonst den Enumerator verlieren würde. Soweit hab ich den Code verstanden, weiß allerdings trotzdem nicht was er machen soll. Da kommt man auf jeden Fall nicht drumrum ohne den Ansatz komplett zu verwerfen. Um das zu können ist widerum die genaue Aufgabe wichtig.

3.) Der "Keyzugriff" ist total trivial. Es ist ein Wert von einer Datenstruktur wo nichts berechnet wird. Ob du das 1 oder 10 mal machst wird an der Laufzeit nicht viel ändern.


Imo sind die für die Laufzeit wirklich entscheidenden Befehle diese hier:

einkauf.Value.Contains(preis.Key);
new List<int>(einkauf.Value));

Benutz halt einfach die PointConverter-Klasse um den String in einen Point umzuwandeln.
Der Rest von dem Text war nur Beiwerk um die Frage zu beantworten warum es überhaupt ein String ist. Ändern wirst du es nicht können, ohne dich von der automatischen Generierung zu verabschieden. Was eigentlich unnötig ist für das kleine Problemchen.

Weißt du das ist ein Problem was ich mit der automatischen Codeerzeugung von VS habe. Die Leute benutzen Dinge die sie nicht verstehen. (damit will ich dich nicht angreifen)

Ich kenn mich jetzt mit den von VS erzeugten Settings nicht sonderlich aus. Schau mal wie dort die entsprechenden Properties im Code definiert sind.
Ich tippe mal darauf, dass dort ein ein Attribut vom Typ ConfigurationProperty(Attribute) definiert ist, und dort der String als DefaultValue angegeben ist. Das liegt einfach daran, dass man in Attributen nur primitive Typen (int, float, decimal, usw), Strings und den Typ 'Type' verwenden darf. Also kann man als DefaultValue so nicht einen Point zuweisen.
Außerdem wird dort noch ein Attribut sein (ich tippe mal auf TypeConverter(Attribute)) in dem die Klasse PointConverter als Converter ausgewiesen wird. Die Klasse kannst du dann auch benutzen um den String in einen Point zu konvertieren.

Wie gesagt, ich vermute das nur. Der letzte Satz gilt trotzdem auch wenn der Rest nicht zutrifft

Du kannst nur einfach keinen String in einen Point casten.

Nur mal ein Tipp für die Zukunft. Wenn eine Funktion eine Exception wirft, steht meist in der Hilfe zu der Funktion warum das auftritt, und wie man es behebt. Und wenn nicht schadet es auch nicht mal nen Blick reingeworfen zu haben.
Die Message in der Exception ist oft nicht sonderlich Aussagekräftig und zum Teil auch irreführend.

Bei mir steht da: