Was wünscht ihr euch für C# 5?

Hallo Lord Fritte,

die Standard-Parameter (default parameters) wird es schon in C# 4.0 geben, s.a. The Future of C# (C# 4.0)

Und sind eine ganz blöde Idee ... siehe Für und wider C# 4.0

Und sind eine ganz blöde Idee ... siehe
>

Naja optionale Parameter würde ich (und tut der Blog ja auch nicht) nicht als generell blöde Idee ansehen. Wenn ich jedoch dort lese, wie diese gedacht und implementiert sind, ist das ja so ziemlich gar nicht so, wie man die kennt. Bedauerlich, dass Microsoft hier dem Entwickler sehr strikt vorschreiben will, für was er diese verwendet (ähnlich unschön, wie dass die Zip-Klasse nur die MSO07-Like ZIPs machen kann) und vor allem, dass die diese dann auch noch so implementieren und ankündigen, dass genau dieses extrem unschöne Verhalten nicht offensichtlich ist.

Um es noch mal deutlich zu sagen: Optionale Parameter in C# 4.0 sollte man ausschließlich dann verwenden, wenn es um Kompatibilität zu COM geht.

Ansonsten: Finger weg!

Die Möglichkeit eine Property als PropertyInfo oder ähnliches zu übergeben.

Gerade wieder drüber gestolpert und ein Grund warum ich mit Themen wie eSQL (die Abfragesprache vom Entities Framework) und anderen dynamischen Lösungen (z.B. Reflection) recht vorsichtig bin. String Literale sind zwar im ersten Augenblick schick für solche Sachen, aber halt nicht durch den Compiler geprüft. Ändert sich jetzt mal ein Name einer Spalte in einer Datenbank - oder soll einfach nicht mehr verwendet werden - kann man nur auf gut-glück mit einer Volltestsuche arbeiten. Das ist aber bei großen Systemen gerne mal zwecklos...

Ich habe jetzt erstmal nicht geschaut, ob ich da was über den Call-Stack rausbekomme - bin erstmal damit _zufrieden mich zu ärgern _😁 8o ?( - aber praktisch wäre das manchmal wirklich.

Ich hätte eigentlich 'nur' 2 Wünsche an C#5.0:

• Ebenfalls AOP von Haus aus (bin eigentlich zufrieden mit PostSharp, aber würde es begrüssen, wenn das Framework/C# das direkt anböten)
• Laufzeit-Angabe von Typparametern bei Generics (man wird ja wohl träumen dürfen ...)

Ansonsten bin ich ziemlich zufrieden mit dem Umfang von C#. Eigentlich würde ich sogar fast sagen "übertreibts nicht mit der Featuritis" 😃

Und sind eine ganz blöde Idee ... siehe
>

Sehr guter Artikel, danke. Bin auch der Meinung, dass das ziemlich schnell dazu führen kann, dass aus 'Faulheit' darauf zurückgegriffen wird und sich das später wie beschrieben übel rächen wird. Ich kann auf optionale gut Parameter verzichten, so überlegt man sich zumindest bei jeder Überladung vorher, ob das jetzt wirklich sein muss 😃

Ich wünsche mir auch

Die Möglichkeit eine Property als PropertyInfo oder ähnliches zu übergeben.

oder zumindest, dass man delegates auf die getter und setter von properties setzen kann (sind schließlich auch nur Methoden)

Ich arbeite auf Arbeit hauptsächlich auch noch mit .NET2, habe erst vor kurzem VS2008 bekommen...ich denk immer wir hinken total hinterher deshalb freut es mich zu lesen dass es hier noch andere gibt bei denen es genauso ist 😉
Ich simme Rainbird zu dass man nicht so viele neue Technologien einführen sollte, ich setzt mehr auf Qualität und Verlässlichkeit und nicht auf Quantität.

Dann stört es mich etwas dass es für diverse Befehle zig Varianten (lange Variante, kurze Variante, noch kürzere Variante) gibt wie man es hinschreiben kann, da macht jeder es wie er will und wenn man mal ne Variante nicht kennt versteht man's nicht.
Allgemein habe ich schon in C#4 gesehen wie man manches ultra-verkürzt schreiben kann, und hey, ich hab überhaupt nicht durchgeblickt, letztendlich war es sowas wie eine Variable zuweisen aber nur wenn dies und das und sonst was anderes (und ich meine nicht den "x= a ? b : c" Konstrukt (wie auch immer der heißt)). Raus kommt ja letztendlich das gleiche, da hab ich persönlich lieber etwas längeren Code bei dem man gleich sieht was er macht, statt fünf Anweisungen in eine Zeile zu packen und man blickt nicht mehr durch.

Ich würde mir auch wünschen dass man sich im Hardware-Bereich mehr engagiert, alles etwas schneller wird. Und vielleicht Windows API Funktionen die häufig gebraucht werden einfacher zugänglich machen...

Weniger C#, aber fürs Visual Studio würde ich mir mehr Unterstützung im Thema Design Patterns wünschen (nuja vielleicht gibt es den ja schon in VS2010 oder so). Dass man sich z.B. einfache Templates generieren lassen kann für bestimmte Design Patterns und so.

gruß
sth_Weird

Allgemein habe ich schon in C#4 gesehen wie man manches ultra-verkürzt schreiben kann, und hey, ich hab überhaupt nicht durchgeblickt, letztendlich war es sowas wie eine Variable zuweisen aber nur wenn dies und das und sonst was anderes. Raus kommt ja letztendlich das gleiche, da hab ich persönlich lieber etwas längeren Code bei dem man gleich sieht was er macht, statt fünf Anweisungen in eine Zeile zu packen und man blickt nicht mehr durch.

Das heisst du straeubst dich auch gegen Lambda Expressions und schreibst das ganze lieber mit Delegates und Events aus?
Na dann Prost..

Das heisst du straeubst dich auch gegen Lambda Expressions und schreibst das ganze lieber mit Delegates und Events aus?

nuja, ob ich jetzt schreibe

List<string> evenNumbers = 
   list.FindAll(delegate(string i)
      { return (i.Length % 2) == 0; });

oder

var evenNumbers = list.FindAll(i =>
            (i.Length % 2) == 0); 

soo viel Schreibarbeit spar ich mir da jetzt auch nicht...
Mit dem var bzw. Fehlen von Datentypen hadere ich auch etwas...da geht find ich etwas Typsicherheit verloren.

Mit den Events...bei den eingebetteten Event-Funktionen seh ich spontan auch nur den Nachteil, dass man, wenn man z.b. die Click Methode von x Buttons in einer Funktion anhängen will, diese unendlich lang wird. Ich habe in meinem Code lieber das Event im InitComponents angebunden (oder da wo der Button erstellt wird), und dann mach ich mir ne Region in meinem Code wo ich alle Control-Event-Funktionen abhändle. Dann sind sie auch einfacher zu finden wenn man sie sucht.

Aber ich glaube wir diskutieren jetzt Funktionen die es schon gibt und nichts neues für C#5, insofern geht das glaub ich zu sehr in Richtung off Toppic

gruß
sth_Weird

Hallo sth_Weird

Sorry wenn ich das so direkt sage, aber deine Meinung kommt mir irgendwie rüber, als ob du dich mit dem neuen nicht anfreunden willst, es nicht lernen magst und dich deswegen dagegen streubst.

soo viel Schreibarbeit spar ich mir da jetzt auch nicht...

Es geht ja unbedingt darum Schreibarbeit zu sparen, sondern es ist einfach besser lesbar und sieht um einiges eleganter aus.

Ausserdem zwing dich niemand dazu, die ältere Schreibweise zu benutzen.

Mit dem var bzw. Fehlen von Datentypen hadere ich auch etwas...da geht find ich etwas Typsicherheit verloren.

Was heisst "hadern"?
Im Prinzip ist das ja eine simple Sache und Typsicherheit (Was heisst überhaupt "ein wenig"?) geht da überhaupt nicht verloren.

Gruss Peter

gruß
sth_Weird

was das var betrifft so würde ich mir für c#5 wünschen, das es abgeschafft wird, da zwar nciht die typsicherheit flöten geht (das hat schon 'dynamic' geschafft), jedoch sieht man nicht den typ sofort im code und das ist etwas was ich enttäuschend finde. es geht ja um die lesbarkeit von code und wenn da steht:

var blubb = Foo();

dann sehe ich nciht den typ unmittelbar. ich muss mir erst den rückgabetyp von Foo() anschauen um zu wissen, was da für ein typ verwendet wird. das war in meinen augen eine verschlimmbesserung.

Hallo JAck30lena,

das var wurde deshalb eingeführt da es in Verwendung mit LINQ eine Erleichterung ist - sonst würden Ungetüme von Typen angegeben werden müssen.

Sonst braucht es ja nicht verwendet werden 😉

mfG Gü

Hallo zusammen

Meine Meinung dazu steht hier:

• Alles var – oder nicht?

das var wurde deshalb eingeführt da es in Verwendung mit LINQ eine Erleichterung ist - sonst würden Ungetüme von Typen angegeben werden müssen.

Nein, dafür kann man sie gut gebrauchen aber "eigentlich" wurden sie für die Anonymen Typen eingeführt.
Dort brauchst du var, sonst kannst du die gar nicht nutzen.

Gruss Peter

problematisch hierfür sehe ich nur das vergrößerte potenzial für noch mehr "shit"-code. klar, wenn man sich an die richtlinien hält, dann ist alles kein problem. dann könnte ich auch ohne typsicherheit leben aber dummerweise funktioniert es nciht so, wie man es scih auf dem blatt papier ausdenkt.

var ist in meinen augen nur eine weitere möglichkeit für shitcode und daher habe ich auch ein wenig bammel bei c#4 mit den dynamic.

Also, meine Wunschliste sieht derzeit so aus:

1.) Mixins/Traits (also quasi Interfaces, mit dem Unterschied, dass ich Standardimplementierungen angeben kann). Daran wird laut einiger Blog-Posts und auch Videos auf Channel9 schon gearbeitet, also hoffe ich mal, dass sowas wirklich bald kommt.

2.) Operatorüberladung in Interfaces - wäre schon einige male praktisch gewesen. Normale statische Methoden will ich aber weiterhin nicht in Interfaces haben.

3.) Indexed Properties oder, wie mans auch nennen könnte, benannte Indexer. Das ist eine Sache, die ich schon oft praktisch gefunden hätte.

4.) Design by Contract wie in Spec#, inklusive eines Theorem Proofers, der die Contracts zur Compilezeit analysiert.

5.) Aufhebung der - meiner Meinung nach recht gekünstelten - Einschränkung, dass Contraints für Generics nicht von den Typen System.Enum, System.Delegate und System.MulticastDelegate sein dürfen.

So, das fällt mir auf die Schnelle ein. Ich weiß, recht viel, das würde sehr wahrscheinlich gar nicht alles in eine Version passen. Aber man wird ja wohl träumen dürfen 😉

Hallo,

mir sind passen zur beginnenden Vorweihnachtzeit noch zwei Wünsche eingefallen 😉1.Optimierungen des C#-Compilers 1.Unterstützung für Vektorgrafiken

ad 1) der C#-Compiler könnte optimierten IL-Code ausgeben anstatt den Code nur nach IL zu übersetzen. Also zB mehr Inlining, Schleifenmanipulationen, etc.
Vorteil: Das Programm läuft schneller und dem JITer könnte arbeit weggenommen werden.
Nachteil: Im Reflektor ist der Code nicht mehr so gleich wie dem Quellcode (sofern das wichtig ist, bei yield schauts zB auch ganz anders aus)

ad 2) die meisten Methoden der Graphics-Klasse sind Vektoroperationen wie zB DrawLinie, etc. Die unterstützten Ausgabeformate sind alles Rastergrafiken (Pixelgrafik). Super wäre hier wenn SVG, EPS, PDF direkt erstellt werden könnte (oder nur 1 davon, da sich Vektorformate relativ einfach konvertieren lassen).
Hierzu gibt es zwar mit Cairo eine funktionierende Alternative, aber dies könnte doch direkt dabei sein und somit würden die üblichen Graphics-Befehle weiter verwendet werden können.
Vorteil: Man hat eine Vektorgrafik 😉
Nachteil: Fällt mir keiner ein.

mfG Gü

Ist zwar schon älter, aber: Typisierte Integers!

Was soll das sein: Wir verwenden für die Implementierung diskreter Algorithmen C#. Da kommen häufig indizierte Objekte vor. Die dann auch noch Redundant gespeichert werden müssen.

Also habe ich z.B:

class Person{
    int id;
    int department;
}

class Department{
    int id;
    int[] persons;
    int[] boss;
}


class Specification{
    Person[] persons;
    Department[] departments;
}

Aus performancegründen führt an Arrays kein weg Vorbei, Dictionaries sind keine Alternative.

Nun ist das Problem, das ich z.B. mit der Department-ID auf eine Person zugreifen kann. Also departments[person.id]. Das bekommt man i.d.R. noch gut hin. Ekelhaft ist eher die Verwechselung lokaler und globaler IDs (ist z.B. boss in Department der Index der Person im Department oder global?)

Mit typesicheren Arrays und IDs ginge das ganze viel einfacher:

Ist zwar schon älter, aber: Typisierte Integers!

Was soll das sein: Wir verwenden für die Implementierung diskreter Algorithmen C#. Da kommen häufig indizierte Objekte vor. Die dann auch noch Redundant gespeichert werden müssen.

Also habe ich z.B:

define PersonId:int;
define DepartmentId:int;

class Person{
    PersonId id;
    DepartmentId department;
}

class Department{
    define LocalPersonId:int;
    DepartmentId id;
    PersonId[<LocalPersonId>] persons;
    LocalPersonId[<LocalPersonId>] boss;
}


class Specification{
    Person[<PersonId>] persons;
    Department[<DepartmentId>] departments;
}

Dabei stellt ein Array Person[<PersonId>] sicher, dass als Index nur eine PersonId übergeben werden kann.

In C++ kann man sich das mit Structs und nachbauen, das wird alles wegoptimiert. In C# geht das leider nicht, da kostet sowas zu viel Performance. Obiges Konstrukt hingegen würde zur Copilezeit geprüft werden können und kostet zur Laufzeit keine Performance.

Ähnlich sind die Units in F#.

Viele Grüße,
Uwe

nichts für ungut aber warum übergibst du die id eines objektes und nicht gleich das objekt selbst? dann hast du es gleich typisiert und die id ist die referenz?

Die Möglichkeit in einem Interface einen Constructor zu definieren. Mit ISerializable zeigt .NET recht schön, dass das Feature manchmal nicht schlecht wäre.

Die Möglichkeit in einem Interface einen Constructor zu definieren. Mit
> zeigt .NET recht schön, dass das Feature manchmal nicht schlecht wäre.

Ich würde sogar so weit gehen und sagen, dass man ganze Methoden in Interfaces implementieren können sollte. Das ganze funktioniert in Scala mit Traits wunderbar! Bin ein echter Fan davon geworden.

Optimierungen des C#-Compilers

ad 1) der C#-Compiler könnte optimierten IL-Code ausgeben anstatt den Code nur nach IL zu übersetzen. Also zB mehr Inlining, Schleifenmanipulationen, etc.
Vorteil: Das Programm läuft schneller und dem JITer könnte arbeit weggenommen werden.
Nachteil: Im Reflektor ist der Code nicht mehr so gleich wie dem Quellcode (sofern das wichtig ist, bei yield schauts zB auch ganz anders aus)

Dass das nicht der C# Kompiler "voroptimiert" liegt daran, das dieser nicht weiss, auf welchem Prozessor der Code laufen wird (abgesehen von 32/64 bit). So kann der JITer nämlich noch intensiver optimieren. ZB wenn er die Größe der L1 und L2 Caches kennt...

So kann der JITer nämlich noch intensiver optimieren.

ich würde eher etwas begrüßen, das beim start der anwendung automatisch eine ngen compilierung anwendet. so muss man sich dann nicht im setup anstrengen.

Unterstützung für Vektorgrafiken

Servus Gü,

auch wenn Dein Wunsch schon älter ist:

zu deinem Vektorgrafikwunsch kann ich Dir einen Tipp geben: SVG2XAML.

Grüße

Tobi

Hallo Tobias_H,

danke für den Tipp, aber ich bin mit Cairo ganz zurfrieden 😉

Die Aussage dass eine geinlinte Methode_ überall schneller_ relativiere ich ein wenig denn es kommt auch Instruction-Pipelining, Cache-Size, etc. hinzu und somit ist überall nicht ganz korrekt, denn in seltenen Fällen kann es sogar "langsamer" werden. Daher auch kein generelles und allgemeines Inlining 😉
Dennoch ist die Heuristik die der JITer verwendet ziemlich starr und durch eine zusätzliche Compileroption oder eine weitere Option in MethodImpl (also das Gegenstück zu NoInlining) könnte der C# Compiler oder auch der JITer angewiesen werden diese Methode zu inlinen. In diesem Fall kann das aber gleich der C# Compiler durchführen.

Den Vorteil den ich darin sehe ist dass ich nicht auf die (nicht offiziell von MS dokumentierte) Heuristik des JITer angewiesen bin. So können auch Methoden geinlined werden die der JITer nicht dafür in Betracht ziehen würde. Ob sich das für die betroffene Methode ausgezahlt hat zeigt ein Performance-Vergleich. Ich gehe aber davon aus dass sich das meistens auszahlen wird.

Der MS C++ Compiler für .net kann auch Methoden inlinen (gemeint sind nicht Inline-Functions sondern Inline-Expansion). Warum sollte es also der C# Compiler nicht können?

Wie bereits erwähnt ist die Heuristik mit welcher der JITer entscheidet was mit einer Methode passiert ziemlich starr und mir ist nichts bekannt dass der JITer auf die Prozessorarchitektur eingeht. Also kann ich dein Argument in Bezug auf JIT nicht nachvollziehen, wobei du recht hättest wenn der JITer das so machen würde. Macht er aber nicht (außer x86 und x64, aber keine Cache-Berücksichtigung udgl.).

Ich verstehe also nicht warum dieses Feature nicht unterstützt werden sollte. Wenn es wirklich unnötig sein sollte dann erklär mir das bitte detailierter.

mfG Gü

PS: Es sei noch angemerkt dass ich mir keine Gedanken über die Art und Weise wie dem Compiler mitgeteilt wird dass er eine Methode inlines soll, etc. gemacht habe. Das obige sind nur spontane Gedanken wie es umgesetzt werde könnte.

Ich weiss wovon er gesprochen hat.){gray}