Das ist nur ein Makro. Wenn du das benutzen willst, kannst du leicht ne Funktion schreiben, die das gleiche macht. Wenn du es nicht benutzen willst, dann ignoriers einfach.
C# unterstützt leider keine Kovarianz für Rückgabewerte. Die beste Lösung sieht wohl so aus:
public interface IInterfaceBase {
}
public interface IInterface2 : IInterfaceBase {
}
public interface IInterface3
{
IInterfaceBase BusinessLogic { get; }
}
public class Class1<T> : IInterface3
where T : IInterfaceBase {
IInterfaceBase IInterface3.BusinessLogic {
get { return BusinessLogic; }
}
public T BusinessLogic {
get { return default(T); }
}
}
public class Class2 : Class1<IInterfaceBase> {
}
public class Class3 : Class1<IInterface2> {
}
List<IInterface3> lstClassList = new List<IInterface3>();
Class2 oClass2 = new Class2();
lstClassList.Add(oClass2);
Class3 oClass3 = new Class3();
lstClassList.Add(oClass3);
Du kannst eine ganze Menge rausholen, wenn du SqlParameter benutzt. Wenn du die richtig konfigurierst, d.h. Datentyp setzen, Länge setzen, und bei Numeric/Decimal Präzession setzen, dann kannst du die Prepare Funktion von SqlCommand aufrufen. Damit wird das ganze als eine Art Stored Procedure hinterlegt, und der SQL Server spart Zeit zum compilieren und optimieren.
Damit konnte ich eine ähnliche Anwendung um ein vielfaches beschleunigen.
Eine zweite Variante wäre alles in eine Datei zu schreiben, und dann BULK INSERT zu benutzen.
Eventuell könntest du auch mit zwei Threads etwas rausholen. Natürlich nicht in der Simulation.
Aber wenn ein Thread die Datei ließt, und ein anderer in die Datenbank schreibt, könnte eventuell die Rechenzeit besser genutzt werden.
Original von onlinegurke
Bei 64bit-Systemen sollte aber definitiv Double in absolut jedem Fall schneller sein...
Mit so einer absoluten Aussage, liegst du auf jeden Fall falsch
Der Kontext ist bei heutigen CPUs sehr entscheidend und auch sehr umfangreich. Eine generelle Aussage ist nicht möglich.
Zwei Bytes zu addieren ist z.B. im Allgemeinen nicht schneller als zwei Integer zu addieren. Im Speziellen lassen sich aber Byte Vektoren schneller addieren als Integervektoren mit gleicher Dimension.
Außerdem ist die FPU eigentlich schon länger mit 64bit Registern ausgestattet.
Original von Samba
Naja, ich hab eben einen Serializer vom Typ typeof(PatientenPatient) erstellt und ihm eine PatientenPatient[] übergeben, das müsste dann ja auch funktionieren.
Nein müsste es nicht. Der Serializer den du so erstellst, serialisiert ArrayOfPatientenPatient, eben ein allgemeines Schema für ein Array. Du möchtest ein ganz spezielles Schema in der Ausgabe haben. Dieses spezielle Schema wird von der Klasse Patienten umgesetzt. Es ist wenig verwunderlich, dass nicht dieses spezielle Schema rauskommt, wenn du die darauf zugeschnittene Klasse nicht benutzt.
Original von talla
Wie Herbivore schon sagt, für unbehandelte Exceptions gibts das Application.ThreadException Event. Damit fängst du aber nur Exceptions die nirgends anders behandelt werden, in deinem ersten post hat man des net genau rausgehört wie du das nun haben willst.
Wohlgemerkt nur Exceptions, die im GUI Thread geworfen werden. Das gibt es, weil man diverse Bedienungsfehler von Controls nicht mit try-catch abfangen kann.
Sonst sollte man AppDomain.CurrentDomain.UnhandledException benutzen.
Die Speed Membervariablen sind Vektoren oder? Dann wäre der Name Velocity besser gewählt, Speed beschreibt eigentlich nur den Betrag der Geschwindigkeit, und nicht seine Richtung.
Aber die Formel ist eindeutig falsch. Man muss sich nur mal die Einheiten dazudenken, dann kommt am Ende für die gerichtete Geschwindigkeit was mit Gramm raus, was so nicht stimmen kann.
Das müsste so eigentlich hinhauen... vieleicht kriegst es ja noch cleverer umgeformt, aber das zeigt dem Impulserhaltungssatz glaub ich am Besten. Man zerlegt erstmal die Bewegung in die Anteile in Stoßrichtung (speedA und speedB in Richtung impulse). Dann rechnet man über Impulserhaltung und Energieerhaltung die neuen Anteile in diese Richtung aus (newSpeedA und newSpeedB in Richtung impulse).
Und die neue Bewegung ist die Summe aus den neuen Anteilen, und der Bewegung, die Senkrecht zur Stoßrichtung ist. Senkrecht zur Stoßrichtung wäre:
Bis zu ner gewissen Grenze finde ich den Designer gut. Man kann gut mit dem Layout experimentieren, ein paar Eigenschaften verändern und Controls rumschieben und umsortieren.
Ziemlich ätzend das ohne Designer zu machen. Für jede kleine Änderung neu kompilieren und bis zum gewünschten Control durchklicken, nur um festzustellen, dass es scheiße aussieht...
Für alles was unter der GUI liegt, finde ich den Designer aber eher schlecht. Angefangen bei DataBindings, was über den Designer imo umständlicher ist als über puren Code. Außerdem zerstört das automatische erstellen von Events imo das Gefühl für die Trennung von GUI und Funktionen.
Also ich blick da nicht ganz durch, aber es sieht mir so aus, als ob die Relationen falsch angegeben sind.
Mit Code kenn ich mich etwas besser aus:
Mit GetChildRows("...") kriegst du auf jeden Fall was du willst.
Solche Befehle stehen ja auch in der CS Datei. Nur eben an der falschen Stelle. In der Datei steht bei PhotometryAnalysis ein GetParentRow, was logischerweise nur eine Row zurückliefert. Dafür steht bei CalibrationCurvesRow ein GetChildRows.
So wie es jetzt ist, hast du also ne n:1 Beziehung zwischen PhotometryAnalysis und CalibrationCurves. Wenn ich das richtig verstehe, soll das aber eine 1:n Beziehung sein.
Also wie auch immer du das gemacht hast, du musst es andersrum machen
Hab nicht den Eindruck, dass es länger dauert. Wenn ich was zum SQL Server nachschlage, dauert das auch recht lange. Und es dauert definitiv zu lange. Man sollte meinen, Microsoft könnte sich ne vernünftige Anbindung leisten.
Der Unterschied ist, dass ThreadStart ein Delegate ist, und Bla eine Klasse. Probier mal das mal mit Bla.DoDelegate bla = new Bla.DoDelegate( . Da zeigt er dann auch an was du willst, weil Bla.DoDelegate auch ein Delegate ist.
Du könntest höchstens die CopyTo Funktion benutzen, um die Informationen in ein Array zu kopieren. Aber foreach mit ner extra Zählvariable ist imo die bessere Variante.
Man kann durch locking verhindern, dass das 2. Set aufgerufen wird. Das 2 Sets immer sequenziert werden ist klar. Deswegen muss man ja auch nichts machen, wenn man den gleichen Effekt wünscht, wie wenn es 2 mal hintereinander ausgeführt wird. Genau das wird ja gemacht.
Nur wenn man diesen Effekt nicht wünscht, dann muss man was tun. Genau das hab ich doch gesagt.
Seien wir mal realistisch, es wird wohl eher wenige Namen mit mehr als 3 Umlauten geben. Daraus folgt, es gibt höchstens 8 Kombinationen. Das ringt der Datenbank auch nur ein Gähnen ab.
Die Variante mit dem IN erscheint mir aber besser als die ORs. Semantisch ist es natürlich das Gleiche, aber der Optimierer kann da doch ganz andere Sachen draus basteln.
Dell ist finde ich auch nicht gerade die Referenz für günstige Komplett-PCs. Ist zumindest mein Eindruck. Ich hab hier alle Nase lang Angebote von lokalen Händler, die Dell im Preis/Leistung auf allen Leistungsniveaus schlagen.
EDIT: Ich glaube in 2 Monaten werden die Core 2 Duo nochmal ne Eckte billiger, weil sich Intel auf neue Produkte vorbereitet. Das wäre ja mein CPU der Wahl.
Ah ja alles klar. Das kann so natürlich nicht gehen, weil das in nem ganz anderen Kontext steht.
Bei dem Beispielcode den du angehängt hast, ist dieses "plugin" in Wirklichkeit ein Type. Also keine Instanz von IRenderer, sondern eine Beschreibung der Klasse, die IRenderer implementiert. Dort kannst du natürlich nicht mit "is" abfragen, "is" testet, ob eine Instanz einen gewissen Typ hat. Nicht, ob ein Type Objekt einen gewissen Typ beschreibt.
Hast du einen Type gegeben und willst testen, ob dieser ein Interface implementiert, dann musst du sowas machen:
Glaub ich jedenfalls. Die Funktion ist die richtige, ich bin nur nicht sicher, ob man die von plugin aufruft mit IRenderer als Parameter, oder andersrum... ich denke so wirds schon passen
Also ich bin nicht sicher, ob ich das richtig verstanden habe, aber wie wärs, wenn du über Remoting nur ein eingeschränktes Interface auslieferst?
D.h. du gibst dem Client per se nur ein Objekt, vom Typ eines Interfaces, was alle notwendigen Funktionen beinhaltet, nicht aber die eigentlich verbotenen Operationen. Wenn er an verbotene Operationen ran will, muss er also schon mutwillig nen Cast auf die echte Klasse machen.
Das fände ich jetzt ne ziemlich unaufwändige und für dein Problem wirksame Methode.
Die zweite Möglichkeit wäre mit CodeAccessSecurity zu arbeiten. Die strittigen Funktionen benötigen eine gewisse Permission. Und die lässt nur den Server rein und weist die Clients ab.
Nachteil daran, man sieht den Fehler erst zur Laufzeit, nicht zur Kompilierzeit. Der Vorteil, es ist wirklich sicher und kann nicht so leicht umgangen werden.
Macht die Sache aber auch komplexer, als es nötig ist, glaube ich.
Mid ist doch nur ein Substring, nur das man dem ganzen einen dämlichen Namen gibt, so dass ein VB Programmierer für alle anderen Programmiersprachen unbrauchbar ist, wie eben bei VB üblich