---

Jeg er ved at lære fantastiske C++ og jeg syntes hele tiden det er
forskelligt om folk bruger return 0; eller return (0);
Er det ene mere korrekt end det andet og i så fald hvorfor ?



-Josefsen

---

---

On Mon, 24 Feb 2003 15:08:24 +0100, Claus Pedersen wrote:

>
> Dette er måske ikke noget særligt autoriseret svar, men jeg kan i
> "Accelerated C++" af Andrew Koenig (vældig god C++ lærebog) se, at der
> bruges "return 0;". Jeg ved ikke, om det andet er ukorrekt, men
> parenteserne gør ingen forskel. Så du sparer lidt tid og plads ved ikke
> at skrive dem
>

Mange tak for de hurtige svar, det er rart at gøre det der er rigtigt fra
starten :)

find ./ -name "*.cpp" -exec sed s/return (0);/return 0;/g {} \;


-Josefsen

---

"Brian Josefsen" <josefsen@sjovedyr.dk> wrote in message
news:pan.2003.02.24.16.48.47.140749@sjovedyr.dk...
> On Mon, 24 Feb 2003 15:08:24 +0100, Claus Pedersen wrote:
>
> >
> > Dette er måske ikke noget særligt autoriseret svar, men jeg kan i
> > "Accelerated C++" af Andrew Koenig (vældig god C++ lærebog) se, at der
> > bruges "return 0;". Jeg ved ikke, om det andet er ukorrekt, men
> > parenteserne gør ingen forskel. Så du sparer lidt tid og plads ved ikke
> > at skrive dem
> >
>
> Mange tak for de hurtige svar, det er rart at gøre det der er rigtigt fra
> starten :)
>
> find ./ -name "*.cpp" -exec sed s/return (0);/return 0;/g {} \;

Det er sådan set heller ikke forkert at skrive (0) da udtrykket alligevel
bliver evalueret til 0. Et tilfælde hvor det faktisk er handy at benytte
parentser er noget ala:

return ((a?true:false) || (a?false:true));

... jeg vil dog give folk ret i at f.eks. "return (a)" er overkill og grimt

---

Brian Josefsen wrote:
> Jeg er ved at lære fantastiske C++ og jeg syntes hele tiden det er
> forskelligt om folk bruger return 0; eller return (0);
> Er det ene mere korrekt end det andet og i så fald hvorfor ?

Jeg bryder mig ikke selv om de unødvendige parenteser, da det får return
til at ligne et funktionskald. Men i C++ må du sætte alle de ekstra
parenteser du vil, så det er et spørgsmål om stil. Compileren er ligeglad.

Ivan Johansen

---

Ivan Johansen skrev:

>Jeg bryder mig ikke selv om de unødvendige parenteser

Enig.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

In article <pan.2003.02.24.13.00.32.100971@sjovedyr.dk>, Brian Josefsen wrote:
> Jeg er ved at lære fantastiske C++ og jeg syntes hele tiden det er
> forskelligt om folk bruger return 0; eller return (0);
> Er det ene mere korrekt end det andet og i så fald hvorfor ?

Nu er C++ ikke særlige konsekvent[1], men i C er ALLE andre funktioners
argumenter pakket ind i parenteser. Hvorfor i alverden skulle return()s,
så ikke være det?

1: Jeg fatter simpelthen ikke den der bizarre "cin <<" og "cout >>".
Mage til inkonsekvens.

--
Salu2, Søren.

---

Søren Hansen <sh@warma.dk> writes:

> In article <Pine.LNX.4.50L53.0302251714040.19607@ask.diku.dk>, Jonas Meyer
> Rasmussen wrote:
>>> Nu er C++ ikke særlige konsekvent[1], men i C er ALLE andre funktioners
>>> argumenter pakket ind i parenteser. Hvorfor i alverden skulle return()s,
>>> så ikke være det?
>> Det er vist noget vås.
>> return er _ikke_ nogen funktion, det er et nøgleord.
>
> Korrekt. Jeg formulerede mig uklart. Den bliver brugt som en funktion.

Den bliver ikke brugt som en funktion, den bliver brugt som en
kontrolstruktur. Ligesom f.eks. break, continue og goto der heller
ikke har paranteser.

> Den har et navn, og den kaldes med et argument (som regel ).

Bliver kaldt med et argument er ikke noget argument (pun not
intended), da funktioner i C/C++ uden argumenter også skal have
parenteser.

Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
ikke bruger paranteser og opfører sig som en funktion (der udregnes på
compile time i stedet for run-time). Her kan jeg da også fristes til
at sætte de (unødvendige) parenteser.

Men hvis man skal være konsistens, gælder det så også andre indbyggede
funktioner med et argument, som "-", "~" og "!"?

Efter min mening vil konsistens på det punkt ikke forbedre
læsligheden, tværtimod, og så bliver det bare til konsistens som et
mål i sig selv. Når man gør konsistent til et mål i stedet for et
middel kører et projekt af sporet, efter min erfaring.

> Jeg begriber
> ikke, hvorfor I/O ikke benytter almindelige funktionskald.

Fordi det skal være til at holde ud at læse og skrive.

Sammenlign

cout << a << " + " << b << " = " << a + b << "\n";

med

cout.print (a);
cout.print (" + ");
cout.print (b);
cout.print (" = ");
cout.print (a + b);
cout.print ("\n");

Man kan til nød få en C programmør der er vant til

fprintf (stdout, "%g + %g = %g\n", a, b, a + b);

til at gå over til den første notation, men aldrig den anden.

I/O notationen bør være kompakt, typesikker, simpel og udvidbar. Den
balance lykkedes bedre i C++ end i ret mange andre sprog med statisk
typecheck. C notationen er f.eks. kompakt og simpel, men hverken
udvidbar eller typesikker.

At den er så konsistent med operatorer i stedet for funktioner er
mindre væsentligt.

---

Per Abrahamsen skrev:

>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>ikke bruger paranteser

Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
ikke kun en warning.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>>ikke bruger paranteser
>
>Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
>ikke kun en warning.

Det skyldes, at sizeof både fungerer som en slags funktion og som en
operator, ligesom +-*/ osv. De tager to forskellige argumenter:

   sizeof ( type )
   sizeof expression

Hvis argumentet er en type skal det stå i parentes. Hvis argumentet er
et udtryk behøves parenteser ikke, men er naturligvis tilladt (det er
parenteser jo i udtryk). Dvs

   int n = 7;

   sizeof int; // fejl: et type-argument kræver parenteser
   sizeof(int); // ok
   sizeof((int)); // fejl: "(int)" er ikke en type

   sizeof n; // ok
   sizeof(n); // ok
   sizeof((((n)))); // ok
   sizeof (5*n++); // ok, osv med andre udtryk

Du har tydeligvis brugt en type som argument, siden compileren brokker
sig. Det er oftest bedst at bruge en instans fremfor en type, fordi man
da undgår at skulle gentage typeinformationen. Dvs fx:

   SOMETYPE *p = malloc(n * sizeof(SOMETYPE)); // unødig gentagelse
   SOMETYPE *p = malloc(n * sizeof p); // bedre
   SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
variabels typenavn spredt rundt omkring. Specielt i situationer hvor en
ændring af typen ikke vil blive opdaget, fx når den bruges som argument
til sizeof().

Og nej, den opførsel er ikke særlig konsistent. Som en pragmatisk udvej
forsyner jeg selv ofte sizeof med parenteser også når den fodres med et
udtryk: altså sizeof(p) fremfor sizeof p. Jeg synes "sizeof p" ser sært
og usædvanligt ud i større udtryk.

I øvrigt mener jeg at return(0) bør udslettes.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Richard Flamsholt <richard@flamsholt.dk> skrev:
[blah blah]

Aaargh! Min newshost, sunsite, var helt død og timede ud og hver gang
valgte jeg bare retry. Nu ser jeg, at mange af disse fejlslagne postings
faktisk alligevel blev modtaget af sunsite. Ups! Tid til cancelling.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Richard Flamsholt skrev:

>Det skyldes, at sizeof både fungerer som en slags funktion og som en
>operator, ligesom +-*/ osv. De tager to forskellige argumenter:

Okay, det var jeg ikke klar over.

>Du har tydeligvis brugt en type som argument

Jeg skulle beregne størrelsen af et array:

   sizeof(array)/sizeof(array[0]);

>Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
>tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
>variabels typenavn spredt rundt omkring.

Klart, og redundans er i det hele taget af det onde.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Richard Flamsholt wrote:
>    SOMETYPE *p = malloc(n * sizeof p); // bedre
>    SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Du mener forhåbentlig sizeof(*p), da sizeof(p) jo giver pointerens
størrelse.

Ivan Johansen

---

Ivan Johansen <NG2@Padowan.dk> skrev:
>Du mener forhåbentlig sizeof(*p), da sizeof(p) jo giver pointerens
>størrelse.

D'oh! Ja, det var en styg svipser.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>>ikke bruger paranteser
>
>Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
>ikke kun en warning.

Det skyldes, at sizeof både fungerer som en slags funktion og som en
operator, ligesom +-*/ osv. De tager to forskellige argumenter:

   sizeof ( type )
   sizeof expression

Hvis argumentet er en type skal det stå i parentes. Hvis argumentet er
et udtryk behøves parenteser ikke, men er naturligvis tilladt (det er
parenteser jo i udtryk). Dvs

   int n = 7;

   sizeof int; // fejl: et type-argument kræver parenteser
   sizeof(int); // ok
   sizeof((int)); // fejl: "(int)" er ikke en type

   sizeof n; // ok
   sizeof(n); // ok
   sizeof((((n)))); // ok
   sizeof (5*n++); // ok, osv med andre udtryk

Du har tydeligvis brugt en type som argument, siden compileren brokker
sig. Det er oftest bedst at bruge en instans fremfor en type, fordi man
da undgår at skulle gentage typeinformationen. Dvs fx:

   SOMETYPE *p = malloc(n * sizeof(SOMETYPE)); // unødig gentagelse
   SOMETYPE *p = malloc(n * sizeof p); // bedre
   SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
variabels typenavn spredt rundt omkring. Specielt i situationer hvor en
ændring af typen ikke vil blive opdaget, fx når den bruges som argument
til sizeof().

Og nej, den opførsel er ikke særlig konsistent. Som en pragmatisk udvej
forsyner jeg selv ofte sizeof med parenteser også når den fodres med et
udtryk: altså sizeof(p) fremfor sizeof p. Jeg synes "sizeof p" ser sært
og usædvanligt ud i større udtryk.

I øvrigt mener jeg at return(0) bør udslettes.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>>ikke bruger paranteser
>
>Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
>ikke kun en warning.

Det skyldes, at sizeof både fungerer som en slags funktion og som en
operator, ligesom +-*/ osv. De tager to forskellige argumenter:

   sizeof ( type )
   sizeof expression

Hvis argumentet er en type skal det stå i parentes. Hvis argumentet er
et udtryk behøves parenteser ikke, men er naturligvis tilladt (det er
parenteser jo i udtryk). Dvs

   int n = 7;

   sizeof int; // fejl: et type-argument kræver parenteser
   sizeof(int); // ok
   sizeof((int)); // fejl: "(int)" er ikke en type

   sizeof n; // ok
   sizeof(n); // ok
   sizeof((((n)))); // ok
   sizeof (5*n++); // ok, osv med andre udtryk

Du har tydeligvis brugt en type som argument, siden compileren brokker
sig. Det er oftest bedst at bruge en instans fremfor en type, fordi man
da undgår at skulle gentage typeinformationen. Dvs fx:

   SOMETYPE *p = malloc(n * sizeof(SOMETYPE)); // unødig gentagelse
   SOMETYPE *p = malloc(n * sizeof p); // bedre
   SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
variabels typenavn spredt rundt omkring. Specielt i situationer hvor en
ændring af typen ikke vil blive opdaget, fx når den bruges som argument
til sizeof().

Og nej, den opførsel er ikke særlig konsistent. Som en pragmatisk udvej
forsyner jeg selv ofte sizeof med parenteser også når den fodres med et
udtryk: altså sizeof(p) fremfor sizeof p. Jeg synes "sizeof p" ser sært
og usædvanligt ud i større udtryk.

I øvrigt mener jeg at return(0) bør udslettes.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>>ikke bruger paranteser
>
>Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
>ikke kun en warning.

Det skyldes, at sizeof både fungerer som en slags funktion og som en
operator, ligesom +-*/ osv. De tager to forskellige argumenter:

   sizeof ( type )
   sizeof expression

Hvis argumentet er en type skal det stå i parentes. Hvis argumentet er
et udtryk behøves parenteser ikke, men er naturligvis tilladt (det er
parenteser jo i udtryk). Dvs

   int n = 7;

   sizeof int; // fejl: et type-argument kræver parenteser
   sizeof(int); // ok
   sizeof((int)); // fejl: "(int)" er ikke en type

   sizeof n; // ok
   sizeof(n); // ok
   sizeof((((n)))); // ok
   sizeof (5*n++); // ok, osv med andre udtryk

Du har tydeligvis brugt en type som argument, siden compileren brokker
sig. Det er oftest bedst at bruge en instans fremfor en type, fordi man
da undgår at skulle gentage typeinformationen. Dvs fx:

   SOMETYPE *p = malloc(n * sizeof(SOMETYPE)); // unødig gentagelse
   SOMETYPE *p = malloc(n * sizeof p); // bedre
   SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
variabels typenavn spredt rundt omkring. Specielt i situationer hvor en
ændring af typen ikke vil blive opdaget, fx når den bruges som argument
til sizeof().

Og nej, den opførsel er ikke særlig konsistent. Som en pragmatisk udvej
forsyner jeg selv ofte sizeof med parenteser også når den fodres med et
udtryk: altså sizeof(p) fremfor sizeof p. Jeg synes "sizeof p" ser sært
og usædvanligt ud i større udtryk.

I øvrigt mener jeg at return(0) bør udslettes.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
>>ikke bruger paranteser
>
>Min compiler brokker sig hvis jeg fjerner parenteserne, og det er
>ikke kun en warning.

Det skyldes, at sizeof både fungerer som en slags funktion og som en
operator, ligesom +-*/ osv. De tager to forskellige argumenter:

   sizeof ( type )
   sizeof expression

Hvis argumentet er en type skal det stå i parentes. Hvis argumentet er
et udtryk behøves parenteser ikke, men er naturligvis tilladt (det er
parenteser jo i udtryk). Dvs

   int n = 7;

   sizeof int; // fejl: et type-argument kræver parenteser
   sizeof(int); // ok
   sizeof((int)); // fejl: "(int)" er ikke en type

   sizeof n; // ok
   sizeof(n); // ok
   sizeof((((n)))); // ok
   sizeof (5*n++); // ok, osv med andre udtryk

Du har tydeligvis brugt en type som argument, siden compileren brokker
sig. Det er oftest bedst at bruge en instans fremfor en type, fordi man
da undgår at skulle gentage typeinformationen. Dvs fx:

   SOMETYPE *p = malloc(n * sizeof(SOMETYPE)); // unødig gentagelse
   SOMETYPE *p = malloc(n * sizeof p); // bedre
   SOMETYPE *p = malloc(n * sizeof(p)); // bedst, imho

Det synes måske ikke som alverden (og i eksemplet ovenfor er det jo helt
tydeligt, hvad typen er) men generelt er det bedst at undgå at have en
variabels typenavn spredt rundt omkring. Specielt i situationer hvor en
ændring af typen ikke vil blive opdaget, fx når den bruges som argument
til sizeof().

Og nej, den opførsel er ikke særlig konsistent. Som en pragmatisk udvej
forsyner jeg selv ofte sizeof med parenteser også når den fodres med et
udtryk: altså sizeof(p) fremfor sizeof p. Jeg synes "sizeof p" ser sært
og usædvanligt ud i større udtryk.

I øvrigt mener jeg at return(0) bør udslettes.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

In article <rjisv75e9c.fsf@zuse.dina.kvl.dk>, Per Abrahamsen wrote:
>> Korrekt. Jeg formulerede mig uklart. Den bliver brugt som en funktion.
> Den bliver ikke brugt som en funktion, den bliver brugt som en
> kontrolstruktur. Ligesom f.eks. break, continue og goto der heller
> ikke har paranteser.

Nej, og det irriterer mig egentlig også.

>> Den har et navn, og den kaldes med et argument (som regel ).
> Bliver kaldt med et argument er ikke noget argument (pun not
> intended), da funktioner i C/C++ uden argumenter også skal have
> parenteser.

Jeps. Jeg synes også return() burde være gyldigt.

> Et mindre urimeligt eksempel på inkonsistens er sizeof, der heller
> ikke bruger paranteser og opfører sig som en funktion (der udregnes på
> compile time i stedet for run-time). Her kan jeg da også fristes til
> at sætte de (unødvendige) parenteser.

Nåja, det heller ikke en funktion. Jeg sætter ALTID de parenteser. For
programmøren er det ret så ligegyldigt, at sizeof er et nøgleord og ikke
en funktion.

> Men hvis man skal være konsistens, gælder det så også andre indbyggede
> funktioner med et argument, som "-", "~" og "!"?

Jeg gør det ikke med "-", men med "~" og "!" plejer jeg at sætte
parentes, ja.

> Efter min mening vil konsistens på det punkt ikke forbedre
> læsligheden, tværtimod, og så bliver det bare til konsistens som et
> mål i sig selv.

Det synes jeg nu ikke. Det er meget nemmere at overskue, hvor det ene
udtryk slutter og det næste starter.

>> Jeg begriber ikke, hvorfor I/O ikke benytter almindelige funktionskald.
> Fordi det skal være til at holde ud at læse og skrive.
> Sammenlign
> cout << a << " + " << b << " = " << a + b << "\n";
> med

Hvad med:
cout(a," + ",b," = ",a+b,"\n");

Det ville da være nemt.

Det er nok fordi, der er noget, jeg ikke forstår, men hvad er det
fantastisk magiske, man kan gøre med de der "<<" og ">>"?

--
Salu2, Søren.

---

[ Søren Hansen ]

[ ... ]

> Hvad med:
> cout(a," + ",b," = ",a+b,"\n");
>
> Det ville da være nemt.


Ikke med den modellen som C++ har for et vilkårlig antall argumenter.





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

"Thomas Krog" <rick@kampsax.dtu.dk> writes:

> Især hvis det bliver længere udtryk som:
> a-(b+c/d)
> som ellers ville hedde:
> a.sub(b.add(c.div(d)))

I Lisp ville det være

(- a (+ b (/ c d)))

Måske er det er sprog i Sørens smag?

---

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> "Thomas Krog" <rick@kampsax.dtu.dk> writes:
>
> > Især hvis det bliver længere udtryk som:
> > a-(b+c/d)
> > som ellers ville hedde:
> > a.sub(b.add(c.div(d)))
>
> I Lisp ville det være
>
> (- a (+ b (/ c d)))
>
> Måske er det er sprog i Sørens smag?

Jeg tillader mig lige at slå et slag for omvendt polsk notation...

a b c d / + -

....altid sjovt at se folk gå fuldstændig i baglås når de skal bruge
min HP lommeregner

--
Christian Hemmingsen

---

> Jeg tillader mig lige at slå et slag for omvendt polsk notation...
>
> a b c d / + -
>
> ...altid sjovt at se folk gå fuldstændig i baglås når de skal bruge
> min HP lommeregner

Jeg er en af dem der går i baglås. Hvad i alverden er dog det smarte ved den
metode fremfor det mere logiske
a/b+c-d? Med paranteser kan man skrive alle udtryk på den måde og det virker
da noget mere logisk.

Jeg går ud fra at der ER fordele ved omvendt polsk, men hvad er dog de
grunde??

---

Den Wed, 26 Feb 2003 19:01:19 +0100 skrev Janus:
>> Jeg tillader mig lige at slå et slag for omvendt polsk notation...
>>
>> a b c d / + -
>>
>> ...altid sjovt at se folk gå fuldstændig i baglås når de skal bruge
>> min HP lommeregner
>
>Jeg er en af dem der går i baglås. Hvad i alverden er dog det smarte ved den
>metode fremfor det mere logiske
>a/b+c-d? Med paranteser kan man skrive alle udtryk på den måde og det virker
>da noget mere logisk.
>
>Jeg går ud fra at der ER fordele ved omvendt polsk, men hvad er dog de
>grunde??

Man regner altid fra venstre mod højre, regnereglerne er meget
simple - både for mennesker og for computeren.

Og da man altid regner fra venstre mod højre, slipper man altså
for paranteserne.

Den eneste grund til at du synes at den "normale" måde er logisk, er
at det er den du har lært.

Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side

---

Janus skrev:

>Jeg er en af dem der går i baglås. Hvad i alverden er dog det smarte ved den
>metode fremfor det mere logiske a/b+c-d?

Den er ikke spor mere logisk. Hvis du var vokset op med OPN,
ville du synes at *den* var mest logisk.

Det ene kan vlære lige så godt som det andet, men OPN er lettere
at programmere til f.eks. en lommeregner, og det er også en god
teknik ved parsning af f.eks. programkode (af samme årsag).

Hvis man læser brochurer fra Texas og HP, 'beviser' de hver for
sig at man skal bruge megt færre tastetryk ved deres metode frem
for ved konkurrentens. Men de snyder begge to, og forskellen er
næsten ikke-eksisterende hvis man taster mest effektivt. Der er
dog enkelte beregninger hvor Texas vinder med ét tryk.

>Jeg går ud fra at der ER fordele ved omvendt polsk, men hvad er dog de
>grunde?

Parenteser er ikke altid nemme at gennemskue.

.... og jeg foretrækker algebraisk notation - af gammel vane.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

In article <rjbs0z5e5y.fsf@zuse.dina.kvl.dk>, Per Abrahamsen wrote:
> I Lisp ville det være
> (- a (+ b (/ c d)))

> Måske er det er sprog i Sørens smag?

Jeg kiggede faktisk forleden på Scheme[1] og det tiltalte mig egentlig en
del, så ja. Konsekvens tiltaler mig i ekstrem grad.

[1]: Scheme er en dialekt af Lisp, der bl.a. bruges i GIMPs
scriptsprog, Script-Fu.

--
Salu2, Søren.

---

"Janus" <aaa@bbb.ccc> writes:

>> Jeg tillader mig lige at slå et slag for omvendt polsk notation...
>>
>> a b c d / + -
>>
>> ...altid sjovt at se folk gå fuldstændig i baglås når de skal bruge
>> min HP lommeregner
>
> Jeg er en af dem der går i baglås. Hvad i alverden er dog det smarte
> ved den metode fremfor det mere logiske a/b+c-d?

Det er helt sikkert ikke mere logisk, hvilket du vil opdage hvis du
prøver at implementere det på en computer. Både de omvendte polakker
og Lisp notationen er langt lettere at få en computer til at forstå.

Den almindelige matematiske notation føles mere "naturlig", men det
skyldes alene at du (ligesom de fleste andre) har lært den i en tidlig
alder, og set den mange gange siden.

Og den giver nogen problemer, specielt med hensyn til præsedens, det
vil sige at a+b*c skal parses som (+ a (* b c)), rigtig mange danskere
(og billige lommeregnere) vil i stedet parse den som (* (+ a b) c).

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> writes:

> Klart, og redundans er i det hele taget af det onde.

Ikke altid, det kan fungere som en slags paritetscheck, også i kode.

---

Søren Hansen <sh@warma.dk> writes:

> Jeps. Jeg synes også return() burde være gyldigt.

Og

do ()
something ();
while (!(done));

?

>> Efter min mening vil konsistens på det punkt ikke forbedre
>> læsligheden, tværtimod, og så bliver det bare til konsistens som et
>> mål i sig selv.
>
> Det synes jeg nu ikke. Det er meget nemmere at overskue, hvor det ene
> udtryk slutter og det næste starter.

Det bruger C++ ";" til.

return 7;

Jeg holder skam også af Lisp, men det får mig ikke til at syntes at
alle sprog nødvendigvis skal bruge parenteser som eneste
struktureringselement.

> Hvad med:
> cout(a," + ",b," = ",a+b,"\n");
>
> Det ville da være nemt.

Hvordan vil du gøre det udvidbart og typesikkert, på en måde der er
konsistens med resten af sproget?

> Det er nok fordi, der er noget, jeg ikke forstår, men hvad er det
> fantastisk magiske, man kan gøre med de der "<<" og ">>"?

Få dem til at fungere med alle typer, også dem brugeren selv
definerer.

---

Søren Hansen <sh@warma.dk> writes:

> Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator
> overloading?

Overloading af operatorer.

(Jeg føler mig hjælpsom i dag).

>> Ikke desto mindre er det ihvertfald _ikke_ inkonsekvent, da hele stream
>> biblioteket i c++ anvender det. og logisk set giver operatorene mening, da
>> de angive hvad vej dataen løber fra din stream.
>
> Ok, det er ganske muligt, at jeg bare ikke forstår det, men så hjælp mig
> lidt på vej. Hvad er forskellen på
> cout << "Hejsa\n";
> og
> cout("Hejsa\n");
> ?

Begge kan implementeres med operator overloading, henholdsvis
operator<< og operator(). Syntaksen ville blive

cout << "Hejsa " << name << " og velkommen!\n";

eller

cout("Hejsa ")(name)(" og velkommen!\n");

Jeg syntes << ser mere naturlig ud.

Desuden er der nogen streams man både kan skrive og læse fra, for dem
er det praktisk at have to forskellige operatorer der indikerer hvad
vej strømmen går.

> Hvorfor er det "pænt" at lave noget, der ikke ligner resten af sproget?

Det er *implementeret* i resten af sproget. For alle de compilere jeg
kender, er streams bare er seperat library implementeret i C++. Der
er intet ved streams du ikke kan gøre med dine egne klasser.

---

---

In article <Pine.LNX.4.50L53.0302251714040.19607@ask.diku.dk>, Jonas Meyer
Rasmussen wrote:
>> Nu er C++ ikke særlige konsekvent[1], men i C er ALLE andre funktioners
>> argumenter pakket ind i parenteser. Hvorfor i alverden skulle return()s,
>> så ikke være det?
> Det er vist noget vås.
> return er _ikke_ nogen funktion, det er et nøgleord.

Korrekt. Jeg formulerede mig uklart. Den bliver brugt som en funktion.
Den har et navn, og den kaldes med et argument (som regel ).

>> 1: Jeg fatter simpelthen ikke den der bizarre "cin <<" og "cout >>".
>> Mage til inkonsekvens.
> Hvordan kan du kalde det inkonsekvent, når du ikke fatter det?

Jeg fatter ikke inkonsekvensen. Det er det, jeg mener. Jeg begriber
ikke, hvorfor I/O ikke benytter almindelige funktionskald.

> Du har tydeligvis ikke indset forskellen, da du har arrangeret dem
> forkert ovenfor ostream's bruger << operatoren og istreams bruger
> >> operatoren.. og det _giver_ mening.

Hvordan? Altså, hvorfor giver det mening, at I/O skal benytte
funktionskald, der ikke ligner alle andre?

> Ydermere, så er er det alt for tyndt at du kalder sproget inkonsekvent
> på basis af _en_ observation.

I mine øjne er det nok. Enten er man konsekvent, eller også er man ikke.
Men det er nærmere en filosofisk diskussion. Desuden diskuterede vi
egentlig ikke C++'s inkonsekvens, men noget ganske andet.

--
Salu2, Søren.

---

> Hvordan? Altså, hvorfor giver det mening, at I/O skal benytte
> funktionskald, der ikke ligner alle andre?

sikkert fordi folk synes det er lettere at læse. Det er den samme
problemstilling som:
a-b
Det er efter min mening pænere end:
a.sub(b)
a.subtract(b)
a.minus(b)
Især hvis det bliver længere udtryk som:
a-(b+c/d)
som ellers ville hedde:
a.sub(b.add(c.div(d)))

---

---

In article <Pine.LNX.4.50L53.0302260215260.6361@ask.diku.dk>, Jonas Meyer
Rasmussen wrote:
>> >> 1: Jeg fatter simpelthen ikke den der bizarre "cin <<" og "cout >>".
>> >> Mage til inkonsekvens.
>> > Hvordan kan du kalde det inkonsekvent, når du ikke fatter det?
>> Jeg fatter ikke inkonsekvensen. Det er det, jeg mener. Jeg begriber
>> ikke, hvorfor I/O ikke benytter almindelige funktionskald.
> Det er muligt du syntes det er grimt at bruge operator overloading til io.

Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator
overloading?

> Ikke desto mindre er det ihvertfald _ikke_ inkonsekvent, da hele stream
> biblioteket i c++ anvender det. og logisk set giver operatorene mening, da
> de angive hvad vej dataen løber fra din stream.

Ok, det er ganske muligt, at jeg bare ikke forstår det, men så hjælp mig
lidt på vej. Hvad er forskellen på
cout << "Hejsa\n";
og
cout("Hejsa\n");
?

>> Hvordan? Altså, hvorfor giver det mening, at I/O skal benytte
>> funktionskald, der ikke ligner alle andre?
> operatoren >> angiver i " istream >> variabel ", at der løber data fra
> istream'en til variablen.. og omvendt ved ostreams.
> I bund og grund er det jo blot et funktionskald der bliver foretaget, det
> er blot pakket pænt ind..

Hvorfor er det "pænt" at lave noget, der ikke ligner resten af sproget?

>> > Ydermere, så er er det alt for tyndt at du kalder sproget inkonsekvent
>> > på basis af _en_ observation.
>> I mine øjne er det nok. Enten er man konsekvent, eller også er man ikke.
> Dvs sproget er ukonsekvent, fordi det har taget et valg som du ikke bryder
> dig om?

Nej, fordi det har undtagelser fra ting. At jeg ikke finder
undtagelserne særligt pæne er ganske rigtigt, men det påvirker ikke
konsekvensen.

--
Salu2, Søren.

---

Søren Hansen skrev:

>Ok, det er ganske muligt, at jeg bare ikke forstår det, men så hjælp mig
>lidt på vej. Hvad er forskellen på
>cout << "Hejsa\n";
>og
>cout("Hejsa\n");
>?

Det sidste virker ikke.

Det første minder programmøren om at han er i gang med at benytte
en stream.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

> Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator overloading?

Det er en helt vildt smart feature der gør du kan skrive din kode "pænt". Fx
synes jeg det her er pænt:

*** Vertex.h ***

class Vertex
{
double x;
double y;
double z;
};

*** Vertex.cpp ***


ostream& operator <<(ostream& out, Vertex* v)
{
out << "Vertex: (" << v->x << ", " << v->y << ", " << v->z << ")";

return out;
}



--
<signature>
Lasse Westh-Nielsen
lasse@daimi.au.dk
</signature>


"Søren Hansen" <sh@warma.dk> wrote in message
news:slrnb5pf9f.7t2.sh@pluto.linuxkonsulent.dk...
> In article <Pine.LNX.4.50L53.0302260215260.6361@ask.diku.dk>, Jonas Meyer
> Rasmussen wrote:
> >> >> 1: Jeg fatter simpelthen ikke den der bizarre "cin <<" og "cout >>".
> >> >> Mage til inkonsekvens.
> >> > Hvordan kan du kalde det inkonsekvent, når du ikke fatter det?
> >> Jeg fatter ikke inkonsekvensen. Det er det, jeg mener. Jeg begriber
> >> ikke, hvorfor I/O ikke benytter almindelige funktionskald.
> > Det er muligt du syntes det er grimt at bruge operator overloading til
io.
>
> Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator
> overloading?
>
> > Ikke desto mindre er det ihvertfald _ikke_ inkonsekvent, da hele stream
> > biblioteket i c++ anvender det. og logisk set giver operatorene mening,
da
> > de angive hvad vej dataen løber fra din stream.
>
> Ok, det er ganske muligt, at jeg bare ikke forstår det, men så hjælp mig
> lidt på vej. Hvad er forskellen på
> cout << "Hejsa\n";
> og
> cout("Hejsa\n");
> ?
>
> >> Hvordan? Altså, hvorfor giver det mening, at I/O skal benytte
> >> funktionskald, der ikke ligner alle andre?
> > operatoren >> angiver i " istream >> variabel ", at der løber data fra
> > istream'en til variablen.. og omvendt ved ostreams.
> > I bund og grund er det jo blot et funktionskald der bliver foretaget,
det
> > er blot pakket pænt ind..
>
> Hvorfor er det "pænt" at lave noget, der ikke ligner resten af sproget?
>
> >> > Ydermere, så er er det alt for tyndt at du kalder sproget
inkonsekvent
> >> > på basis af _en_ observation.
> >> I mine øjne er det nok. Enten er man konsekvent, eller også er man
ikke.
> > Dvs sproget er ukonsekvent, fordi det har taget et valg som du ikke
bryder
> > dig om?
>
> Nej, fordi det har undtagelser fra ting. At jeg ikke finder
> undtagelserne særligt pæne er ganske rigtigt, men det påvirker ikke
> konsekvensen.
>
> --
> Salu2, Søren.

---

Ja ok, Outlook Express keyboard shortcut gjorde jeg ikke blev færdig...

Forfra:

Operator overloading er en helt vildt smart feature der gør du kan skrive
din kode "pænt". Fx
synes jeg det her er pænt:



*** Vertex.h ***

class Vertex
{
double x;
double y;
double z;
};

extern ostream& operator <<(ostream& out, Vertex* v);



*** Vertex.cpp ***


ostream& operator <<(ostream& out, Vertex* v)
{
out << "Vertex: (" << v->x << ", " << v->y << ", " << v->z << ")";

return out;
}



*** Main.cpp ***

Vertex* v;

[noget kode der opretter vertex'et osv]

cout << v << endl;



Så får du fx på skærmen:

Vertex: (3.0, 4.0, 5.0)


Smart hva'?

- Lasse


--
<signature>
Lasse Westh-Nielsen
lasse@daimi.au.dk
</signature>


"Lasse Westh-Nielsen" <lasse@daimi.au.dk> wrote in message
news:b3lhsf$oes$1@sunsite.dk...
> > Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator
overloading?
>
> Det er en helt vildt smart feature der gør du kan skrive din kode "pænt".
Fx
> synes jeg det her er pænt:
>
> *** Vertex.h ***
>
> class Vertex
> {
> double x;
> double y;
> double z;
> };
>
> *** Vertex.cpp ***
>
>
> ostream& operator <<(ostream& out, Vertex* v)
> {
> out << "Vertex: (" << v->x << ", " << v->y << ", " << v->z << ")";
>
> return out;
> }
>
>
>
> --
> <signature>
> Lasse Westh-Nielsen
> lasse@daimi.au.dk
> </signature>
>
>
> "Søren Hansen" <sh@warma.dk> wrote in message
> news:slrnb5pf9f.7t2.sh@pluto.linuxkonsulent.dk...
> > In article <Pine.LNX.4.50L53.0302260215260.6361@ask.diku.dk>, Jonas
Meyer
> > Rasmussen wrote:
> > >> >> 1: Jeg fatter simpelthen ikke den der bizarre "cin <<" og "cout
>>".
> > >> >> Mage til inkonsekvens.
> > >> > Hvordan kan du kalde det inkonsekvent, når du ikke fatter det?
> > >> Jeg fatter ikke inkonsekvensen. Det er det, jeg mener. Jeg begriber
> > >> ikke, hvorfor I/O ikke benytter almindelige funktionskald.
> > > Det er muligt du syntes det er grimt at bruge operator overloading til
> io.
> >
> > Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator
> > overloading?
> >
> > > Ikke desto mindre er det ihvertfald _ikke_ inkonsekvent, da hele
stream
> > > biblioteket i c++ anvender det. og logisk set giver operatorene
mening,
> da
> > > de angive hvad vej dataen løber fra din stream.
> >
> > Ok, det er ganske muligt, at jeg bare ikke forstår det, men så hjælp mig
> > lidt på vej. Hvad er forskellen på
> > cout << "Hejsa\n";
> > og
> > cout("Hejsa\n");
> > ?
> >
> > >> Hvordan? Altså, hvorfor giver det mening, at I/O skal benytte
> > >> funktionskald, der ikke ligner alle andre?
> > > operatoren >> angiver i " istream >> variabel ", at der løber data fra
> > > istream'en til variablen.. og omvendt ved ostreams.
> > > I bund og grund er det jo blot et funktionskald der bliver foretaget,
> det
> > > er blot pakket pænt ind..
> >
> > Hvorfor er det "pænt" at lave noget, der ikke ligner resten af sproget?
> >
> > >> > Ydermere, så er er det alt for tyndt at du kalder sproget
> inkonsekvent
> > >> > på basis af _en_ observation.
> > >> I mine øjne er det nok. Enten er man konsekvent, eller også er man
> ikke.
> > > Dvs sproget er ukonsekvent, fordi det har taget et valg som du ikke
> bryder
> > > dig om?
> >
> > Nej, fordi det har undtagelser fra ting. At jeg ikke finder
> > undtagelserne særligt pæne er ganske rigtigt, men det påvirker ikke
> > konsekvensen.
> >
> > --
> > Salu2, Søren.
>
>

---

Lasse Westh-Nielsen skrev:

>> Ok, nu brillerer jeg lige med min uvidenhed. Hvad er operator overloading?

>Det er en helt vildt smart feature ...

Det er også en helt vildt smart feature at man kan slette det
citat som er overflødigt. Kan du formås til at benytte dig af
den?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospamfor@lundhansen.dk> wrote in message
news:crms5v02qfu82che1a2df3cff7985eui1u@news.stofanet.dk...

> Det er også en helt vildt smart feature at man kan slette det
> citat som er overflødigt. Kan du formås til at benytte dig af
> den?


Hehe... Det var faktisk ikke engang med vilje - men nu hvor jeg ser det igen
så synes jeg det er stor humor

Det må i - og Søren især - undskylde.

Mvh Lasse


--
<signature>
Lasse Westh-Nielsen
lasse@daimi.au.dk
</signature>

---