Opdeling af String

Du kan benytte dig af funktionene instr(), til at finde det næste \'+\', den returnere positionen, som du så kan benytte ved at bruge mid() til at kopiere den karakter ud du skal bruge....

X=.....
tmpX=X

While InStr(tmpX,\";\")
  endIndex=InStr(tmpX,\";\")
  array=Mid(tmpX,1,1) // tallet før +
  value=Mid(tmpX,3,endIndex-1) // tallet efter +
  length=len(tmpX)
  tmpX=Mid(tmpX,endIndex+1,length-endIndex+1)

  // læg værdierne ind i de rigtige arrays
  select case array
  case 1
    array1(<plads>)=value
  case 2
  ...
  case else
    Response.write(\"ERROR! Array ikke defineret!\")
  end select
wend

// jeg har ikke afprøvet ovenstående, men prøv at se hvad det giver :o)

dim Arr1
dim Arr2
dim i

arr1 = split(Text,\";\")
for i = 0 to ubound(arr1) -1
  arr2 = split(arr1(i),\"+\")
  \'nu ligger det første bogstav i arr2(0) og det andet i arr2(1)
next i

\'Ikke testet men burde virke ;)

Sorry det skal være
for i = 0 to ubound(arr1)
og ikke
for i = 0 to ubound(arr1) -1

oswald-> kan man ikke bare bruge for each?

arr= split(stringX,\";\")
for each item in arr
tal=split(item,\"+\")
select case tal(0)
case 1
...  tal(1) 
case else
end select
next

runesoft:>For each bruges normalt i forbindelse med objecter i collections, men når det bare er et array af string kan man lige så godt bruge Ubound.

jems:>Skal du også have noget kode til at indlægge data i dine arrays?

oswald-> Jeg synes det er mere overskueligt

Ja, men det er langsommere

Må jeg høre hvorfor det er langsomere ?

En for each løkke er langsommere da den et for et løber din collection/array igennem og adderer en tæller med en. LBound og Ubound bruger en anden algoritme som altid antager at det element det starter med er henholdsvis det største eller laveste og derfor behøves der sjældent al løbes igennem hele dit arrayet/collection

Det forklarede ikke hvorfor at for each er langsommere.
i next tælles der jo også en tæller op. Til gengæld kan det nok godt betale sig at flytte ubound ud af FOR løkken, da den ellers checker størrelsen af arrayet hele tiden.

moonduck->  Har du tabt mælet? Jeg er stadig interesseret i at vide hvad der er hurtigst ...

Nej, nej. Foreach løkken ved ikke hvor mange steps den skal igennem det skal den først tælle, det skal den først tælle. Det skal for x to x løkken ikke

WHAT???  Jo den skal! Ubound finder jo størrelsen af arrayet(og i dette tilfælde hvor mange steps den skal igennem). Jeg er ked af det, men dine forklaringer holder ikke i retten.
Uden at vide hvordan microsoft har implementeret for each, kan du ikke konkludere at for each er langsommere end ubound. Hvis du har et link til microsoft specifikation af implementeringen, må du meget gerne poste det.

Min umiddelbare holdning til dette er at for each meget vel kan være hurtigere end ubound, fordi at mere funktionalitet er gemt i en linie kode asp, og microsoft derfor har haft mulighed for at optimere det i baggrunden.

Og så er det netop at du nu skal læse mit svar fra 26/07 2001 11:19:12 

Jeg har prøvet lidt af hvert kommet frem til følgende (som ikke virker):

TmpArray = split(Text,\";\")
for i = 0 to ubound(tmpArray) -1

Case = split(tmpArray(i),\"+\")

select case Case
 
  case 1
    ArrayCNR

  case 2
    ArrayRNR

  case 3
    ArrayGNR
       
  case 4
    ArrayDNR

  Case 5
    ArrayTNR
           
  case 6
    ArrayNNR
   
  case else
    Response.write(\" ERROR! Array ikke defineret! \")
end select

next

Array\'et i hver case skal indeholde de værdier der er efter +

Jeg håber i kan hjælpe mig med det sidste, på forhånd tak :)

PS

TmpArray er god nok, den indeholder værdierne (adskilt af mellemrum):
1+4 2+5 4+7 3+11 5+6 6+10 4+13 1+21 2+40

du skal nok ikke bruge case som et variabelnavn

Du skal bruge select case case(0) og din værdi ligger i Case(1).

Case er nok et dårligt variabel navn.

moonduck...  Jeg har lige testet performance på for each o.s.v. på arrays på 200000 poster.

Jeg får følgende (sådan cirka):
for each:        301 milisekunder
for i=0 to uBound:391 milisekunder

Det er ok at græde :-)

Det nægter jeg at tro på min test på et array med 313682 elementer, fik jeg følgende resultat:

\'For i = LBound(x) to UBound(x) Next

\'1,113281
\'1,082031

\'For Each...Next

\'1,139844
\'1,2906

(Hvilken IIS kører du på?)

sekunder self.

først på en iis5.0

på en iis4.0 får jeg følgende
for each:266
for i=0 to uBound:328

koden er som følger:

redim arr(arrsize)
starttimer(0)
for each item in arr
  item = 10000
next
ms=readtimer(0)
response.write \"for each:\"& ms & \"<br>\"



starttimer(1)
for i=0 to ubound(arr)
  arr(i) = 10000
next
ms=readtimer(1)
response.write \"for i=0 to uBound:\"& ms & \"<br>\"

jems:> Er det bare mig eller er runesoft og moondock bare nogle hanekyllinger som nægter at give sig? ;)

runesoft og moonduck:> hører det ikke hjemme under et andet spørgsmål?... Så som \'hvem er mest stædig\' ;)

moonduck... Du husker at tilgå arrayet i løkken ikke?

Okay, dette er meget skummelt. Jeg har nu også prøvet din på min IIS 5 og det lader til at der er forskel på vores kode. Min ser sådan her ud:

<%
starttid = timer

for each element in arrTemp
Response.write element & \"<br/>\"
next

Response.write timer - starttid

Erase arrTemp
%>

<%
starttid = timer

for i = LBound(arrTemp) to UBound(arrTemp)
Response.write arrTemp(i) & \"<br/>\"
next

Response.write timer - starttid

Erase arrTemp
%>

I mit array er der variabel linie længde.(Det er et array med en post pr registreret dkdomæne)

oswald>> Undskyld men jeg syntes netop dette er en dejlig diskussion da det ikke er den sædvanlige: \"Hvad går der galt her\". Jeg har intet imod at vi drejer os over på performance og teori.

Jeg synes også at det er fedt, men jeg tror at at det bliver lidt svært at afgøre hvordan og hvorledes, når vi får forskellige resultater.

jems... undskyld at vi fucker op dit spørgsmål, men det er lidt spændende det her :-)

moonduck... hvad resultat får du med min kode? (du bliver lige nødt at lave timeren om)

Jeps har jeg gjort.. Med din kode må jeg desværre indrømme at du får ret :-(

for each:0,3125
for i=0 to uBound:0,3401563

for each:0,3125
for i=0 to uBound:0,3984375

for each:0,3203125
for i=0 to uBound:0,3984375

Men generelt syntes jeg svingningerne er lige lovlig store på min IIS så det er nok hos mig problemet ligger..

nej, det behøver det ikke være. Windows bruger jo tid på så meget andet. Kan du gennemskue hvad forskellen på de to stumper kode?

Jeg har desværre ikke lige et kæmpe array af tekst, ellers ville jeg også have prøvet din kode.

Ikke andet end at mit array indeholder noget når det bliver gennemløbet, det gør dit ikke.

ja, og dit tekst og mit tal. Nåh, men vil du være med til at konkludere at for each ikke nødvendigvis er langsommere end ubound? :-)

JA, okay jeg overgiver mig.

:-) Jeg går under navnet: Det stædige æsel ude i byen.

:-D

Men vi kan vel godt blive enige om at man IKKE bruger en for each hvis man kender sine afgrænsninger på forhånd, f.eks. vhvor mange elementer der er i arrayet.

hmm...  Skal vi fortsætte lidt?

Grunden jeg tror at for each er hurtigere er at tilgang til lokale variable er hurtigere end hurtigere en at læse og skrive i arrays. Derfor tror jeg at uanset om man kender størrelsen på arrayet, vil det det være hurtigst at bruge for each (hvis man vel at mærke skal igennem alle poster i arrayet). Hvis man derimod kun skal tilgå et subset af sit array, kan det med stor sikkerhed betale sig at at bruge for x to y.
Det der tager længst tid i din kode må være at skrive teksten ud. Hvis du bare kopierer teksten over i en variabel, tror jeg du vil få et andet resultat.

jems:> burde du ikke tage og fordele dine points som du mener de skal fordeles ( tag mig tag mig tag mig ). ;)

Undskyld det har taget så lang tid, jeg har lige flyttet :)

Jeg har brugt lidt fra zeptic og lidt mere fra oswald, derfor denne point fordeling...
Tak for hjælpen og sikke en diskusion!