myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Externes » Szenenews » C# 6 - Übersicht der Neuigkeiten
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

C# 6 - Übersicht der Neuigkeiten

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.631
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

C# 6 - Übersicht der Neuigkeiten

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo zusammen,

das C#-Team hat einen Beitrag über die Neuigkeiten in C# 6 verfasst - siehe  New Features in C# 6

mfG Gü
21.11.2014 22:02 Beiträge des Benutzers | zu Buddylist hinzufügen
Khalid Khalid ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2534.gif


Dabei seit: 19.07.2005
Beiträge: 3.505
Entwicklungsumgebung: Visual Studio 15/17
Herkunft: Hannover


Khalid ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Bis auf die "Auto-property initializers", die "Getter-only auto-properties" und die "Expression-bodied function members" alles ganz nett. Aber die genannten finde ich grausam. Bestes Feature: await in try..catch..finally.
24.11.2014 08:34 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.575
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ich finde, dass das mit die effizienteste Anpassung von C# überhaupt ist, da viele Alltags-Hindernisse gelöst werden.
Besonders nameof, String interpolation und die Null-conditional operators sowie die Exception-Filter finde ich einfach klasse.

Die Member declaration features sehe ich als hilfreich an, aber nicht als intuitiv.
Sie sind sehr praktisch, aber ich finde die Art und Weise der Änderung in C# als sehr krasse Major-Änderung an - irgendwie zu viel des Guten.
Man merkt hier sehr, dass C# doch in der Web-Welt wichtiger wird und diese Sprach-Konstrukte aus den Web-Script-Sprachen nun hier langsam Einzug finden; finde ich aber nicht unbedingt gut.

Die usings sind für mich auch Käse.
24.11.2014 09:33 Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.473
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo zusammen,

ich habe erst jetzt Zeit gefunden, mich mit den Neuerungen zu beschäftigen. Hier meine Eindrücke:


nameof stellt nur sicher, dass es den angegebenen Namen z.B. einer Property gibt, aber nicht, dass es auch die Property ist, die man meinte, insbesondere beim Kopieren von Code für z.B. INotifyPropertyChanged. Da ist es weiterhin besser das CallerMemberName-Attribut zu benutzen, siehe  Suche Variable für Filename oder Methode für optionale Argumente (C# 5.0?).

Außerdem frage ich mich, ob man nicht an manchen Stellen den vollqualifizierten Namen haben möchte und nicht nur den letzten Namensbestandteil wie ihn nameof liefert.

In bestimmten Fällen ist nameof aber sicher nett.


Lustigerweise bringt die String interpolation genau das Problem mit sich, was im Zusammenhang mit nameof als fehleranfällig beschrieben wird, nämlich Namen und Ausdrücke in String-Literalen. Ok, zugegeben, auch bisher musste der Format-String bestimmte Anforderungen erfüllen, die erst zur Laufzeit geprüft wurden. Trotzdem erhöht sich die Anzahl Fehlermöglichkeiten.

Für (menschliche) Übersetzer sehe ich Vor- und Nachteile. Einerseits muss sich der Übersetzer nicht damit herumschlagen, wofür die Platzhalter 0, 1, 2 usw. stehen, sondern hat einen direkten Bezug. Anderseits darf sich der Übersetzer bei den (möglicherweise komplexen) Ausdrücken nicht verschreiben, sonst gibt es Exceptions zur Laufzeit. Außerdem finde ich die Möglichkeit, dass Übersetzer die Ausdrücke (versehentlich oder absichtlich) ändern können, gefährlich. Übersetzer müssen außerdem aufpassen, dass sie die Namen in den Ausdrücken nicht mitübersetzen. Sie dürfen also aus p.Age nicht p.Alter machen.

Man sollte also genau abwägen, ob man dieses Feature einsetzt oder nicht.


[EDIT]Da es sich bei der String interpolation tatsächlich um ein Compilezeit-Feature handelt, wie Th69 weiter unten schreibt, greift die gestrichene Argumentation - die von einem Laufzeit-Feature ausgeht - nicht. Daher ist es ein nettes Feature, gegen das sich nichts sagen lässt, außer dass es einen eher eingeschränkten Einsatzbereich (eben nur String-Literale) hat und damit String.Format nicht überflüssig macht.[/EDIT]


Der Null-conditional operator ist praktisch. Eigentlich sogar so praktisch, dass man überlegen könnte, das Verhalten zum Standard zu machen, wenn das denn nicht ein Beaking Change wäre. In den wenigen Fällen, in denen tatsächlich eine NullReferenceException geworfen werden soll, könnte man die "umgekehrte" Syntax einführen:

C#-Code:
int length = customers!.Length;


Index initializers
sind ganz nett, nur frage ich mich, warum man dafür eine neue Syntax braucht. Man kann jetzt schon schreiben:

C#-Code:
var numbers = new Dictionary<int, string> {
    { 7, "seven"},
    { 9, "nine"},
    {13, "thirteen" }
};

Das ist für meinen Geschmack genau so gut oder schlecht lesbar wie die neue Syntax. Und erfordert pro Zeile (bei üblicher Formatierung ein Leer-)Zeichen weniger, jedenfalls nicht mehr. Die neue Syntax ist also nicht mal kompakter.


Extension Add methods sind nur konsequent und hätten schon von Anfang genauso wie Instanz Add methods behandeln werden sollen. Vermutlich war es nur ein Versehen, dass es bisher nicht ging.


Zur Overload resolution kann ich nicht viel sagen, weil zumindest in dem verlinkten Blog-Beitrag nichts zu den Details steht. Sollte es wirklich so sein, dass die Methodenauswahl jetzt besser den Erwartungen der Programmierer entspricht, bleibt nur die Frage, ob dadurch Breaking Changes entstehen, wenn man bestehenden Code neu kompiliert.


Exception filters sind mir zu magic, und das ohne Not. Erst recht, wenn im Filter - wie vorgeschlagen - eine Methode mit Seiteneffekt, z.B. fürs Logging aufgerufen wird. Die angegebene Begründung für Exception filters, ist, dass der StackTrace sich bei einem re-throw ändert (=abgeschnitten wird). Das stimmt allerdings nicht wirklich. Bei einem echten re-throw catch (Exception) { throw; } bleibt der StackTrace unverändert(*). Ändern würde er sich nur bei catch (Exception e) { throw e; }. Es besteht also gar keine Notwendigkeit für Exception filters. Ich würde davon abraten.

[EDIT](*) Es ändert sich lediglich die Zeilennummer, die zu der aktuellen Methode angegeben wird. Diese ist nicht mehr die von dem Methodenaufruf, der mit der Exception zurückkehrt, sondern die von der Zeile mit dem throw (bzw. merkwürdigerweise der mit dem Ende des Blocks, der das throw enthält, bzw. sogar der mit dem ersten Statement nach diesem Block; aber das ist wohl eine andere Geschichte).[/EDIT]


Await in catch and finally blocks ist nur konsquent und hätten schon bei der Einführung von await erlaubt sein sollen.


Auto-property initializers und getter-only auto-properties ist nur konsequent und hätten schon bei der Einführung von Auto-property möglich sein sollen. Gut ist, dass man getter-only auto-properties auch in Konstruktor setzten kann. Insgesamt eine gute Umsetzung.


Bei Expression-bodied function members bin ich mir unschlüssig. Für kurze Methoden und Getter spart es Zeilen und etwas Schreibarbeit. Aber irgendwie kann ich mich damit nicht anfreunden. So viel länger ist

C#-Code:
public Point Move(int dx, int dy) { return new Point(x + dx, y + dy); }

statt

C#-Code:
public Point Move(int dx, int dy) => new Point(x + dx, y + dy);

nun auch nicht. Und eigentlich sogar etwas lesbarer finde ich. Vielleicht gewöhnlich ich mich daran, aber momentan überwiegt für mich die Lesbarkeit der gewohnten Syntax die Vorteile der geringen Ersparnis. Momentan würde ich davon abraten.


Parameterless constructors in structs gefallen mir auch nicht. Es ist verwirrend, dass ein explizit definierter parameterloser Konstruktor nur in einem bestimmten Fall aufgerufen wird (bei explizitem new auf einen Strukturtyp), aber in anderen nicht (z.B. new auf einem Array von einem Strukturtyp). Ich würde davon abraten.


[EDIT]Parameterless constructors in structs haben es nicht in das finale Release von C# 6.0 geschafft.[/EDIT]


using static ist sicher in bestimmten Fällen (System.Math) ganz nett und praktisch. Verleitet aber möglicherweise dazu, stärker prozedural statt objektorientiert zu arbeiten. Man sollte das Feature bewusst und überlegt einsetzen.


Fazit: Es spricht dafür, wie ausgereift C# schon ist, wenn die Verbesserungen überwiegend kleine Details betreffen und sich teilweise auf reinen syntaktischen Zucker beschränken. Manche Änderungen scheinen mir praktisch und solide, andere etwas unmotiviert oder sogar wenig durchdacht.

herbivore
13.12.2014 23:04 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Th69
myCSharp.de-Poweruser/ Experte

avatar-2578.jpg


Dabei seit: 01.04.2008
Beiträge: 3.503
Entwicklungsumgebung: Visual Studio 2015/17


Th69 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo herbivore,

ich kann mich den meisten deiner Argument anschließen.
Bei der String-Interpolation jedoch verstehe ich es so, daß die Ausdrücke direkt schon vom Compiler (wie bei der alten Format-Schreibweise die Parameter) überprüft werden, d.h. es ist wirklich nur "syntactic sugar".
14.12.2014 09:56 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.473
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo Th69,

es freut mich, dass meine Argumente für dich überwiegend stimmig sind.

Format-Strings werden - so wie ich das sehe - momentan nicht vom Compiler geprüft und werden es nach der Einführung des "String interpolation"-Features wohl auch weiterhin nicht. Zumindest steht nichts derartiges in dem Blog-Artikel. In vielen Fällen wäre eine Prüfung der Format-Strings durch den Compiler gar nicht möglich, nämlich immer dann, wenn sie erst zur Laufzeit bekannt sind, z.B. weil sie aus einer Datei, Datenbank oder externen Ressourcen-DLL stammen oder erst zur Laufzeit dynamisch zusammengebaut werden.

herbivore
14.12.2014 10:08 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Th69
myCSharp.de-Poweruser/ Experte

avatar-2578.jpg


Dabei seit: 01.04.2008
Beiträge: 3.503
Entwicklungsumgebung: Visual Studio 2015/17


Th69 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Es geht hier aber nicht um den String.Format-Parameter, sondern der Ausdruck

C#-Code:
var s = $"{p.Name} is {p.Age} year{{s}} old";

wird anstelle des Aufrufs der String.Format-Methode vom Compiler ausgeführt d.h. der Compiler erzeugt quasi intern daraus den String.Format-Aufruf:

C#-Code:
String.Format("{0} is {1} year{{s}} old", p.Name, p.Age);

(so verstehe ich das jedenfalls ;-)

Klar wird der eigentliche Format-Parameter erst zur Laufzeit ausgewertet, aber die Parameter dazu sind aber vom Compiler ausgewertete Ausdrücke.

Edit: Man muß für diesen Fall also nicht mehr explizit String.Format aufrufen!
Für externe Format-Strings wird man aber weiterhin die String.Format()-Methode aufrufen müssen und dabei dann weiterhin bei der {0}-Syntax bleiben müssen.
Ob dieses Feature angesichts der Lokalisierung von Anwendungen wirklich nützlich ist, ist also eine andere Sache...

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Th69 am 14.12.2014 11:49.

14.12.2014 11:39 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.473
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo Th69,

ok, du könntest recht haben. Wenn die Interpolation ein Compilezeit-Feature ist, dann sieht es natürlich anders aus. Das würde bedeuteten, dass es nur bei String-Literalen direkt im Code greift. Vergleichbar mit der Umsetzung von Escape-Sequenzen durch den Compiler in die zugehörigen entsprechenden Steuerzeichen. Ich habe meinen Beitrag oben entsprechend geändert.

Vermutlich müssten dann auch die Ausdrücke in dem Kontext, in dem das String.Literal im Code steht, existieren bzw. gültig sein. Das heißt, folgender Code müsste funktionieren:

C#-Code (vermutlich gültiger Code):
void M () {
   Person p = new Person ();
   String s = $"{p.Name} is {p.Age} year{{s}} old";
}

Aber die folgende Verwendung müsste scheitern:

C#-Code (vermutlich ungültiger Code):
String fmt = $"{p.Name} is {p.Age} year{{s}} old";
void M () {
   Person p = new Person ();
   String s = fmt;
}

Fraglich ist auch, ob man vor den String const (vermutlich nicht) oder readonly (schon eher) schreiben könnte.

Und das Feature dürfte natürlich erst recht nicht funktionieren, wenn der String in einer Datei oder Datenbank oder einer externen Ressourcen-DLL steht.

herbivore
14.12.2014 12:04 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Andreas Adler Andreas Adler ist männlich
myCSharp.de-Mitglied

Dabei seit: 18.12.2012
Beiträge: 25


Andreas Adler ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Die String-Interpolation habe ich bisher auch als Compiler-Feature verstanden. Finde die Funktion auch ganz nett.

Allerdings sehe ich kaum Vorteile im Vergleich zu  SmartFormat.NET, da auch noch einige weitere Features hat.
Klar, man hat eine Prüfung des Format-Strings schon bei der Kompilierung und je nach dem wie es intern umgesetzt wird eventuell eine bessere Performance (string.Format ist ja etwas langsamer als normale String-Verkettung mit dem + Operator. Aber ob das dann am Ende so viel ausmachen wird...?


Das Argument für die Exception-Filters hab ich auch nicht nachvollziehen können. Wie herbivore ja schon gesagt hat, bleibt der StackTrace bei einem einfachen throw ja auch erhalten.


Der Null-condition Operator war meiner Meinung nach auch schon lange überfällig. Sehr nützlich!


Ansonsten war ja auch ein Ziel der neuen C#- und VB.NET-Version, die beiden Sprachen näher aneinanderzurücken. Das using-static-Feature beispielsweise gab es in VB.NET von Anfang an (damals wohl aus der Motivation heraus, VB6-Umsteigern entgegenzukommen).
Sei's drum, nützlich kann dieses Feature trotzdem sein.
15.12.2014 11:19 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.575
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ihr müsst mal den Fokus von C# mittlerweile anschauen...
Es hat nicht nur die Anwendungsentwicklung im Auge, sondern teilweise sogar das Scripting im Azure Umfeld.

Es konkurriert also nicht nur mit C++ und Java, sondern zB auch in gewisser Weise mit Python, JavaScript und Co - und dort sind solche String-Formattierungen schon lange üblich; Syntax-Zucker wie das Null-Verhalten sowieso.

Gerade Administratoren werden hier also sehr einfach mit der C# Sprache in Kontakt kommen (können).
15.12.2014 14:35 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 5 Jahre.
Der letzte Beitrag ist älter als 5 Jahre.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 01.04.2020 06:32