Suchergebnisse

Moin Leute, mal eine Frage an diejenigen hier, die andere ermutigen Option Strict On zu verwenden: Ich lese hier immer nur "Verwende bitte Option Strict On", aber ich habe bisher keine Begründung dafür in diesem Forum entdeckt. Ich programmiere zwar selber überwiegend strikt, aber ich komme auch aus dem C#-Sektor und bin nur aufgrund meiner Arbeitsstelle auf Visual Basic umgestiegen. Da gerade so Dinge wie late binding und ein gering strikter Programmierstil eigentlich der elementare Unterschied…

Ja ist ein guter Einwand. Aber dann richtet sich der Tipp meiner Meinung nach eher an Neulinge im Bereich VB als Erleichterung für die Arbeit. Mich würde es an einigen Stellen eher behindern, wenn ich überall auf implizite Konvertierungen verzichten würde.

Moin @VaporiZed, danke dir für deine Anwort. Und deine Antwort in diesem Thread ist auch wie von dir gewohnt sauber erklärt und richtig, sehe ich absolut genauso. Es geht mir in diesem Thread auch weniger um die Vorteile von Option Strict On sondern vielmehr um das was von Visual Basic übrig bleibt, wenn ich Option Strict On verwende. Meine Frage zielt eher darauf ab, zu verstehen, warum ich Visual Basic verwenden soll, wenn ich mir den einzigen Vorzug gegenüber C#, nämlich dass der Compiler mir…

@ErfinderDesRades: Ja, genau das habe ich mir nämlich auch gedacht, die Syntax ist einfach angenehmer. Ich lasse den Thread noch ein wenig offen, vielleicht hab ich ja tatsächlich noch was übersehen oder nicht bedacht. Vielen Dank auf jeden Fall an alle die so schnell geantwortet haben. @EaranMaleasi: Ist wahrscheinlich echt nur ein historisches Ding. Und die Bedeutung deines letzten Satzes in Bezug auf Microsoft ist klar. Beide Sprachen sind gleich, aber eine ist halt gleicher als die andere

@RodFromGermany: Entschuldige aber das kann ich so nicht stehen lassen. zum Thema Compiler-nah: In Bezug auf die ursprünglichen Compiler und die MSIL hast du natürlich Recht, da gibt es wenige Unterschiede, aber Microsoft hat mit Projekt Roslyn vor Jahren angefangen einen offenen Compiler zu entwickelt, mit dessen Hilfe dir ein Großteil der Compiler-Funktionen per dll im .NET geöffnet werden. Bedauerlicherweise hat Microsoft die vollständige Funktionalität bis heute nicht in Visual Basic integri…

@EaranMaleasi: Hab unsafe ehrlich gesagt noch nie benutzt, dachte immer das wäre dafür da, Typisierungen zu umgehen. Danke für die Richtigstellung An Dynamic habe ich noch gar nicht gedacht, aber da hast du absolut Recht. Spätestens hier haben wir auch in C# eine Möglichkeit die Tyisierung zu umgehen.

C#-Quellcode (2 Zeilen) VB.NET-Quellcode (2 Zeilen) Beide Beispiele lösen keine Kompilierzeitfehler aus... Demnach ist meine Aussage richtig, dass ich eine explizite Typisiserung über Dynamic umgehen kann. Zitat: „Nein hast Du nicht. Dynamic legt den Typ erst zur Laufzeit fest“ Und was macht VB.NET bitte in meinem oben genannten Beispiel? Richtig, genau das gleiche. Zitat: „Wogegen Du bei Option Strict Off eine Variable vom Typ Integer mit einem String belegen kannst“ "kannst" ist hier das richt…

Kenn ich, hab ich für den Umstieg einige Mal benutzt. Aber danke, dass du darauf aufmerksam machst. Sollte in diesem Thread auf jeden Fall erwähnt werden. EDIT: Ich denke die Debatte kann man endlos fortsetzen, aber meine Hauptfrage ist denke ich geklärt. Danke nochmal an alle. Ich schließe den Thread jetzt.

Unterscheide bitte zwischen Kompilierzeit und Laufzeit. Dynamic legt den Typ zur Laufzeit auf einen Integer-Wert fest. VB.NET legt den Typ ebenfalls erst zur Laufzeit fest. Wie ich vorher schon geschrieben habe, lösen beide Fälle keine Kompilierzeitfehler aus. Einziger Unterschied: VB.NET konvertiert intern den Integer-Wert zu einem String. Das macht C# nicht. Hat aber nichts mit der Aussage zutun, dass ich den Datentypen NICHT angeben muss, was beweist, das auch in C# eine implizite Typisierung…

Zitat von SpaceyX: „Eine implizite Typisierung ist aber was Anderes.“ Ah okay, jetzt verstehe ich warum wir aneinander vorbeireden. Du musst unterscheiden zwischen implizite Typisierung und implizite Konvertierung. Wir reden hier die ganze Zeit von zwei unterschiedlichen Dingen.