C#: Avbryte en FOR løkke

[GeirGrusom]

Exceptions er en ganske CPU krevende prosess, så dersom en kan unngå det, så gjør man det.

Exceptions brukes KUN til feilmeldinger, ikke som en kontrollstruktur.

 

Et program hvor det ikke skjer noe galt skal heller aldri utføre exceptions.

[HDSoftware]

Exceptions er en ganske CPU krevende prosess, så dersom en kan unngå det, så gjør man det.

Exceptions brukes KUN til feilmeldinger, ikke som en kontrollstruktur.

 

Et program hvor det ikke skjer noe galt skal heller aldri utføre exceptions.

jada - hehe. Sa det var grisete ;-)

[teflonpanne]

If-tester og metodekall er også dyrt, goto er ikke. Eller nei, dette er jo et typisk eksempel hvor goto ikke skal brukes, dumme meg.

[HDSoftware]

If-tester og metodekall er også dyrt, goto er ikke. Eller nei, dette er jo et typisk eksempel hvor goto ikke skal brukes, dumme meg.

HIHI!!! Nå fåru snart tilsnakk ;-)

[GeirGrusom]

If-tester og metodekall er også dyrt, goto er ikke. Eller nei, dette er jo et typisk eksempel hvor goto ikke skal brukes, dumme meg.

Vi kan ta et VB6 sitt glimrende dårlige feilhåndtering:

Dim i As Long
On Error Goto ErrHandler
i = 100 / 0
ErrHandler:
MessageBox.Show "Ånei! en feil!"

 

Uffameg....

 

Men når det gjelder dyre operasjoner, bruker en ikke exceptions som et programflytelement.

Eller man kan, men det finnes bedre, mer logiske metoder.

 

Btw håper jeg ikke teflonpanne sin post var rettet som en spydig post mot meg.

[teflonpanne]

Vet ikke helt hvorfor du tok med den VB6-greia der men..

 

Og exceptions bruker jeg ikke for programflyt

 

Og posten var ikke rettet mot deg, jeg syns det er greit med goto her. Som jeg sa så er branching og metodekall dyrt, goto er ikke.

Endret 19. mai 2008 av teflonpanne

[GeirGrusom]

det er sant det

Hehe, virket bare som "GeirGrusom tar opp hva som er dyrt igjen uten å tenke på programkall"

[Manfred]

Jeg stemmer i alle fall også for denne:

  bool FoundIt = false;
 for(int i = 0; i < 10 && FoundIt == false; i++)
 {
for(int o=1; o<10 && FoundIt == false; o++)
  if(EttEllerAnnet)
		  FoundIt = true;
 }

[j000rn]

Jeg stemmer i alle fall også for denne:

...

 

1 poeng til meg!!!

[Mr.Garibaldi]

Jeg stemmer i alle fall også for denne:

...

 

1 poeng til meg!!!

 

Og jeg som trodde jeg var første som kom med det forslaget:

bool notFound = true;
int i, j;
for(i = 0; i < 2 && notFound; i++){
for(j = 0; j< 5 && notFound; j++){
	 if(array[i, j].Equals(Tallet))
		notFound = false;
}
}
if(notFound)
  //do something

[j000rn]

1 poeng til meg!!!

 

Og jeg som trodde jeg var første som kom med det forslaget:

 

Pfft....

[Manfred]

Eneste forskjellen fra mitt forslag var å legge testen i for-løkka i stedet for å ha en eksplisitt if rett under den innerste for-en!

[GeirGrusom]

public void LoopRun(bool secondrun)
{
 for(int i = 0; i < 100; i++)
 {
for(j = 0; j < 100 && !secondrun; j++)
{
  if(j == 50 && !secondrun)
  {
	System.Threading.Thread new_thread;
	new_thread = new System.Threading.Thread(new System.Threading.ParameterizedThreadStart(LoopRun));
	new_thread.Start((object)true);
	System.Threading.Thread.CurrentThread.Abort()
  }
}
 }
}

[Mr.Garibaldi]

Eneste forskjellen fra mitt forslag var å legge testen i for-løkka i stedet for å ha en eksplisitt if rett under den innerste for-en!

 

Ja, og dermed bruker vi den eksisterende testen, bare legger til en & operasjon, istedenfor å lage en ny test. Dermed sparer man jo litt ressurser, samt at man lett(ere) ser når løkken blir avsluttet.

 

Geir> Hva var tanken bak den koden? Det vil da bruke flere ressurser å sette opp og starte trådene (samt ødelegge for evt. unrolling av løkken) enn å kjøre løkken som normalt.

Endret 19. mai 2008 av Mr.Garibaldi

[Manfred]

Forslaget til GeirGrusom var vel mest en spøk, vil jeg tro...

 

Det er en mulig løsning, men komplett idioti

[teflonpanne]

Problemet er ikke testen i seg selv, den tar ikke så lang tid, men at moderne prosessorer utfører flere operasjoner på en gang og har svære pipeliner. Dermed må de gjøre branch predictions på if-tester og sånt, for å prøve å predicte hvilken branch den må ta neste gang. Hvis denne predictionen feiler må den gjerne tømme pipelinen, og det tar mange sykler og er veldig dyrt. I tillegg må den også muligens fetche koden på nytt fra minnet hvis den ikke ligger i cachen. Men goto er bare én instruksjon uansett, selv om man gjerne har nok prosessorkraft i dag til å drite i sånne mikrooptimaliseringer uansett da.. Så whatever lissom.

Endret 19. mai 2008 av teflonpanne

[Manfred]

Det sier jeg også: WHATEVER LISSOM! *fikle med håret og smatte med tyggisen*

[x871kx6167ss7]

[HDSoftware]

HAHAHA!! Dritbra :-D

[The Jackal]

Det går jo an å tenke litt på hva slags datastruktur man har også. Hvorfor bruke et 2d array f.eks? "Samme" kode som HDSoftware har:

const int MAX = 800;
List<string> array = new List<string>(MAX);
for (int i = 0; i <= MAX; ++i)
array.Add(i.ToString());

Console.Write("Søke etter et tall: ");
string number = Console.ReadLine();

if(array.IndexOf(number) == -1)
Console.WriteLine("Tallet {0} ble ikke funnet.", number);
else
Console.WriteLine("Tallet {0} er funnet.", number);
Console.WriteLine("Ferdig med søket");

 

Er ganske enig med Manfred her...bruk aldri goto 2 nestede for looper er jo heller ikke akkurat så bra med tanke på optimalisering.