Hallo secondsun
Wie stellt ihr euch eine solche vollautomatische Lösung vor? Threadsicherheit alleine heißt nicht, dass beliebige Threads ohne eigenes Zutun einfach mit dem gleichen Objekt arbeiten können, ohne dass es früher oder später knallt.
Wenn mehrere Threads auf die gleichen Objekte zugreifen, kann methodenübergreifende Konsistenz nicht auf magische Weise in dem internen Code der Klasse erreicht werden. Ebensowenig wird es gelingen, etwas so komplexes wie Frameworks, über Wrapper, threadkonsistent zu machen.
Kennst Du die statische Methode System.Collections.Queue.Synchronized()? Damit werden einfach Queues threadsafe gemacht. Wunderbar.
Hast Du dich schonmal gefragt, warum es in System.Collections.Generic kein Pendant dazu gibt? Nachdem was ich vor einiger Zeit mal gelesen habe: Weil zu viele Programmierer in eben jene Falle gelaufen sind und erwartet haben, dass die threadsichere Queue nun beliebig über Threadgrenzen hinweg verwendet werden kann.
Um den Punkt zu verdeutlichen. Folgendes raucht so gut wie immer mit einer InvalidOperationException ab:
class Program
{
static void Main(string[] args)
{
Queue q = System.Collections.Queue.Synchronized(new Queue(Enumerable.Range(0, 100).ToList()));
new Thread((o) => Worker(q)).Start();
Worker(q);
Console.ReadKey(true);
}
private static void Worker(Queue q)
{
while (q.Count > 0)
{
Thread.Sleep(10);
Console.WriteLine((int)q.Dequeue());
}
}
}
Erst wenn Worker synchronisiert wird, funktioniert es.
Auch wenn ich mit dem EF nicht arbeite (sondern mit nHibernate), behaupte ich einfach mal, dass euer Vorhaben nicht möglich ist.
Was man aber realisieren kann, sind Hilfklassen, welche die Arbeit bei Multithreading erleichtern. Ist nur die Frage, was genau erreicht werden soll.
Servus,
der string muss in der Länge gleich dem Format sein. d.h. "dd.MM.yyyy" -> "dd.MM.yyyy HH.mm.ss". Verwende anstatt ParseExact, TryParseExact und überprüfe den Rückgabewert (true / false).
Gruß
Hellsgore
Sieht interessant aus. Ich werde es aber doch bei den Standard-Dateien belassen, weil ich im Moment noch viele andere Sachen zum Laufen bringen muss
Danke für die Antwort.
Gruß
Sonic
ujnhu schrieb:
Wieso wird, wenn man die Eigenschaft BackColor unangetastet lässt, das Ausgrauen automatisch ausgeführt sobald man Enabled ändert? Ergänzt die IDE da etwas, oder wie funktioniert das?
Solchem Verhalten kann man gut mit ILSpy auf den Grund gehen:
http://wiki.sharpdevelop.net/ILSpy.ashx
Damit kannst Du Dir anschauen wie BackColor und Enabled implementiert sind.
Nur falls das entsprechende Verhalten in nativem Code implementiert ist, ist man aufgeschmissen.
Newbie² schrieb:
Ich hätte da mal noch so eine Frage, kann man Bilder einlesen, und das geschriebene in Text umwandeln und wäre es unmöglich für einen Anfänger?
Für mich klingt es momentan so, als würde ich es erst in paar Jahren schaffen...
Wüsste nicht, wie es gehen sollte...
mfG,
Newbie²
Was du suchst, hört auf den Namen OCR (Optical Character Recognition, auch Texterkennung).
Eine sehr interessante und kostenlose Opensource-Lösung ist Tesseract OCR. Schau' dir mal an.
Der Destruktor ist der Punkt, an dem du deinitialisierungen vornehmen kannst.
Solange du dich also im Destruktor der Klasse befindest, kannst du weiterhin auf deren Member zugreifen. - Ausnahme ist, wenn du die Member weggeräumt hast. Dann knallts natürlich.
@David W
Das .NET Framework hat was was sich "Finalizer" nennt. Das ist (mehr oder weniger) ne ganz normale Methode, und die kann halt aufgerufen werden, und der Finalizer-Thread macht das auch automatisch.
Und C# hat was was sich "Destruktor" nennt (ich finde es auch doof, aber in der offiziellen Doku von MS wird das Wort leider verwendet).
Der C# Destruktor implementiert dabei den Finalizer. Und zwar mit "Chaining", d.h. es wird automatisch auch der Finalizer der Basisklasse aufgerufen.
Daher macht die Unterscheidung der beiden Begriffe (zumindest manchmal) Sinn. Wobei ich wie gesagt den Begriff "Destruktor" für unglücklich gewählt halte, eben weil man dabei normalerweise an C++ und deterministische Finalisierung denkt.
Bezüglich der MemoryLeak-Quelle beim Xml-Serializer:
XmlSerializer Class
Auszug:
To increase performance, the XML serialization infrastructure dynamically generates assemblies to serialize and deserialize specified types. The infrastructure finds and reuses those assemblies. This behavior occurs only when using the following constructors:
System.Xml.Serialization.XmlSerializer(Type)
System.Xml.Serialization.XmlSerializer(Type,String)
If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, resulting in a memory leak and poor performance. The simplest solution is to use one of the two constructors above. Otherwise, you must cache the assemblies in a Hashtable, as shown in the following example.
Anhand des MSDN Beitrags sollte klar werden, worin die Leak-Quelle besteht. - Eine Möglichkeit das zu umgehen steht ja im Text.
[quote="asc"]Das mag vielleicht bei Projekten mal vorkommen (sofern die Klauseln wirklich die Sourceübergabe einschließt - was ich nur selten erlebt habe)./quote]
Ja, das kommt natürlich drauf an, was man macht. Das waren alles Auftragsarbeiten für konkrete Kunden und somit gehörte auch der Source diesen Kunden. Wenn man was eigenständiges für mehrere Kunden macht, ist es natürlich was anderes.
Ansonsten... Man kann natürlich einen Obfuscator einsetzen, ist kein großer Aufwand. Viel bringt es aber nicht. Wenn der Kern des Programms in einem bestimmten Algorithmus besteht, wird man ihn auch in obfusckierter Form nachvollziehen können. Wenn aber das ganze Programm an sich wichtig ist, dann wird Reverse Engineering beim Nachbauen keine besonders große Hilfe sein.
Hallo Koni1988,
du versuchst dort einer Queue<int> einen Int32 zuzuweisen. Das geht so nicht. Du kannst ja auch nicht in dein Haus gehen und den Motor anlassen, weil du Campen fahren willst.
Eine Queue<T> bietet für das Hinzufügen Enqueue und für das Entfernen Dequeue.
