* Uofficiel Black/White liste V3
|
Denne tråd er over 6 måneder gammel
Er du sikker på, at du har noget relevant at tilføje?
Nybegynder C# hjælpAf Ultrabruger JFBN | 07-11-2013 19:47 | 2484 visninger | 34 svar, hop til seneste
Hej HOL
Jeg er igang med Datatekniker med speciele i programmering uddannelsen, og jeg sidder og lejer lidt med det her hjemme - men er stødt ind i et problem, som vi ikke har lært at håndtere endnu..
Problemet ligger her;
Console.SetCursorPosition(2, 4);
Console.WriteLine("Tast 'F' for at komme igang.");
svar = Console.ReadLine();
if (svar == "F")
{
Console.Clear();
Console.SetCursorPosition(2, 2);
Console.WriteLine("Hvad er dit fornavn?");
fornavn = Console.ReadLine();
}
Jeg ved godt jeg ikke har angivet nogen "else" endnu, ved heller ikke om det er nødvændigt.
Det jeg håber at få gjort, er at den skal blive ved med at køre:
Console.WriteLine("Tast 'F' for at komme igang.");
svar = Console.ReadLine();
Indtil det er "F" der bliver trykket.
Hvordan kan jeg gøre dette?
Har forsøgt mig at lave en "else" som ser sådan her ud:
else
{
goto komigang;
}
og så skrive "case komigang:" før den første code.
Hvad skal jeg gøre?
Beklager nyhed. --
while (svar != "F") {} -- +1 indlæg = *PUFF*
svar = Console.ReadLine();
while (!svar.Equals("F")) {
svar = Console.ReadLine();
}
// Her er vi sikre på at "F" er blevet trykket på
Console.Clear();
Console.SetCursorPosition(2, 2);
Console.WriteLine("Hvad er dit fornavn?");
fornavn = Console.ReadLine();
Prøv dette.
#1 Er det "kun" i Java at == (og !=) er farlig at bruge i forbindelse med sammenligning af String-objekter? Jeg husker ikke lige hvordan det er i C#. -- http://tinyCode.dk[...] Har ikke mulighed for at teste det lige nu.
Vil overstående bare fortsætte, indtil der bliver tastet F?
Hvis der bliver tastet andet, så skriver kører den blot;
Console.SetCursorPosition(2, 4);
Console.WriteLine("Tast 'F' for at komme igang.");
svar = Console.ReadLine();
igen? -- #3
Nej, ikke helt. Den bliver ved med at lave en ny linje, indtil du har tastet F.
Den "renser" ikke skærmen og prompter hver gang.
#2
nej, det er det reelt også i C#.
Jeg brugte alene == fordi #0 selv havde gjort det, i håb om, at han kunne gennemskue hvad det hele gik ud på. -- +1 indlæg = *PUFF* For ikke at gentage statements, så vend din while-løkke om:
do {
Console.WriteLine("Tast 'F' for at komme igang.");
svar = Console.ReadLine();
} while (svar.toUpper() != "F"); -- http://xlinx.dk[...]
i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK Hvad er der farligt ved at sammenligne strenge i C# ? -- #6 Det er muligt, at compileren misforstår sammenligningen, og sammenligner strengobjekterne (referencerne / pointerne) i stedet for deres indhold. Skal man være på den sikre side, skal man bruge "a.Equals(b)" i stedet for "a == b". -- http://xlinx.dk[...]
i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK #7 Hvad er det for noget vrøvl? Jeg sammenligner dagligt strings med == operatoren...
Har du noget reelt der kan underbygge det fakta? -- try { write crappy code that might fail }
catch { don't care } #9 Men why? En note der fortæller det er da stadig ikke noget der reelt forklarer mig hvorfor? -- try { write crappy code that might fail }
catch { don't care } #10 Ifølge http://stackoverflow.com[...] svarer "==" til metodekaldet .Equals(...) på objektet der sammenlignes, f.eks. vil a == b være det samme som a.Equals(b). Ifølge den kommentar, altså.
Men hey, hvis du lever op til din signatur er der jo ingen problemer med at du ikke gider opretholde en hvis standard i din kode. For nogen er programmering et værktøj, for andre er det en kunst.
Hver mand sin smag. -- http://tinyCode.dk[...] #8 Jeg kan ikke underbygge det, og snakker fra min erfaring med Java (og pointere generelt), hvor det kan blive et problem. Jeg bruger kun "==" hvis jeg har en konstant i sammenligningen, da compileren så ikke kan misforstå noget.
string a = "abc";
string b = "abc";
//Virker altid:
bool equal1 = (a == "abc");
//Virker sandsynligvis:
bool equal2 = (a == b);
Der kan opstå problemer i "equal2", da compileren kan misfortolke sammenligningen til "&a == &b" (altså objekt-referencerne fremfor strengene), og det kan undgåes ved at bruge a.Equals(b). -- http://xlinx.dk[...]
i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK #12 Fair nok, men nu snakker vi jo C# og selvom jeg kan læse en note om hvor det frarådes, så vil jeg stadig gerne se et reelt eksempel på hvorfor jeg fremover skal undlade at bruge == med strings.
Og jeg kan også læse mig frem til at Java har lidt problemer på det område, men nu snakker vi meget simple strings og som nævnt også C# :) -- try { write crappy code that might fail }
catch { don't care } Nu koder jeg dagligt i C#, og jeg må støtte op om Equals fremfor ==
Her er et eksempel hvor det ikke vil virke :)
"Dude" == "Dude" //Vil måske virke, men
"Dude" == new String("Dude") //Vil ikke, pga new String("Dude") laver en ny String instans, og bryder mulig lighed mellem pointerne.. -- #19 Du har netop ødelagt en sur mands aften. Tillykke. :)
/Ironi off
#18 Hvis du ikke en gang gider læse materialet jeg kommer med igennem, kan jeg ikke se hvordan vi kan føre en samtale. Mht. mit arbejde kan du jo finde mig på LinkedIn - nej, det er ikke C# jeg arbejder med til dagligt. -- http://tinyCode.dk[...] #19 Yay! Tak for et reelt eksempel :)
Ud fra det vil jeg så også sige at hvis man ved hvad man laver, så er == fint at anvende til strings. Når jeg skriver jeg andvender det dagligt så er fordi jeg ikke er ude i ny instanser, men sammenligner i et LINQ statement. Oftest noget alla (x => x.SomeString = "SometingSomething")... -- try { write crappy code that might fail }
catch { don't care } Hold da op en diskussion jeg fik startet. Synes der er lidt misforståelser. Compileren "misforstår" ikke noget, spørgsmålet er om vi som programmører forstår hvad det er vi beder den om at sammenligne.
Det er jo ikke sådan at compileren nogensinde kommer til at misforstå nedenstående:
while(true){
if("test"!="test"){
Console.WriteLine("Hov, her lavede compileren da en fejl");
}
} -- #29 Det kan aldrig blive din skyld at der skal spilles med "store if-sætninger" overfor hinanden (for nu lige at holde det lidt over i programmerings verden) :D
Fandt du overhovedet ud af svaret på spørgsmålet? :) -- D: #29 Som #11 skrev er programmering en kunst og derved er der også mange måder at gøre tingene på. Men nu er programmering også logisk så der følger altid en forklaring med... Troede jeg.. :)
Men ja, "test" == "test" er at sammenligne 2 strings og compileren er helt med.
#19's eksempel er heller ikke helt legit. Visual Studio brokker sig ved:
if ("test" == new String("test"))
{
}
Med:
Cannot resolve constructor 'String(string)'.
Så det eksempel holder heller ikke eftersom du ikke engang kan compile...
Eneste jeg kan finde frem til er at == og != sammenligner værdien og er altså fuldt ud dygtig til at varetage en "string comparison"... -- try { write crappy code that might fail }
catch { don't care } String objekter i c# er unikke, dvs at der kun findes én streng med et givet indhold i din .net process. Der er altså en stor hashtabel der holder styr på alle strenge, så der aldrig findes duplikater.
Så derfor er simpel pointersammenligning helt fint. Hvis det frarådes at skrive == nogen steder må det være i forhold til portabilitet til fx java. -- String objekter i c# er unikke, dvs at der kun findes én streng med et givet indhold i din .net process. Der er altså en stor hashtabel der holder styr på alle strenge, så der aldrig findes duplikater.
Så derfor er simpel pointersammenligning helt fint.
Det der står i #9 linket er at de synes man bør bruge metoder der explicit specificerer en sringcomparison, altså om det fx skal være case insensitivt. Det kan man så være enig i eller ej ;)
(men det #0 spørger om bør vel være case insensitivt) -- Jeg har her til morgen haft gang i både test i VS, søgt Google tyndt og spurgt adskillige andre C# og Java udviklere. Kan igen kun konkludere at == operatoren som nævnt i #32 er fuldt ud dygtig til at kunne varetage en string comparison hvad angår C#. -- try { write crappy code that might fail }
catch { don't care } #40 det er vel fair nok hvis Zazzy har haft behov for at tage et kig mere på problemet, hvis han er blevet usikker.
Hvis du vil kritisere noget er det måske fair at slå på at hans "andre udviklere" er fuldstændigt uden reference og derved lidt ubrugelig for os andre.
Med al respekt er de ' vindende' argumenter her i tråden i mine øjne ret empiriske, så det er ikke unfair at være lidt uafklaret.
Når det er sagt - så kunne jeg næppe selv finde på at sammenligne med String.Equals() metoden, da operator == giver et simplere oveblik i mine øjne.
Odd trivia: Jeg har par gange set String.CompareTo() anvendt til selv samme formål. -- I C# er det at skrive:
string1 == string2
det samme som at skrive:
string1.Equals(string2)
Dette er fordi compileren er redefineret til at sammenligne indholdet af strengene og ikke selve referencen på heap'en. - Dette er specielt for strenge i C#.
Hvad angår Java, så er det korrekt, at referencen sammenlignes, når der benyttes == og ikke .Equals. -- * i7 950 @ 3.8Ghz - 12GB HyperX - MSI 770 OC - Force GT SSD
* Filco Majestouch 2 MX Brown PBT #42: Nej, som jeg skriver i #38, så er begge dele en simpel reference sammenligning. To strings i .net med samme indhold vil være/pege på den *samme* string.
Og jeg er enig med #41 at == giver mere overskuelig kode. -- [BLUE]Dele af indlæg fjernet.[/BLUE]
Nu sidder jeg i et ret så stort udviklings team hvor C# er 90% af det. Derfor forhørte jeg mig lige til morgenmødet hvor alle rystede på hovedet af teorien om at == ikke skulle fungere i alle tilfælde af string comparison i C#.
At de alle sammen også kan fejl er selvfølgelig en mulighed, men så længe ingen kan modbevise det med et reelt kode eksempel, jamen så forholder jeg mig til hvad jeg selv ved og har erfaret, samt bruger i hverdagen.
Og jeg er helt enig at == er langt mere overskuelig og "pænere" at anvende end string.Equals hvorfor brugen af == operatoren for mit vedkomne vil forsætte som den plejer.
#42 Præcis! Og eftersom hele tråden handler om C# kode så er det stadig noget "vrøvl" at == kan skabe problemer. Noget som #7 og #9 påstår, men altså ikke kan bevise. -- try { write crappy code that might fail }
catch { don't care } --
#43 Det er præcis det jeg skriver?
Equal operatoren (==) kalder String.Equals(string, string) hvis man virkelig vil fluekneppe.
Her er et link - så kan der vidst ikke opstå tvivl:
http://msdn.microsoft.com[...] -- * i7 950 @ 3.8Ghz - 12GB HyperX - MSI 770 OC - Force GT SSD
* Filco Majestouch 2 MX Brown PBT #45 Og skulle man en dag komme i den situation, at man vil compile sin kode med en 3-parts C#-compiler til linux / iOS, så er det jo bare at håbe, at den er enig med M$'s compiler til windows - ellers har man en røvfuld rettearbejde, som kunne være undgået. P.S: Jeg bruger selv "==" til sammenligning af strenge, selvom jeg ikke burde :-D
#0 Mit eksempel i #5 er stadig det mest korrekte svar, der er givet til dit spørgsmål ;-) -- http://xlinx.dk[...]
i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK #46 Se dét giver jeg dig helt ret i ;)
Det er måske også en af grundene, at MS anbefaler at man bruger .Equals(). -- * i7 950 @ 3.8Ghz - 12GB HyperX - MSI 770 OC - Force GT SSD
* Filco Majestouch 2 MX Brown PBT #46 Hvis du tænker Mono her så er det komplet det samme som MS's compiler :)
Mine Xamarin(MonoDroid, MonoTouch og OSX) apps anvender også alle == i stedet for string.Equals og her har jeg heller ingen problemer oplevet ;)
Og jeg vil da stadig gerne se et sted eller et eksempel på hvor en 3. parts C# compiler misfortolker == i en string comparison :) -- try { write crappy code that might fail }
catch { don't care } #19
Nej, for dit argument til konstruktøren er ikke gyldigt. Med et gyldigt argument er det fuldt ud muligt:
char[] chars = new char[]{'D','u','d','e'};
if("Dude" == new string(chars)) -- Gæstebruger, opret dit eget login og få din egen signatur. #43
char[] chars = new char[]{'D','u','d','e'};
string s = "Dude";
object.ReferenceEquals(chars, s); // false
"Dude" ligger altså to forskellige steder, men == fungerer alligevel... -- Gæstebruger, opret dit eget login og få din egen signatur. #50
Det skal naturligvis være:
object.ReferenceEquals(string(chars), s); // false -- Gæstebruger, opret dit eget login og få din egen signatur. Hmm.. det ser faktisk ud til at være lidt åbent hvornår .net internerer (putter dem ind i den globale tabel) strings eller ej: http://msdn.microsoft.com[...]
(jeg har ikke været obs på den funktion før)
Så mon ikke == (og equals) ser om begge strings er internerede og i givet falder bruger reference sammenligning, og ellers må den sammenligne indholdet. Det ændrer naturligvis ikke på =='s specifikation ( http://msdn.microsoft.com[...] ), men har visse performance implikationer.
(jeg vil nu nok fx regne med at en switch(string) altid vil internere) --
Grundet øget spam aktivitet fra gæstebrugere, er det desværre ikke længere muligt, at oprette svar som gæst.
Hvis du ønsker at deltage i debatten, skal du oprette en brugerprofil.
Opret bruger | Login
|
Du skal være logget ind for at tilmelde dig nyhedsbrev.
Hvilken udbyder har du til internet? 239 personer har stemt - Mit energiselskab (Ewii f.eks) 11%
|
|
|