Dafür müsstest du erstmal definieren, was menschenähnliche Intelligenz überhaupt sein soll, bzw. was sie leisten soll. Bevor man eine Lösung suchen kann, muss man sich erstmal über das Problem klar werden.
Ich könnte mir vorstellen, dass die Interfaces explizit implementiert wurden.
Also das Interface wurde explizit implementiert, und dann die Property mit dem "echten" Typ zusätzlich noch hinzugefügt. Die expliziten Implementierungen sieht man nur, wenn man auf das Interface castet.
Das sähe dann so aus:
public interface IUserWithRoles : IUser {
IList<IRole> Roles { get; }
}
public class User : Person, IUserWithRoles, IUser,
IAuthenticationActiveDirectoryUser, IAuthenticationStandardUser {
[Association("User-Role")]
public XPCollection<Role> Roles
{
get { ... }
}
// keine Ahnung ob hier noch ein Attribut hin müsste...
IList<IRole> IUserWithRoles.Roles
{
get { return this.Roles; }
}
Das ist prinzipiell keine schlechte Idee. Man sollte das aber nur bei Rückgabetypen machen.
Ich möchte noch für herbivore anmerken, dass dieses Beispiel auch das einzige Szenario ist, bei dem man das new Schlüsselwort sinnvoll einsetzen könnte. In dem Fall wäre das Roles eine Property der Basisklasse und man würde das mit einem Roles mit spezielleren Typ verdecken. So sieht das z.B. bei allen von DbCommand erbenden Klassen und der Parameters Property aus.
Wie gesagt nur bei Typen von Rückgabewerten zu empfehlen.
Du kannst letztendlich jedes Objekt zurückgeben, was IList implementiert.
Aber die Signatur der Property in der Klasse muss mit der Signatur im Interface übereinstimmen. Das heißt der definierte Rückgabetyp muss identisch sein. Wenn im Interface IList als Rückgabetyp steht, muss auch die Property in der Klasse IList als Rückgabetyp definiert haben, egal welches Objekt am Ende tatsächlich zurückgegeben wird.
Ich seh es eigentlich auch anders. Insgesamt dezentralisiert sich das. Wer nur noch auf eine Technologie setzen will, steht ziemlich schnell als Einsiedler da. Imo kann man die heutigen neuen Sprachen in ihrer Nutzung nicht mit den guten alten Zeiten vergleichen.
Gerade weil die neueren Sprachen in sich konsistenter und besser designed sind, ist es viel leichter die Sprachwelt auch mal zu wechseln. Programmierer sind imo viel Sprachunabhängiger.
In C++ kann man nicht einfach so reinspringen. Wenn man die Grundkonzepte der Programmierung versteht, ist das in C++ gerade mal ein Anfang. Schon allein dass es keiner schafft einen 100% standardkonformen C++ Compiler zu schreiben, sollte einem da sehr zu denken geben.
Ich bin Student und verdien nebenbei Geld mit Programmieren. Ich werd sowieso zu schlecht bezahlt um keine Fehler zu machen
Bei den wirklich kritischen Stellen, dort wo Daten verloren gehen könnten, oder wo Daten meinen Kontrollbereich verlassen, schaue ich auch ganz genau hin. Dort ist mir bisher noch nichts passiert. Ein Programmabsturz ist für die meisten Kunden kein großes Problem. Das heißt ja nur mehr Arbeit für mich und nicht für sie. Aber wenn Daten in der Datenbank irgendwie verfälscht werden, heißt das Arbeit für sie und dann ist die Stimmung ganz schnell im Keller.
Also ich arbeite viel mit Datenbanken aber wenig mit GUIs.
Mit DataBindings stehe ich auch etwas auf dem Kriegsfuß. Was imo daran liegt, dass sich die Darstellung teilweise stark von den Daten unterscheidet.
Das Problem bei der Geschichte mit der Basisklasse ist ja, dass sie eigentlich schon alles können muss. Du musst von der Basisklasse aus bestimmen können, ob das Feld blockiert oder nicht.
Also eigentlich läufts darauf hinaus, dass deine Basisklasse genau so aussieht, wie in deinem ersten Ansatz. Trotzdem empfielt es sich das ganze schon im Hinterkopf als Basisklasse zu gestalten. Das heißt die Auswertung der einzelnen Dinge in virtuelle Methoden packen, die bei Bedarf überschrieben werden könnten. So hast du dann kein Problem, wenn später z.B. mal ein Feld hinzukommt, was man nur Nachts durchschreiten kann.
Das Zweite klingt für mich verdächtig nach eine Resourcenverwaltung. Da kenne ich mich jetzt nicht so gut aus, weil ich eher resourcenlose Programme schreibe. Ich weiß nur, dass es dafür in .NET schon viele gute Klassen gibt die du benutzen solltest, bevor du das Rad neu erfindest (wie eigentlich fast immer).
Dann verstehe ich die Aufregung wirklich nicht. Zumal die gleiche Gesetzesänderung ebenfalls enthält, dass man nach Abschluss der Ermittlungen (bis auf Ausnahmen) über die Maßnahmen informiert werden muss.
Also die konkrete Gesetzesänderung von NRW ließt sich für mich so, dass die Überwachung von Computern etc. auf die gleiche Stufe gestellt wird wie Überwachung von Telefonen und Briefverkehr.
Original von Borg
Wegen DirectX 10 und den entsprechenden Spielen würde ich mir keine Sorgen machen. Da DirectX 10 ausschließlich auf Vista laufen soll, werden sich die Spieleentwickler sehr zögerlich mit der Anpassung haben. Ich denke, es werden noch mindestens drei Jahre ins Land gehen, bevor es Spiele ausschließlich für DirectX 10 gibt.
Ich bin sogar der Meinung, dass Microsofts Marketing-Trick mit DirectX 10 nicht funktioniert. Selbst wenn MS es durchhält, DX10 nicht für XP zu veröffentlichen, so wird irgendeine Cracker-Truppe es schon schaffen das ganze Paket an XP anzupassen.
Daher mein Fazit: ich werde keinen Cent für Vista ausgeben.
Naja ich sehe keinen Grund warum das anders als bei den Graphikkarten laufen sollte. DirectX 10 kann halt paar Sachen mehr oder besser und manche werden das optional unterstützen und irgendwann wirds eben von der Option zur Voraussetzung.
Mit Pixelshader wars ja genauso. Da hats auch keinen gestört, dass man sich eben ne neue Graphikkarte holen muss. Und billig ist das ja auch nicht unbedingt. Ich versteh nicht warum man Microsoft mit anderen Maßstäben messen muss.
Ich sehe meine Freiheit da ehrlich noch nicht bedroht und absolut keine Parallelen zu einem totalitären System, geschweigedenn 1984.
Ich meine solange man öffentlich sagen kann was man will (solange es nicht gegen diverse Artikel des Grundgesetzes verstößt), ohne dafür ins Zuchthaus zu kommen, sehe ich absolut keine Gefahr schon für das, was man nicht öffentlich sagt irgendwie bestraft zu werden. Und das heißt, dass ich auch keine Angst vor Verfolgung und Überwachung habe. Damit meine ich ganz konkret, nicht, dass ich nichts dagegen habe überwacht zu werden. Sondern viel mehr, dass ich nicht glaube, dass ich überwacht werde ohne einen guten Grund.
Und mit gutem Grund darf man gerne auch überwachen.
Original von talla
Im Grunde verstehe ich die Aufregung nicht, ob es nun offiziell zur Dateneinsicht erlaubt ist auf fremde Rechner zuzugreifen bei Verdacht, oder ob Fahnder vor der Haustür stehen und den Rechner beschlagnahmen bei Verdacht - wo ist der Unterschied?
Naja wenn man es so betrachtet, ob ein Punkt vom kleineren Bogen im größeren Bogen liegt, dann klappt das auch.
Also man muss eventuell die Eingabe umtauschen, so dass A und B immer den größeren Bogen repräsentieren.
Außerdem wäre es vieleicht leichter, nicht A und B zu betrachten, sondern A und Distanz zu B. Dann muss man nur die Distanz von A zu C und D berechnen, und schauen, ob die kleiner als die Distanz zu B ist.
Man muss die Punkte dann nur im gleichen Drehsinn betrachten d.h. wenn die Distanz negativ wird, nochmal 360 draufaddieren.
Dadurch sollte man aber die Probleme loswerden die entstehen, wenn die Bögen den Winkel 0 überschneiden. Man betrachtet dann quasi alle Winkel von A aus, und dort ist B immer größer als A.
Klassen, die nicht mit [Serializable] markiert sind, lassen sich doch exakt genauso in XML serialisieren wie mit diesem Attribut. Das hat damit garnichts zu tun.
Wenn man Zahlen vergleicht wird IMMER alles ausgewertet. Also es wird mit einem einzigen CPU Befehl auf ==, > und < geprüft. Egal ob man das mit nem if oder nem switch macht. Ich glaube man kann mit nem XOR einen Takt sparen, wenn man nur auf Gleichheit prüfen will. Bin mir da aber nicht völlig sicher, und schon garnicht, ob der JITer das auch macht.
Es stimmt, dass switch deutlich besser optimiert werden kann. Zum einen kann man eben eine Jumptable anlegen wenn die Werte dicht beieinander liegen, zum anderen kann man die Werte clever anordnen und eine binäre Suche durchführen, die als C# Code extrem hässlich und unübersichtlich wäre.
Am Ende spielt aber wie herbivore richtig sagte nur die Lesbarkeit eine Rolle. Wenn man das .NET Framework benutzt, ist man schon so weit von der Hardware weg, dass Performancebedenken dieser Art eher sinnlos sind. Faktoren, die man in .NET nur sehr schwer beeinflussen und überschauen kann, wie Caching und Pipelining können einen mit etwas Pech die Abschätzung völlig zunichte machen. Mal davon völlig abgesehen, dass man nahezu nie einen spürbaren Unterschied feststellen wird, selbst wenn alles günstig laufen sollte.
Wenn gelöscht werden soll, geh ich immer von hinten ran, dann wirds auch ne schöne Schleife:
for ( int i = this.Controls.Count - 1; i ≥ 0; --i )
{
if (this.Controls[i] is Label)
{
Control ctrl = this.Controls[i];
this.Controls.RemoveAt( i );
ctrl.Dispose();
}
}
Finds irgendwie unschön nur halbe for-Schleifen hinzuschreiben.
Naja bei Bibliotheken, bzw. Anwendungen die nicht hart mit Windows.Forms zu tun haben, ist das keine annehmbare Lösung. Also Control.Invoke würde ich da gleich wieder vergessen.
Dir bleibt nichts anderes übrig als die Start Methode zu synchronisieren.
Dazu sehe ich zwei Möglichkeiten:
Das erste wäre den Thread gleich mal weglassen. Ist sowieso keine schlechte Idee. Es ist sehr leicht eine Methode asynchron ausführen zu lassen, wenn man das wünscht. Es ist unmöglich eine asynchrone Methode zu synchronisieren, ohne den Code dieser Methode zu ändern. In Bibliotheken ist es daher denkbar schlecht die asynchrone Variante vorzuschreiben.
Die Zweite ist deutlich komplexer. Als Vorbild kannst du dir mal die FileStream Klasse und die BeginRead und EndRead Methoden darin anschauen. Das ist das typische Muster für asynchrone Methoden, das durchweg im Framework verwendet wird.
Grob gesagt besteht das einseits aus einem Callback, dass aufgerufen wird, wenn die Methode fertig ist (egal ob fehlerhaft oder erfolgreich). Das dient aber nur der asynchronen Fehlerbehandlung, d.h. der andere Thread weiß da immernoch nichts davon. Das würde aber auch schon reichen, es ist dann möglich die Threads zu synchronisieren, es ist nur etwas Arbeit.
Andererseits gibt es da das IAsyncResult, dass von der BeginMethode zurückgegeben wird. Damit kann man dann wirklich die Threads synchronisieren. D.h. der aufrufende Thread kann dann auf das Ende des anderen Threads warten. Um dann zu wissen, wie der ausgegangen ist, gibt es dann die EndRead Methode. Die findet dann aus dem IAsyncResult raus, was passiert ist, und wirft dann gegebenenfalls die Exception, und zwar dann in den richtigen Thread.
Das ganze müsstest du natürlich selbst implementieren. Es ist aber nicht so viel Arbeit, wenn man das Prinzip erstmal verstanden hat.
Meine Fresse, 3GB Speicher werden zur Installation belegt. Visual Studio selbst ist laut Anzeige 2GB groß. Nach ner halben Stunde fragt er dann, ob man denn auch wirklich installieren möchte, knappe 4 Stunden später bin ich fertig. Und ich hab hier noch PCs die bedeutend schwächer sind. Naja, dort läuft immerhin nur Express, das wird wohl nicht ganz so hart sein.
Und dann zeigt $(TargetPath) immernoch aufs obj Verzeichnis. Das ist eines der wenigen Dinge, die mich wirklich nachhaltig stören.
Original von norman_timo
Deshalb wäre für mich ein Programmierwettbewerb mit einem Thema wie "Entwickle ein Algorythmnus...", "Programmiere die schnellstmögliche Lösung mit Problem xyz"...
eher interessant.
Naja das fänd ich eher langweilig, gerade weil ich mich auf dem Gebiet recht gut auskenne. Ich hab unter anderem mitgemacht, weil ich sonst garnichts in dieser Richtung mache. Ich konnte mich also mal an was ganz anderem testen, und hab dabei viel gelernt.
Außerdem grenzt es jene mit weniger Know-How extrem aus. Ich fänds blöd wenns nur darum ginge zu zeigen, wer der Größte ist.
Wenn du Algorithmen schön findest, bau doch welche in das Projekt mit ein. Zumal man aus vielen Algorithmen auch tolle Spiele basteln kann. Sei es um das Spielfeld zu generieren (z.B. Sudoku oder ein Labyrinth) oder mit ner KI einen Gegenspieler zu stellen. Muss ja kein Schachcomputer sein Tic-Tac-Toe oder Vier-Gewinnt oder sogar Mensch-ärger-dich-nicht geht doch wunderbar mit Algorithmen und kommt mit sehr spartanischer Spielfläche aus.
Merkt man z.B. daran, dass man unterschiedliche Funktionen benutzen kann/muss wenn man an unterschiedliche Datenbanken geht. Z.B. heißt es in Oracle SUBSTR und in MSSQL Substring.
Bei Access ist es was anderes. Da gibt es ja nur die Datei, in der die Datenbank gespeichert ist. Da läuft ja nirgendswo ein Programm für die Datenbank, wie bei MSSQL oder Oracle. Dort muss wirklich der Treiber selbst rausfiltern was gebraucht wird.
Der Adapter macht es dann trotzdem nicht, er verlässt sich darauf, dass der OleDb Treiber für die Datenbank ihm die richtigen Ergebnisse liefert.
Prinzipiell stellt sich der DbDataAdapter ziemlich dumm, wenn du ihm mit den Commands fütterst, die er braucht. Den interessiert das überhaupt nicht was da drin steht, ob du Primärschlüssel abfragst oder nicht. Er hätte nur gerne bestimmte Intigritätsbedingungen erfüllt, und das heißt, wenn du ein Update auf eine Zeile ausführst, dann soll die Zeile doch bitte auch in der Datenbank existieren.
In deinem Beispiel hat sich das Update auf keine Zeile ausgewirkt. Das kann mehrere Ursachen haben:
1. Dein Updatebefehl stellt die falschen Bedingungen in WHERE.
Sieht mir nicht danach aus.
2. Die Parameter haben die falschen Werte.
Du fügst die Parameter einfach hinzu und machst danach nichts mehr. Für Schlüsselfelder (also bei DELETE und UPDATE alles, was hinter WHERE steht, egal ob echter Primärschlüssel oder erdachter Schlüssel) sollte man immer die SourceVersion des Parameters auf Original setzen.
3. Die Felder haben den Wert NULL.
NULL kann nicht mit = geprüft werden, sondern nur mit "IS NULL". Um beides parallel machen zu können, muss man für ein Feld das NULL unterstützt noch einen zusätzlichen Parameter einführen.
Mal angenommen "dia_id" könnte NULL sein, dann müsste das so aussehen:
// updateCommand = "UPDATE pool SET sta_id = ?, sta_comment = ? WHERE ((dia_id = ?) OR (? = 1 AND dia_id IS NULL)) AND dil_id = ? AND use_id = ?"
adapter.UpdateCommand = new OdbcCommand(updateCommand,_connection);
...
OdbcParameter param = adapter.UpdateCommand.Parameters.Add( "@dia_id", OdbcType.Int,11, "dia_id" );
param.SourceVersion = DataRowVersion.Original; // siehe 2.
param = adapter.UpdateCommand.Parameters.Add( "@dia_id_null", OdbcType.Bit,1, "dia_id" );
param.SourceVersion = DataRowVersion.Original;
param.SourceColumnNullMapping = true;
...
durch das param.SourceColumnNullMapping sagst du dem Adapter, dass er den Parameter auf 1 setzen soll, wenn der Wert der Column NULL ist, und 0 sonst.
4. Irgendwas war noch... aber habs beim Schreiben von 3. vergessen
Kannst nur die .cspoj Datei per Hand editiere.
Einfach bei ner Windows Anwendung mit dem Editor mal reischauen. Dort stehen alle Dateien aufgelistet, und mit DependentUpon werden die Nebendateien an die Hauptdateien "rangehangen"
Aber es stimmt schon, dass monolithische Klassen einem schnell ein Bein stellen können. Komposition ist Vererbung vorzuziehen. Statt x Interfaces zu implementieren, verpasse der Klasse Komponenten, die jeweils eines umsetzen. Dann der Klasse noch ein Interface geben, das den Zugriff auf die Komponenten freigibt.
Ich hab noch nicht einen Fall erlebt wo eine monolithische Klasse sich beim Refactoring (um neue Kundenwünsche einzubauen, um Fehler auszubauen, etc.) als günstig erwiesen hat.