WinFuture-Forum.de: out - Parameter nach && - IF-Abfrage nicht zugreifbar. - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Entwicklung
Seite 1 von 1

out - Parameter nach && - IF-Abfrage nicht zugreifbar.


#1 _nobido_

  • Gruppe: Gäste

geschrieben 12. April 2020 - 22:15 

class Program
    {
        static void Main(string[] args)
        {
            string _decimalValue1 = string.Empty;
            string _decimalValue2 = string.Empty;

            Console.Clear();
            Console.Write("Enter 1st. decimal value: ");
            _decimalValue1 = Console.ReadLine();

            Console.Write("Enter 2nd. decimal value to add to 1st. decimal value: ");
            _decimalValue2 = Console.ReadLine();

            // bool _success = float.TryParse(_decimalValue1, out float _number);

            if (float.TryParse(_decimalValue1, out float _number1))
            {
                
            }

            if (float.TryParse(_decimalValue2, out float _number2))
            {

            }

            if (float.TryParse(_decimalValue1, out float _number3) && float.TryParse(_decimalValue2, out float _number4))
            {

            }

            Console.WriteLine(_number1);
            Console.WriteLine(_number2);
            Console.WriteLine(_number3);
            Console.WriteLine(_number4);
            Console.ReadKey();
        }
    }



Ich steh grad bissl auf dem Schlauch...
... wieso ist _number4 nicht zugreifbar?
...also bei der Ausgabe auf die Console.

joar.
greetz && danke :)

*EDIT
Hm... die Loesung scheint wohl zu sein nur "&" zu verwenden.
Verstehe nur nicht warum...

Dieser Beitrag wurde von nobido bearbeitet: 12. April 2020 - 23:39

0

Anzeige



#2 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.565
  • Beigetreten: 14. August 15
  • Reputation: 414
  • Geschlecht:unbekannt

geschrieben 13. April 2020 - 06:45

Was ist das für Code? C, C++ oder JavaScript oder was?
AMD Ryzen 9 9950X3D, Asus ProArt X870E-Creator WiFi, 64GB Kingston Fury DDR6-6000, Asus Radeon 9070 OC 16GB, Creative Sound Blaster AE-7, 1x Intenso SSD 240GB, 1x M.2 WD_BLACK SN8100 PCIe 5.0, 2x M.2 WD_BLACK SN850X PCIe 4.0, 4x Acer G246HL Bbid, Logitech G502 Hero, Logitech G440 Mousepad, Logitech G413 SE, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#3 _nobido_

  • Gruppe: Gäste

geschrieben 13. April 2020 - 07:49

C#.

Also es scheint es liegt an der Verwendung von & und &&.
&& prueft short-circuit.

Und die IDE scheint so schlau zu erkennen dass der 1te Teil der Abfrage bereits zum Abbruch fuehren kann und der 2te Teil gar nicht mehr ausgefuehrt wird, ergo: der Veriablen dort auch nichts zugewiesen wird.

...find ich jetzt doof in anbetracht der Tatsache dass && viel performanter ist.

naja, ploeder fehler.

netten tag noch.

Dieser Beitrag wurde von nobido bearbeitet: 13. April 2020 - 07:49

0

#4 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.565
  • Beigetreten: 14. August 15
  • Reputation: 414
  • Geschlecht:unbekannt

geschrieben 13. April 2020 - 10:27

Beitrag anzeigenZitat (nobido: 13. April 2020 - 07:49)

Und die IDE scheint so schlau zu erkennen dass der 1te Teil der Abfrage bereits zum Abbruch fuehren kann und der 2te Teil gar nicht mehr ausgefuehrt wird

Eigentlich hat das mit der IDE weniger zu tun sondern eher mehr mit Unterschied zwischen den Operatoren & und &&.

Dieser Beitrag wurde von Gispelmob bearbeitet: 13. April 2020 - 10:28

AMD Ryzen 9 9950X3D, Asus ProArt X870E-Creator WiFi, 64GB Kingston Fury DDR6-6000, Asus Radeon 9070 OC 16GB, Creative Sound Blaster AE-7, 1x Intenso SSD 240GB, 1x M.2 WD_BLACK SN8100 PCIe 5.0, 2x M.2 WD_BLACK SN850X PCIe 4.0, 4x Acer G246HL Bbid, Logitech G502 Hero, Logitech G440 Mousepad, Logitech G413 SE, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#5 _nobido_

  • Gruppe: Gäste

geschrieben 13. April 2020 - 16:20

dass es an & und && liegt (letztendlich) ist mir auch (wieder) klar.
stichwort short circuit, wie ich bereits schrieb.


netten oster-montag noch.


*Edit OT


trotzdem weist mich die ide schon waehrend des schreibens des programm darauf hin dass es nicht funktionieren wird... was andere (rudimentaere) ide's nicht tun.

...

aber ich will da jetzt auch nicht weiter "streiten".

Dieser Beitrag wurde von nobido bearbeitet: 13. April 2020 - 16:25

0

#6 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.565
  • Beigetreten: 14. August 15
  • Reputation: 414
  • Geschlecht:unbekannt

geschrieben 13. April 2020 - 21:44

Ja, es gibt IDEs die analysieren den Code bereits bei der Eingabe, prüfen dann ob was sinnvolles dabei rauskommt und warnen gegebenenfalls. Dieses Verhalten ist oft schön, aber manchmal auch hinderlich.

Ingesamt macht micht bei deim Code aber etwas stutzig, dass die Warnungen nicht bereits schon vorher kommen.

1. du definierst Strings (string _decimalValue1) die Zahlen enthalten sollen
2. du setzt diese Strings auf leer (= string.Empty), obwohl Strings bei Definition bereits leer sind und die Länge 0 haben
3. du machst keine Prüfung ob auch tatsächlich Zahlen eingegeben wurden
4. du verwendest _number1 bis _number4 die vorher nicht definiert wurden

aber gut, einiges davon können auch C# Eigenheiten sein^^
AMD Ryzen 9 9950X3D, Asus ProArt X870E-Creator WiFi, 64GB Kingston Fury DDR6-6000, Asus Radeon 9070 OC 16GB, Creative Sound Blaster AE-7, 1x Intenso SSD 240GB, 1x M.2 WD_BLACK SN8100 PCIe 5.0, 2x M.2 WD_BLACK SN850X PCIe 4.0, 4x Acer G246HL Bbid, Logitech G502 Hero, Logitech G440 Mousepad, Logitech G413 SE, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#7 _nobido_

  • Gruppe: Gäste

geschrieben 14. April 2020 - 06:35

zu 1.: Ist doch voellig egal was darin enthalten ist, so es denn als string darstellbar ist.


zu 2.: Nun, ich zumindest deklariere entweder ein handle string _decimalValue1;, dann hat dieses den Wert bzw. verweist auf Null. Oder ich deklariere ein handle und initialisiere es dabei gleich string _decimalValue1 = ""; bzw. string _decimalValue1 = String.Empty;
Abgesehen vom StringBuilder und anderen Spezialitaeten und Umstaendlichkeiten ... fehlt mir da jetzt die Fantasie.
Sicher, aus oekonomischen Blickpunkten gesehen koennte ich jetzt auf die Erstzuweisung eines Wert warten. Bis der tatsaechlich genutzte Wert ueber die Console eingegeben wurde - aber so zeit-kritisch ist es in diesem Fall (noch) nicht. Und String.Empty ist doch auch viel lesbarer.

zu3. Doch, doch. Da wird schon geprueft. xxx.TryParse ist eine nette Erweiterungs-Methode und erledigt elegant gleich mehrere Dinge: wandelt den eingelesenen Wert um, soweit er denn wandelbar ist, und schreibt ihn per out-Parameter in eine Variable, so der gewandelte Wert denn im Gueltigkeitsbereich der Variablen liegt und nicht gegen die Formatierungsregeln der Variablen verstoesst. Und gibt am Ende True/False zurueck um zu signalisieren ob die Umwandlung erfolgreich war. Deswegen funktioniert die If-Abfrage ja auch.
(Ich liebe solche Methoden - mit denen laesst sich "geiler" Code schreiben, allerdings ist der oft schnell unleserlich).

Die If-Abfragen lassen sich auch entzerren:
float _number1;
bool _success;
_success  = float.TryParse(_decimalValue1, out _number1);
if(_success == true)
{

}

Aber das waere der Leserlichkeit dann doch zu viel Gutes getan :P

Und was 4. angeht: Da wird nix undeklariertes verwendet. Die Deklaration findet im Kop der If-Abfrage statt: float.TryParse(_decimalValue1, out float _number1) ist in C# durchaus erlaubt - wir sind da nicht so steif-formal wie die java-fuzzies und C-progger (!C/C++). Wie geschrieben: 's laesst sich geiler Code schreiben (nicht unbedingt meiner jetzt), der aber schnell unleserlich ist.

So, nu is aber Ende.
Der Hund will raus.

tschoe

Dieser Beitrag wurde von nobido bearbeitet: 14. April 2020 - 06:42

0

#8 Mitglied ist offline   RalphS 

  • Gruppe: aktive Mitglieder
  • Beiträge: 8.889
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 14. April 2020 - 06:38

Das Problem ist, daß hier zuviel zusammengeworfen wird (cf Side Effects bei der Programmierung).

Das, und Coderedundanz.

Besser wäre es, in einem ersten Schritt das TryParse auszuführen:

readonly bool Parse1Success = TryParse(var1, out result1);
readonly bool Parse2Success = TryParse(var2, out result2);

Jetzt hat man in den beiden Booles einen definierten Status (true/false) und in Abhängigkeit davon jeweils einen oder keinen gültigen Zahlwert. Die Side Effects sind damit raus, weil die Ausführung der Methode nicht mehr bedingt ist. Im Anschluß kann man dann nach Bedarf auf Parse1Success und Parse2Success beliebige logische Operationen ausführen.

Ich nehm mal an, daß die anderen beiden TryParse nur zum Testen da waren. In jedem Fall ist TryParse exakt einmal pro Input auszuführen, nicht öfter. Genügt auch völlig.

Note, das Readonly kann man je nach Kontext natürlich auch als sowas wie bool ParseSuccess => TryParse(input, out parsedValue); definieren.
Note 2, weil's im Text oben nicht hervorgeht: result1 und result2 sollten vorher irgendwo im richtigen Datentyp deklariert worden sein.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0