operator ++ og effektivitet?

Brug den notation du synes bedst om og lad compileren om at optimere koden.

Hvad der er mest effektivt vil formentlig variere mellem
forskellige compilere og forskellige versioner af disse.

Under alle omstændigheder vil forskellen næppe betyde
meget på dages computere.

De fleste moderne compilere vil formentlig generere præcis
den samme kode for de to.

Hvad du bør bruge er derfor et spørgsmål om kode stil.

Jeg synes at du skal bruge i++ fordi det trods alt er det
mest almindelige og det vil give koden et kendt look and
feel for dem der skal læse den senere.

Hvis du skal bruge det nye tal samtidig med at du lægger en til er ++i vel at foretrække, men ellers har jeg kun set i++ blive brugt.

Hvis du bruger STL og iteratorer kan det gøre en stor forskel om man bruger ++i eller i++. Eks :

std::vector<int> v;
//...
std::vector<int>::iterator i;

for( i = v.begin(); i != v.end(); ++i)
{
  // ...
}

Forskellen på i++ og ++i er netop at i++ skal incrementere i og returnere den gamle værdi af i, mens ++i skal incrementere i og returnere den nye værdi.

Ved simple skalare typer som int er der ikke nogen forskel (som arne_v et.al. rigtigt skriver). Når der derimod er tale om en STL iterator betyder det at der skal laves en kopi af iteratoren for at man kan returnere værdien inden  incremented er udført.
I det ovenstående eksempel bruger man så ikke den returnerede værdi til noget, og det er der nogle kompilere som er smarte nok til at opdage så de kan optimere kopieringen af den gamle værdi væk, men man kan ikke være sikker . . .

hsloth >> jeg kan ikke rigtig se ud fra dit eksempel, at det gør en forskel..?

jpk>>
Den anden måde at lave for-løkken i eksemplet er :

  for( i = v.begin(); i != v.end(); i++)
                                      ^
og min pointe er at man ved at skrive post-increment instruerer kompileren til
at generere kode der returnere den gamle værdi af i, samtidigt med at i selv incrementeres. Man må huske på at et udtryk altid returnerer en værdi, følgende vill f.eks. være lovligt :

  std::vector<int>::iterator iold;
  for( i = v.begin(); i != v.end(); j = i++ )

Så det vigtige er at man ved at bruge postfix tvinger compileren til at tage en kopi af den gamle værdi inden variablen selv incrementeres, dette er som sagt ikke det store problem ved skalare, men når der bruges komplekse typer, som f.eks. i STL kan det have en væsentlig indflydelse på hastigheden.

rettelse til sidste linie i eksemplet :
  j skulle have været iold

hsloth >> I dit eksempel med henholdsvis:
for(i = v.begin(); i != v.end(); i++)
og
for(i = v.begin(); i != v.end(); ++i)
er det jo ikke spor anderledes end hvis det var en simpel int!
Inde i loopet vil du få nøjagtig samme værdi idét iteratoren jo først inkrementeres efter hvert gennemløb, lige meget om du bruger pre- eller post-inkrementering!

Mht. optimering fra compilerens side, er det da ganske rigtigt at den "sansynligvis" gør det, men det kan man jo ikke regne med.

Det er embedded programmering, hvorfor alle tricks vægter. Så 'kodestilen' vægter lidt mindre end effektiviten.

Jeg ved at normalt (i teorien) ved ++i undgår oprettelse af en temp var. til returnering af den gamle værdi, men det jeg var lidt usikker på var med hensyn til compileren og hvordan den håndterer det i praksis.

Men min konklusion bliver at '++i' er den 'mindst-kodestils-venlige-måske-ikke-målbar-men-mest-effektive-(afhængig-af-kompiler-men-i-hvert-fald-ikke-mest-ueffektive)' løsning! (ret mig hvis jeg tager fejl!.

Det virker måske lidt småligt, men man tager hvor man kan få.

Jeg synes nu slet ikke at ++i virker forkert, det er jo med det, som så meget, man skal vænne sig til det...
Jeg bruger stort set altid pre-inkrementering i for loops.

megoo>

Hvis du er ægte hard core programmør, så laver du jo 2 små eksempler
med pre og post og compiler dem ikke med den option der får C compileren
til at liste de genererede instruktioner og så kan du få syn for sagen
hvordan lige netop din C compiler behandler de to.

jpk>
forskellen ligger ikke i hvad løkken laver - de to eksempler laver præcis det samme, forskellen er kun hvor effektiv den genererede kode bliver.

Det er jo det jeg mener..!