Moin moin.

Bevor hier wieder große Aufschreie kommen, weil ich Option Strict auf OFF habe: Ich studiere Maschinenbau und keine Informatik. In unserer Verlesung zu Hochsprachenprogrammierung hat man es uns ohne Option Strict auf ON gezeigt. Ich würde es auch selbst mit Option Strict ON machen, habe aber nicht die Zeit mich damit auseinander zu setzen. Denn Hoschsprachenprogrammierung ist nicht das einzige Fach mit dem ich mich beschäftigen muss und bei weitem auch nicht das wichtigste. Also bitte tut mir den gefallen und seht über Option Strict einfach mal hinweg.


Erstmal ein Ausschnitt meines Quellcodes:


Der Teil des Programms macht folgendes:
Es werden 2 Werte (Position und Kraft) eingelesen und auf fortlaufenden Variablen abgelegt. Zuvor wird überprüft, ob die Werte nummerisch und positiv sind und keinen "." enthalten.

Das ist aber noch nicht alles: Mein Problem betrifft nun die Zeilen 12-18
Es soll zusätzlich überprüft werden, ob der erste Wert (Position) schonmal eingegeben wurde, bevor er auf der nächsten Variablen gespeichert wird.
Jetzt komme ich aber nicht weiter. Denn wenn der Wert tatsächlich schonmal eingegeben wurde, soll wieder angefangen werden eine Eingabe zu fordern. Ich will also aus der If-Abfrage in den oberen Teil meines Quellcodes zurückspringen (wie ich mit dem Kommentar angedeutet habe). Geht das überhaupt? Und wenn ja, wie?

Und wo ist jetzt das Problem?

ElBarto schrieb:

Also bitte tut mir den gefallen und seht über Option Strict einfach mal hinweg.

Ich persönlich habe damit weniger ein Problem.

Aber ich finde die Begründung etwas - nunja - seltsam. In der Regel ist die Programmierung, wenn Option Strict von vornherein auf ON eingestellt ist, wesentlich einfacher und weniger fehleranfällig. Und die IDE unterstützt dich dabei zudem. Du tippst deinen Code meist weiterhin so als wäre Option Strict Off. So mach ich es jedenfalls meistens. Ich schere mich nicht um korrekte CTypes oder DirectCasts und lass die IDE mir den dann daraus resultierenden Fehler unterschlängeln. Dann drücke ich auf meiner Tastatur einfach "Strg+Punkt" und dann "Return" - schon hab ich den korrekten Typecast. Auf der anderen Seite sehe ich an Fehlern, die aus dem Einschalten der Option resultieren an Stellen, wo ich mit solchen Fehlern allerdings nicht rechne, dass ich wohl etwas übersehen habe und korrigieren sollte, was ich ohne Option Strict On NIE gesehen hätte (zumindest nicht bevor es dann im Programm an der Stelle knallt).

Nachtrag: Zu deinem eigentlichen Problem: Ich glaube "Continue Do" ist hier die Lösung.

Danke! Das Funktioniert einwandfrei

Ich weiß, für jemanden, der viel programmiert ist meine Begründung für Option Strict bestimmt etwas seltsam.
Aber wenn einem noch diverse andere Prüfungen vor der Nase schweben, die deutlich schwieriger und wichtiger sind, und man vorher noch nie programmiert hat, dann ist der Zeitaufwand im Verhältnis zum Nutzen zu hoch um sich selber beizubringen wo die Unterschiede zwischen Option Strict ON und OFF liegen.
Da mach ichs lieber so, wie es mir gezeigt wurde. Ich will auch kein professioneller Programmierer werden, höchstens mal die ein oder andere kleine Anwendung für mich selbst erstellen. Die Programme laufen bisher auch immer. Der Sinn dieser Veranstaltung liegt auch vielmehr darin auch als Maschinenbauer zu erkennen, was mit Programmen alles möglich ist, um bei Bedarf einen Informatiker hinzuziehen zu können, der dann ein Programm erstellen kann.

ElBarto schrieb:

Ich will auch kein professioneller Programmierer werden,

sondern einer, der mit Option Strict Off permanent Typ-Probleme hat und infolge mangelnder Erfahrung permanent wegen "nichts" je einen neuen Thread aufmacht.

hi!

also dein "Lern-Konzept": Grundlagen erstmal zu überspringen, um schneller voranzukommen, mag in diesem besonderen Fall sogar mal aufgehen.

Aber falls du jemals was programmieren willst, ist dieses Konzept die 100%ige Katastrophe.
Beim Proggen darf man sich keinerlei ZeitDruck unterwerfen.
Es ist immer wesentlich effizienter, die Grundlagen unverzüglich aufzuholen, sobald sich eine Lücke im KnowHow offenbart.
So magst du etwa 3/4 der Entwicklungszeit eines kleinen Projektes mit Grundlagen-Aufholen zubringen, aber am Ende bist du immer noch schneller, als wenn du dich ohne die Grundlagen bis zum Ziel durchgewurstelt hättest.

Übrigens sieht man deim Code garnet an, dasser Strict Off ist
Er hat zwar vielerlei(!) Mängel, aber eine verborgene, riskante TypKonvertierung, wie sie bei Strict Off so leicht unterläuft, finde ich grad nicht auf die Schnelle.

Also man kann auch Strict Off sauber proggen, nur leider kannmans auch lassen - und merkt das nichtmal

edit: ach doch - hier sieht mans:

@ RodFromGermany:
Danke für diese Unterstellung und einen Beitrag von dir der keinen Wert hat. Meine bisherigen Beiträge behandelten Themen, in denen es um mangelnde Kenntnis über Befehle oder über grundsätzliche Fragen darüber ging, wie man etwas umsetzen kann.

@ ErfinderDesRades:
Wie gesagt, ich beschäftige mich gerne damit, aber im Moment hab ich dazu keine Zeit. Frage mich selbst auch, warum unser Professor das nicht gleich mit Option Strict ON erklärt, wenn es doch nur wenig anders aber dafür um so vieles sicheres ist. Ich denke, es liegt einfach an dem gerimgem Umfang den wir nur behandeln können, und daran dass die Programme, die wir zur Übung erstellen, so klein und simpel sind, dass deren Fehlerpotential von Haus aus gering bleibt.

Edit: Ich sehs aber nicht

ElBarto schrieb:

Frage mich selbst auch, warum unser Professor das nicht gleich mit Option Strict ON erklärt, wenn es doch nur wenig anders aber dafür um so vieles sicheres ist.

Das liegt meist daran, dass Lehrkräfte selbst keine Ahnung haben.
Muss man leider so deutlich aussprechen.
Bei deim Prof trifft das ganz offensichtlich zu: Guck - indem du diesen Thread eröffnest, und gleich drauf eingehst, zeigst du, dass du mehr Ahnung von Programmierung und von Datentypen hast, als er.

ElBarto schrieb:

Edit: Ich sehs aber nicht

Dassis das Problem - dass dus nicht siehst.
Sowas sieht man, wenn man seine Datentypen kennt.
Und bei Strict On kriegt mans auch gezeigt, sodass man seine Datentypen eben kennenlernt.
Bei Strict Off bleibt man dumm.

ElBarto schrieb:

und einen Beitrag von dir der keinen Wert hat.

Offensichtlich bist Du nicht bereit zu lernen.
Es ist ja nicht so, dass ich mir solch einfach so aus den Fingern sauge, sondern da ist schon ein ganz klein wenig Erfahrung eingeflossen, zumal ich bereits den einen und den anderen Post geschrieben
und
dem einen und dem anderen Forumsmitglied geholfen habe.

@ RodFromGermany:
Ich habe klar dargelegt, warum ich mich jetzt nicht intensiv mit dem Thema beschäftigen kann. Wenn du meine Posts nicht liest, sie nicht verstehst oder meine Meinung einfach nicht nochvollziehen kannst oder willst, so ist das dein gutes Recht. In dem Fall solltest du dich einfach aus der Diskussion raushalten und sie nicht weiter behindern.

@ ErfinderDesRades:

ErfinderDesRades schrieb:

edit: ach doch - hier sieht mans:

VB.NET-Quellcode

1. Console.Write(iAnzahlPositionen + 1 & ". Kraft eingeben: ")

Ich versuche mich mal daran zu ergründen, was hier der Fehler ist, den man bei Option Strict OFF nicht sieht:

"Console.Write" gibt Zeichenketten (Strings) aus. "iAnzahlPositionen + 1" ist jedoch ein Integer. Stimmt soweit oder?
Ich gebe also einen Datensatz von Typ Integer direkt als String aus ohne vorher extra einen Befehl zu schreiben (ich vermute mal, bei Strict ON müsste man das), in dem der Integer Typ in einen String umgewandelt wird. Ist das der Kern des Problems von Option Strict OFF?

Falls ich das so richtig sehe, verstehe ich das Problem aber nicht. Schließlich lässt sich ein Interger jederzeit problemlos als String weiterverarbeiten, oder etwa nicht?

ElBarto schrieb:

oder meine Meinung einfach nicht nochvollziehen kannst oder willst,

Du wirst Threads eröffnen, die nicht erforderlich wären, wenn Du gleich Option Strict On machen würdest. Das möchte ich verhindern. außerdem gewöhnst Du Dir einen ordentlichen Programmierstil an.

VB.NET-Quellcode

1. Console.Write(iAnzahlPositionen + 1 & ". Kraft eingeben: ")

ich hab mich geirrt - selbst diese Zeile kompiliert unter Strict On.

ErfinderDesRades schrieb:

ich hab mich geirrt - selbst diese Zeile kompiliert unter Strict On.

Ohne es jetzt nachzuschlagen, vermute ich das "&" als Übeltäter, das als String-Verkettung automatisch die Operanden in Strings umwandelt bzw. implizit ToString() aufruft.
In C# wird es aber vermutlich nicht funktionieren, insbesondere da C# IMHO den Operator & (bzw. einen vergleichbaren String-Verkettungsoperator) nicht kennt.
Was übrigens der Grund ist, warum ich seit .NET den Operator & bei Strings ähnlich meide wie viele andere hier den Microsoft.VisualBasic-Namensraum (aus dem der Operator vermutlich sogar stammt).

naja - man sollte eben immer die Doku lesen - bei egal was

@ElBarto:: Deine und meine Überlegungen sind ganzngar richtig: Ein String ist kein Integer, und deshalb sollte Strict Off meckern. Deine Überlegung ist sogar noch richtiger:

Schließlich lässt sich ein Interger jederzeit problemlos als String weiterverarbeiten, oder etwa nicht?

So sieht das nämlich die Doku des &-Operators auch:

Doku schrieb:

Wenn der expression1-Datentyp oder der expression2-Datentyp nicht String ist, jedoch zu String erweitert werden kann, wird er in String konvertiert.

Was bedeutet "erweitern" genau?
Das bedeutet, dass ein anderer Operator definiert ist, nämlich der Widening CType-Operator.
Und für Integer->String isser definiert, aber nicht annersrum.

Obwohl man auch mit Strings rechnen kann. Zumindest wenn in den Strings zufällig ein Wert steht, der auch in Integer, Double etc umgeadelt werden kann.

Ich habe meinen Professor mal zur Rede gestellt was Option Strict: ON/OFF betrifft, also ob er weiß was das ist und warum wir mit OFF arbeiten. Sinngemäß hat er folgendes geantwortet:

"Mit Option Strict, die bei uns standardmäßig auf "Off" steht, regelt man, ob die automatische Konvertierung (sog. Casting) zwischen Datentypen erlaubt ist (bei "Off") oder aber eben nicht (bei "On"). Wenn die Option Strict auf "On" gesetzt wird, ist z.B. die Umwandlung eines Strings in eine Zahl durch eine einfache Zuweisung der Form ("dZahl = strZahl") nicht mehr möglich. Man müsste dann derartige Umwandlungen explizit anweisen (z.B. durch "dZahl = Convert.ToDouble(strZahl)" oder auch "dZahl = CDbl(strZahl)"). In professionellen Softwareprojekten ist diese Einstellung unbestritten durchaus üblich und auch sinnvoll."
Und weiter
"In der für Programmieranfänger konzipierten Vorlesung Hochsprachenprogrammierung, die ja nicht mit einer aufbauenden Veranstaltung fortgesetzt wird und dementsprechend auch keine Studierenden mit Informatik-Schwerpunkt adressieren kann und soll, geht es aber zunächst um ganz andere und in meinen Augen wichtigere und grundlegendere Probleme der Programmierung (und das in einem eng gesteckten Zeitrahmen von 90 min pro Woche für 13 Wochen)."


Wenn ich mir diese Erklärung so anschaue, dann ist es für mich kein wunder, dass wir nicht mit Option Strict ON programmieren. Es würde den Rahmen sprengen und macht bei unseren eher simplen Programmen eh keinen Unterschied (mal abgesehen von ein paar mehr Zeichen im Quellcode bei Strict ON).
Mangels Erfahrung kann ich mir auch noch keinen Fall vorstellen, bei dem ein Fehler auftreten könnte, wenn man eine automatische Konvertierung zulässt. Wenn ich "dZahl" als Double deklariere und "strZahl" als String, kann bei automatischer Konvertierung auch nichts schiefgehen, was bei Strict ON nicht auch schief gehen könnte. "strZahl = dZahl" funktioniert genauso zuverlässig wie bzw "strZahl = Convert.ToString(dZahl)" und der umgekehrte Fall "dZahl = strZahl" bzw " "dZahl = Convert.ToDouble(strZahl)" führt genauso zum gleichen Ergebnis: Lässt sich der String in einen Double umwandeln funktionierts; lässt sich der String weil es z.B. ein Text ist nicht in einen Double umwandeln stürzt das Programm ab.


Ich werde das Thema weiter im Hinterkopf behalten und mich auch mal versuchen weiter damit zu beschäftigen. Aber fürs erste werde ich mit Option Strict OFF weitermachen.

@ RodFromGermany oder jedem anderem User, der mal über einen Thread von mir stolpern sollte:
Sollte ich in Zukunft hier auch nur einen einzigen Quellcode posten, der nicht funktioniert, weil mit Option Strict OFF programmiert wurde, dürft ihr es mir gerne unter die Nase reiben. Ich verspreche hiermit: Ab dem Zeitpunkt werde ich Option Strict dauerhaft auf ON setzen und mich intensiv mit dem Thema beschäftigen bevor ich erneut irgendwas hier posten werde.

ElBarto schrieb:

Ich habe meinen Professor mal zur Rede gestellt was Option Strict: ON/OFF betrifft

Find ich gut.

ElBarto schrieb:

dürft ihr es mir gerne unter die Nase reiben.

Werden wir.
Lass Deinen Prof mal in das Forum hier reinschauen und ggf. an der Diskussion teilhaben.
----
Strict Off wäre etwas übertrieben etwa so was:
(D)ein Programm soll eine Vektorgrafik laden, bekommt aber eine Pixelgrafik vorgesetzt und macht etwas für Grafiken sinnvolles, das sich aber für dieses Programm als ungeeignet bis katastrophal erweist, weil der Compiler und nicht der User festlegt, wie die Typen konvertiert werden.

@Arby: @ErfinderDesRades: Mich hat das jetzt mal interessiert und ich hab's mir angesehen.
Hier die Codeschnipsel:

Bei VB funktioniert der +-Operator nur, wenn beide Operanden vom Typ String sind (und natürlich die Addition bei numerischen Typen). Wenn einer von beiden String ist und der andere Integer, dann funktioniert's nicht!
Der &-Operator funktioniert mit allen Datentypen, die "einfach" nach String umgewandelt werden können. Wie das genau ausgewählt wird, weiß ich nicht. Es ist jedoch so, dass die Operanden mittels Microsoft.VisualBasic.CompilerServices.Conversions.ToString() nach String umgewandelt werden. Da gibt's Überladungen für alle primitiven Datentypen und auch für Object, jedoch meldet Visual Studio bei Console.WriteLine(StringValue & ObjectValue) das:

"Option Strict On" lässt keine Operanden des Typs "Object" für den &-Operator zu.

, was eigentlich Blödsinn ist, weil es gibt ja eigentlich eine Überladung für Obejct.
Sobald die Operanden nach String konvertiert wurden, wird String.Concat(String, String) verwendet, um die Strings zu verknüpfen.

In C# sieht die Sache anders aus:
Wenn beide Operatoren Strings sind, ist die Sache klar: Es wird String.Concat(String, String) verwendet, um die Strings zu verknüpfen.
Wenn keiner der Opeatoren ein String ist, wird nach einem passenden Additions-Operator gesucht. Das hat dann logischerweise nichts mehr mit Stringverknüpfung zu tun (ein Beispiel wäre Integer + Integer)
Wenn einer der beiden Operatoren ein String ist, werden die nicht-String-Operatoren, die Wertetypen sind, geboxt und dann wird einfach String.Concat(Object, Object) verwendet, was dann einfach die Object.ToString()-Funktion für jeden Parameter aufruft, und die Strings dann an String.Concat(String, String) weitergibt.
(Edit: In C# gibt's den &-Operator übrigens nur als bitweise AND-Verknüpfung. Also das, was in VB der AND-Operator ist.)

Ich kann jedem empfehlen, einfach mal ein Minimalprogramm zu kompilieren und es mit ILSpy oder ähnlichen Programmen zu dekompilieren. (Die Ansicht natürlich auf IL-Code umstellen ).


Persönlich fand ich es schon immer schrecklich, wenn Leute bei der Stringverknüpfung alles implizit konvertieren lassen. Ich schreibe immer selbst .ToString dazu. Allein schon weil ich nie sicher war, ob da nicht irgendein Blödsinn kompiliert wird.
Edit aus der Zukunft (März 2017): Inzwischen hat sich das etwas geändert. Ich habe ein Gefühl dafür entwickelt, was ich implizit konvertiert haben will und was nicht. Spart Schreibarbeit.

@ElBarto:: IMO, was dein Prof von sich gibt, ist schön ausgedacht, hat aber kein Bestand.
Entweder man lehrt eine Sache richtig, oder mans solls lassen. Falsches lehren heißt Anfänger verderben, denn wenn der Unfug erstmal im Kopf ist, ists ungemein schwierig, den wieder rauszukriegen. Das ist sogar eine Erkenntnis der Lernforschung, dass man um ein vielfaches besser lernt ganz ohne Grundlage, als wenn die Grundlage falsch gelegt ist.

Offenbar ist bei deim Prof selbst die Grundlage falsch gelegt, und hier siehst du, wie verheerend das ist.
Wassich sage: Der Lehrkörper hat oft keine Ahnung. Ist unerhört und unverschämt, das zu sagen, aber es ändert sich auch nix dran, wennmans nicht sagt.

Option Strict Off verschleiert das Konzept der Datentypen.
Welches zB. aussagt, dass Zahlen zum rechnen da sind, Texte zum lesen und schreiben.

Das Konzept der Datentypen ist sogar grundlegender als alle sonstigen objektorientierten Hochsprachen-Konzepte, denn bereits die niederen Sprachen bauen darauf auf.
Ich finds abstrus, dass er behauptet, es gebe wichtigere Dinge zu lernen.

Das ist ungefähr wie Integralrechnung lehren, aber die 4 Grundrechenarten überspringen.
Glaub mir: Integralrechnung ist einfacher mit den 4 Grundrechenarten als ohne! (und so sind auch die Hochsprachen mit Typisierung einfacher)