Die Verwendung von dynamic
-
Edit by Dravere:
Abtrennung von http://www.c-plusplus.net/forum/301467
Zitierter Beitrag ist http://www.c-plusplus.net/forum/p2196568#2196568Dravere schrieb:
Man sollte sich allerdings bewusst sein, dass sich dies negativ auf die Performance auswirken kann. Ist somit mit Vorsicht zu geniessen
Grüssli
Viel wichtiger als der Performance Fakt, aber dennoch richtig, finde ich den Compile-Time Sicherheits Fakt
-
Firefighter schrieb:
Viel wichtiger als der Performance Fakt, aber dennoch richtig, finde ich den Compile-Time Sicherheits Fakt
Ich bin etwas gespalten über dieses Argument. Aus den folgenden drei Gründen:
1. Der Fehler passiert eher selten. Mir ist er noch gar nie passiert. Man passt hier besonders auf und zudem sind die betroffenen Codeteile meistens recht nah beeinander.
2. Falls man doch mal einen Fehler machen würde, wird spätestens der nächste Unittest dies anmeckern. Der Fehler dürfte sehr schnell korrigiert sein. In C# haben wir zudem nicht die wahnsinnig langen Kompilezeiten wie bei C++.
3. Es gibt viele Programmiersprachen, wo man diese Compile-Time-Sicherheit nicht hat und trotzdem lässt sich darin problemlos Software schreiben.Das Argument scheint mir einfach nicht stichhaltig genug zu sein. Daher würde ich den "Performance-Fakt" hier als wichtiger einstufen. In Sachen Performance habe ich schon Beispiele gesehen, wo
dynamic
einfach zu exzessiv eingesetzt wurde.Grüssli
-
Dravere schrieb:
Firefighter schrieb:
Viel wichtiger als der Performance Fakt, aber dennoch richtig, finde ich den Compile-Time Sicherheits Fakt
Ich bin etwas gespalten über dieses Argument. Aus den folgenden drei Gründen:
1. Der Fehler passiert eher selten. Mir ist er noch gar nie passiert. Man passt hier besonders auf und zudem sind die betroffenen Codeteile meistens recht nah beeinander.
2. Falls man doch mal einen Fehler machen würde, wird spätestens der nächste Unittest dies anmeckern. Der Fehler dürfte sehr schnell korrigiert sein. In C# haben wir zudem nicht die wahnsinnig langen Kompilezeiten wie bei C++.
3. Es gibt viele Programmiersprachen, wo man diese Compile-Time-Sicherheit nicht hat und trotzdem lässt sich darin problemlos Software schreiben.Das Argument scheint mir einfach nicht stichhaltig genug zu sein. Daher würde ich den "Performance-Fakt" hier als wichtiger einstufen. In Sachen Performance habe ich schon Beispiele gesehen, wo
dynamic
einfach zu exzessiv eingesetzt wurde.Man darf hier schonmal Touche sagen
Trotzdem bin ich der Ueberzeugung, wenn ich Compile-Time Sicherheit geschenkt bekomme, was man in den Sprachen die du meinst nicht hat, dann will ich die auch ausnutzen bis zum Geht-Nicht-Mehr. Richtig ist auf jedenfall das es machbar in C# ist und das es im naechsten Unit-Test auffaellt wenn es kracht. Mein Argument zielte nur dahin ab das man sich immer Bewusst darueber sein sollte was man macht und was man damit verlieren/gewinnen kann.
-
Firefighter schrieb:
Trotzdem bin ich der Ueberzeugung, wenn ich Compile-Time Sicherheit geschenkt bekomme, was man in den Sprachen die du meinst nicht hat, dann will ich die auch ausnutzen bis zum Geht-Nicht-Mehr.
Eben gerade dieses "bis zum Geht-Nicht-Mehr" empfinde ich als falsch. Damit schränkst du dich womöglich unnötig ein. Womöglich kann es irgendwo mal sinnvoll sein, darauf zu verzichten, da es das Problem vereinfacht.
Man sollte halt jeweils immer nur so viel von etwas nehmen, wie es auch sinnvoll ist. Nur weil du gerne Zucker hast, kippst du auch nicht tonnenweise Zucker in den Kuchen
Firefighter schrieb:
Mein Argument zielte nur dahin ab das man sich immer Bewusst darueber sein sollte was man macht und was man damit verlieren/gewinnen kann.
Dagegen habe ich ja auch nichts gesagt. Mir ging es ja nur darum, dass du gesagt hast, dass du den Verlust der Kompilezeitsicherheit als wichtiger eingestuft hast. Dass man sich bewusst sein sollte, dass man diese Sicherheit verliert, ist sicherlich sinnvoll zu erwähnen. Man verliert zum Beispiel auch IntelliSense Möglichkeiten. Gewisse Tools reagieren sogar regelrecht allergisch auf diese
dynamic
KonstrukteGrüssli
-
Dravere schrieb:
Firefighter schrieb:
Trotzdem bin ich der Ueberzeugung, wenn ich Compile-Time Sicherheit geschenkt bekomme, was man in den Sprachen die du meinst nicht hat, dann will ich die auch ausnutzen bis zum Geht-Nicht-Mehr.
Eben gerade dieses "bis zum Geht-Nicht-Mehr" empfinde ich als falsch. Damit schränkst du dich womöglich unnötig ein. Womöglich kann es irgendwo mal sinnvoll sein, darauf zu verzichten, da es das Problem vereinfacht.
Man sollte halt jeweils immer nur so viel von etwas nehmen, wie es auch sinnvoll ist. Nur weil du gerne Zucker hast, kippst du auch nicht tonnenweise Zucker in den Kuchen
Firefighter schrieb:
Mein Argument zielte nur dahin ab das man sich immer Bewusst darueber sein sollte was man macht und was man damit verlieren/gewinnen kann.
Dagegen habe ich ja auch nichts gesagt. Mir ging es ja nur darum, dass du gesagt hast, dass du den Verlust der Kompilezeitsicherheit als wichtiger eingestuft hast. Dass man sich bewusst sein sollte, dass man diese Sicherheit verliert, ist sicherlich sinnvoll zu erwähnen. Man verliert zum Beispiel auch IntelliSense Möglichkeiten. Gewisse Tools reagieren sogar regelrecht allergisch auf diese
dynamic
KonstrukteGrüssli
Confirmed
-
Gute Argumente, Dravere.
Aber würdest Du dynamic häufiger einsetzen, wenn es nicht unter Performanceproblemen leiden würde?
Evtl. auch in Fällen, in denen es einfach nur bequemer wäre, eine typsichere Lösung zur Compilezeit aber mit Mehraufwand möglich wäre?Ich habe gerade einen ähnlichen Fall. Und zwar ein UserControl, dem ich ein "object Tag" hinzufügen musste. Auch da geht die Typsicherheit verloren und ich würde das UserControl nur zu gerne zu einem Generic machen. Leider spielt der Designer da nicht mit und Workarounds sind mir wieder zu viel Mühe.
.oO( Gelengentlich wünsche ich mir noch viel stärkere Typsicherheit für manche Anwendungsfälle, schon auf Ebene der Codeeingabe bzw IntelliSense. Viellicht auch TMP. Oder Contracts. Oder Static-Asserts. Oder einen typsicheren Präprozessor/Metacompiler/Whatever )
-
µ schrieb:
Aber würdest Du dynamic häufiger einsetzen, wenn es nicht unter Performanceproblemen leiden würde?
Evtl. auch in Fällen, in denen es einfach nur bequemer wäre, eine typsichere Lösung zur Compilezeit aber mit Mehraufwand möglich wäre?Das ist schwer einfach so pauschal zu sagen. Kommt ganz auf den Kontext an.
Es ist halt auch schnell mal eine Gefahr, dass man sich für
dynamic
entscheidet, nur weil man zu faul ist, etwas mehr Zeit in das Design zu stecken.dynamic
kann so zu einer schlechten Ausrede werden. Das ist natürlich nicht das Ziel. Wo diese Grenze zu finden ist, kann man wahrscheinlich nicht so richtig definieren.Ich sehe
dynamic
zum Teil auch noch gerne als einen Ersatz für dieTuple
Klasse. Die EigenschaftenItem1
,Item2
,Item3
, usw. derTuple
Klasse sagen einfach nichts aus. Da kann man mitdynamic
deutlich bessere Namen erhalten. Zudem muss man nicht kleine nichtsnützige Klassen schreiben, welche eigentlich völlig unnötig sind. Wenn somit keinerlei Performanceprobleme vorhanden wären, würde ich wahrscheinlichdynamic
z.B. als einen vollständigen Ersatz für Tuple durchaus sehen.µ schrieb:
.oO( Gelengentlich wünsche ich mir noch viel stärkere Typsicherheit für manche Anwendungsfälle, schon auf Ebene der Codeeingabe bzw IntelliSense. Viellicht auch TMP. Oder Contracts. Oder Static-Asserts. Oder einen typsicheren Präprozessor/Metacompiler/Whatever )
Da stimme ich dir zu. Habe schon mehrfach an einer eigenen Sprache gearbeitet (zumindest auf Papier ;)), welche sowas verfolgen würde. Die Sprache wäre quasi dazu gedacht, dem Kompiler mitzuteilen, wie er den Code generieren soll, welchen er dann kompilieren soll. Das Ganze kam bei mir aus der Idee heraus, dass man die TMP in C++ vereinfachen und mit den Makros verschmelzen könnte. Damit könnte man einfach Codegeneratoren schreiben, welche der Kompiler versteht, ohne auf Makros zurückzugreifen, wo dann ein Präprozessor zum Einsatz kommt, welcher keine Ahnung von der Sprache hat. Aber gut, das ist wieder ein ganz anderes Thema
Grüssli
-
Wow ich hab mich gerade gewundert wer da mit meinem Account nen Beitrag aufgemacht hat