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#2196568

    Dravere 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 🙂


  • Administrator

    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.


  • Administrator

    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 Konstrukte 🙂

    Grü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 Konstrukte 🙂

    Grü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 )


  • Administrator

    µ 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 die Tuple Klasse. Die Eigenschaften Item1 , Item2 , Item3 , usw. der Tuple Klasse sagen einfach nichts aus. Da kann man mit dynamic 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 wahrscheinlich dynamic 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 😃


Anmelden zum Antworten