mboost-dp1
Nørd humor
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
CBM (2) skrev:#1: LOL :-) Det viser hvor vigtigt det er at have styr på hvor der skal sættes semikolon;
eller i dette tilfælde; det rigtige antal "="-tegn :)
Det er sådan en klassisk fejl, jeg også med et par måneders mellemrum laver og undrer mig over; det tager altid lige lidt længere tid at finde den, fordi den er uventet. Assignments i if-statements bruger jeg tit - når det er meningen, men når de kravler ind som her, så - ja .. så kan det tage et kig eller to at finde.
_tweak (3) skrev:CBM (2) skrev:#1: LOL :-) Det viser hvor vigtigt det er at have styr på hvor der skal sættes semikolon;
eller i dette tilfælde; det rigtige antal "="-tegn :)
Det er sådan en klassisk fejl, jeg også med et par måneders mellemrum laver og undrer mig over; det tager altid lige lidt længere tid at finde den, fordi den er uventet. Assignments i if-statements bruger jeg tit - når det er meningen, men når de kravler ind som her, så - ja .. så kan det tage et kig eller to at finde.
Ahh shit... det er korrekt. ... der skal stå " == true"
Men der må heller ikke være semikolon før else
Det må være en meget speciel pascal compiler når den tillader det
= i stedet for == kan man komme ud for at compiler accepterer
Hmm måske er det fortolket pascal :-)
CBM (4) skrev:abonnement
Det afhænger vist af sprog; i C/OOC/Cpp/C#/PHP/etc er semikolon fint i dette tilfælde hvor der ikke er en blok (etc { } ) - men der er en single line - etc. i PHP if ($isThisOkay)doThat();else dontDoThat();
if (minbanan = BananFactory.CreateBanan()) er helt validt kode i de fleste sprog jeg kender :-)
#fejl
Den grundliggende fejl er ganske rigtigt = fremfor == (som er C familiens svar på Pascal famliens := og =).
Men fejlen kunne også være undgået på et par andre måder.
Man kunne have brugt en konstant fremfor en variabel.
Man kunne have brugt det gamle trick med at vende den slags test om:
if(v==true) skifter mening hvis det skrives som if(v=true).
Men if(true==v) giver en compile fejl hvis det skrives som if(true=v).
Og endelig er ==true jo totalt overflødig.
Den grundliggende fejl er ganske rigtigt = fremfor == (som er C familiens svar på Pascal famliens := og =).
Men fejlen kunne også være undgået på et par andre måder.
Man kunne have brugt en konstant fremfor en variabel.
Man kunne have brugt det gamle trick med at vende den slags test om:
if(v==true) skifter mening hvis det skrives som if(v=true).
Men if(true==v) giver en compile fejl hvis det skrives som if(true=v).
Og endelig er ==true jo totalt overflødig.
_tweak (5) skrev:if (minbanan = BananFactory.CreateBanan()) er helt validt kode i de fleste sprog jeg kender
Det er faktisk kun i sprog hvor ikke boolske udtryk kan opfattes som et boolsk udtryk (typisk 0 er falsk og ikke 0 er sand).
C, C++, PHP gør det.
Men Java, C# gør det ikke. Og dit banan eksempel vil give en compile fejl. Men i eksemplet havde de været så snedige at lade typen være boolsk, så eksemplet ville virke i både Java og C# også (Java bruger boolean ikke bool, men det er en detalje).
arne_v (8) skrev:#;else
Det er så vidt jeg husker en meget Pascal specifik ting. Jeg mener ikke at hverken Modula-2, Oberon eller Ada forbyder semikolon før else.
Men derudover vil den i Pascal give en compile fejl og ikke slippe robotterne løs.
Jep. Nævnte også at hvis det var pascal så ville det være en form for fortolket pascal (der vil de fleste compile fejl blive "runtime fejl")
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.