---

Hejsa

Jeg skal lave et tal om til et binær tal der skal benyttes til at gemme som
billede. Men hvordan laver jeg det om, så det kan bruges?

Niels

---

Hei Niels

Function Dec2Bin(What As Long) As String
Dim Tell As Long
Dec2Bin = ""
Tell = What
Do
Dec2Bin = Tell Mod 2 & Dec2Bin
Tell = Int(Tell / 2)
Loop Until Tell < 1
End Function

Sub test()
MsgBox Dec2Bin(19)
End Sub

HTH. Beste hilsen Harald

"Niels" <noway> skrev i melding
news:3d072859$0$211$edfadb0f@dspool01.news.tele.dk...
> Hejsa
>
> Jeg skal lave et tal om til et binær tal der skal benyttes til at gemme
som
> billede. Men hvordan laver jeg det om, så det kan bruges?
>
> Niels
>
>

---

Harald Staff skrev:
[snip]
> Dec2Bin = Tell Mod 2 & Dec2Bin
[snip]

Her bør man skrive: Dec2Bin = CStr(Tell Mod 2) & Dec2Bin
.... selvom det virker uden.

Mvh. Bjarke

---

Bjarke Walling Petersen skrev:
> Harald Staff skrev:
> [snip]
> > Dec2Bin = Tell Mod 2 & Dec2Bin
> [snip]
>
> Her bør man skrive: Dec2Bin = CStr(Tell Mod 2) & Dec2Bin
> ... selvom det virker uden.

Både ja og nej.
Fidusen med at bruge & til streng-konkatenering fremfor + er jo netop
at & _gennemtvinger_ en konvertering til strenge _inden_ disse
konkateneres. Se selv beskrivelsen af &-operatoren:

"Used to force string concatenation of two expressions."

Bruger man derimod + som streng-konkateneringsoperator, bør man ALTID
bruge CStr på ikke-strenge.

-------
Tomas

---

Tomas Christiansen skrev:
> Bjarke Walling Petersen skrev:
> > Harald Staff skrev:
> > [snip]
> > > Dec2Bin = Tell Mod 2 & Dec2Bin
> > [snip]
> >
> > Her bør man skrive: Dec2Bin = CStr(Tell Mod 2) & Dec2Bin
> > ... selvom det virker uden.
>
> Både ja og nej.
> Fidusen med at bruge & til streng-konkatenering fremfor + er jo netop
> at & _gennemtvinger_ en konvertering til strenge _inden_ disse
> konkateneres. Se selv beskrivelsen af &-operatoren:
>
> "Used to force string concatenation of two expressions."
>
> Bruger man derimod + som streng-konkateneringsoperator, bør man ALTID
> bruge CStr på ikke-strenge.

På den måde har du ret, men personligt vil jeg foretrække at rette i et
program, der er altid bruger konverteringsfunktionerne, selvom det ikke er
nødvendigt. Det bør være en hovedregel altid at programmere stuktureret og
overskueligt. Derfor synes jeg godt man kan lære folk denne gode skik. I
øvrigt tager det ikke ekstra CPU-tid, da & jo selv vil udføre CStr på begge
variabler der skal konkatineres, hvis disse ikke allerede er strenge.

Mvh. Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> wrote in message
news:3d07bfd4$0$44150$edfadb0f@dspool01.news.tele.dk...
> Det bør være en hovedregel altid at programmere stuktureret og
> overskueligt. Derfor synes jeg godt man kan lære folk denne gode skik.

Nå, så koden min er uoverskuelig ? Og jeg programmerer ustruktureret ?

> øvrigt tager det ikke ekstra CPU-tid, da & jo selv vil udføre CStr på
begge
> variabler der skal konkatineres, hvis disse ikke allerede er strenge.

"Hvis ikke" tar tid i seg selv. Og det du ønsker er CStr(Cstr(x)) hvilket
tar dobbelt så lang tid.

(resten er sensureret -man har da gode skik'er så det renner efter...)

---

Harald Staff skrev:
> Nå, så koden min er uoverskuelig ? Og jeg programmerer ustruktureret ?

Jeg ved nu ikke om det er uoverskueligt, det synes jeg ikke, men der er nogle små skønhedsfejl og plads til forbedringer (og det er
der vel altid).

Du skriver:

> Function Dec2Bin(What As Long) As String
> Dim Tell As Long
> Dec2Bin = ""
> Tell = What

Dvs. at du signalerer til den, som bruger funktionen, at What vil kunne returnere en værdi (idet den overføres ByRef).
Men i koden skynder du dig at tage en kopi af den (Tell), for ikke at ødelægge dens værdi, og du ændrer slet ikke på What's værdi.

Hvis du vil vise dine intentioner, angiver du ByVal, hvis du ikke vil returnere en ny værdi i et argument.
Så behøver du heller ikke at tage (unødig) en kopi af argumentet.

Ydermere bruger du en almindelig (langsom) kommatalsdivision ("/"), for straks herefter at konvertere resultatet til heltal, selvom
det jo er en heltaltsdivision ("\") du ønsker.

En sidste ting, som man måske bør gøre opmærksom på, er at funktionen returnerer værdien nul, hvis den fodres med negative tal. Jeg
vil gerne vælge at returnere den tomme streng i stedet for "0", idet jeg derved signalerer at det ikke giver mening at bruge negatve
tal (i denne implementation).

Den omskrevne funktion bliver da (bemærk at CStr ikke benyttes - jeg ville nok bruge den i praksis):

Function Dec2Bin2(ByVal What As Long) As String
Dec2Bin2 = ""
If What >= 0 Then
Do
Dec2Bin2 = What Mod 2 & Dec2Bin2
What = What \ 2
Loop Until What = 0
End If
End Function

Bemærk at initialiseringen af Dec2Bin til den tomme streng er unødvendig, idet alle streng-variabler (og funktioners returværdi) fra
automatisk tildeles den tomme streng, når de oprettes, men jeg synes nu alligevel at det er god skik at gøre det.

-------
Tomas

---

"Tomas Christiansen" <toc@blikroer.dk.removethis> skrev i melding
news:ae9qkg$2h1k$1@news.cybercity.dk...

> Hvis du vil vise dine intentioner, angiver du ByVal, hvis du ikke vil
returnere en ny værdi i et argument.
> Så behøver du heller ikke at tage (unødig) en kopi af argumentet.

Meget godt poeng.

> Ydermere bruger du en almindelig (langsom) kommatalsdivision ("/"), for
straks herefter at konvertere resultatet til heltal, selvom
> det jo er en heltaltsdivision ("\") du ønsker.

\ fungerer som koden står -dvs ved Long-variabel. Men ved større tall vil
den ikke, så jeg valgte å beholde den sådan for å nemt kunne redigere den.

> Bemærk at initialiseringen af Dec2Bin til den tomme streng er unødvendig,
idet alle streng-variabler (og funktioners returværdi) fra
> automatisk tildeles den tomme streng, når de oprettes, men jeg synes nu
alligevel at det er god skik at gøre det.

Enig.

Beste hilsen Harald

---

Harald Staff skrev:
> Nå, så koden min er uoverskuelig ? Og jeg programmerer ustruktureret ?

Små stykker kode, som det du postede, er nemme at overskue. Så jo, det var
fint nok overskueligt.
Men man, synes jeg, bør altid skrive CStr, hvor det er det man ønsker - en
konvertering fra én variabeltype til en streng.
Selvfølgelig er det ikke teknisk nødvendigt, men det er heller ikke teknisk
nødvendigt at programmere overskueligt og stuktureret.

> "Hvis ikke" tar tid i seg selv. Og det du ønsker er CStr(Cstr(x)) hvilket
> tar dobbelt så lang tid.
[snip]

Det er muligt, når man kører sit program i VB-miljøet. Men er jeg er
overbevidst om det ikke er tilfældet når du compilerer dit program. Her har
MS dummet sig meget, hvis compileren ikke også ændrer CStr(CStr(x)) til
CStr(x) ... for den reducerer nemlig andre matematiske udtryk - i hvert fald
til en vis grad:

"Visual Basic may rearrange arithmetic expressions to increase internal
efficiency." - MSDN Library

Men ok, hvem siger at MS aldrig har dummet sig ...

Jeg blev lidt interesseret i at se, hvormeget tid CStr tog i forhold til
'ikke CStr'. Så jeg lavede et lille testprojekt, der målte hvor lang tid
10.000 'sætninger' med og uden CStr tog. Jeg kørte det et par gange, både i
VB og compileret og fik følgende resultater:

I VB-miljøet:
Med CStr: 11,990 sek. gns. pr. 10.000 sætninger
Uden CStr: 11,790 sek. gns. pr. 10.000 sætninger
=> CStr er ca. 1,7% langsommere
Som .exe-fil:
Med CStr: 13,496 sek. gns. pr. 10.000 sætninger
Uden CStr: 13,678 sek. gns. pr. 10.000 sætninger
=> CStr er ca. 1,3% hurtigere

Dog siger det ikke så meget, da så små procentværdier ligeså godt kan være
en usikkerheder.

Mvh. Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> skrev i melding
news:3d087c0c$0$71635$edfadb0f@dspool01.news.tele.dk...
> I VB-miljøet:
> Med CStr: 11,990 sek. gns. pr. 10.000 sætninger
> Uden CStr: 11,790 sek. gns. pr. 10.000 sætninger
> => CStr er ca. 1,7% langsommere
> Som .exe-fil:
> Med CStr: 13,496 sek. gns. pr. 10.000 sætninger
> Uden CStr: 13,678 sek. gns. pr. 10.000 sætninger
> => CStr er ca. 1,3% hurtigere

Hurtigere kompilert ? I rest my case Tak skal du ha.

Beste hilsen Harald

---

Bjarke Walling Petersen skrev:
> > > Her bør man skrive: Dec2Bin = CStr(Tell Mod 2) & Dec2Bin
> > > ... selvom det virker uden.
> >
> > Både ja og nej.
> >
> > Bruger man derimod + som streng-konkateneringsoperator, bør man ALTID
> > bruge CStr på ikke-strenge.
>
> På den måde har du ret, men personligt vil jeg foretrække at rette i et
> program, der er altid bruger konverteringsfunktionerne, selvom det ikke er
> nødvendigt. Det bør være en hovedregel altid at programmere stuktureret og
> overskueligt. Derfor synes jeg godt man kan lære folk denne gode skik. I
> øvrigt tager det ikke ekstra CPU-tid, da & jo selv vil udføre CStr på begge
> variabler der skal konkatineres, hvis disse ikke allerede er strenge.

Det var jo også derfor at jeg skrev: "både ja og nej"

Jeg er ganske enig med dig mht. det at programmere struktureret og at VISE sine intentioner (med CStr).

Jeg kunne blot ikke lade være med at opponere, idet du ikke begrundede hvorfor man bør bruge CStr (idet årsagen jo er din - som også
er min - personlige holdning til programmering, men ikke er af teknisk karakter).

Mht. forbrug af CPU-tid er streng-konkatenering med + helt klart det hurtigste, men denne metode indeholder så mange faldgruber, at
den bør undgås (hvilket MS også selv anbefaler).

-------
Tomas

---

Tomas Christiansen skrev:
> Det var jo også derfor at jeg skrev: "både ja og nej"
>
> Jeg er ganske enig med dig mht. det at programmere struktureret og at VISE
sine intentioner (med CStr).
>
> Jeg kunne blot ikke lade være med at opponere, idet du ikke begrundede
hvorfor man bør bruge CStr (idet årsagen jo er din - som også
> er min - personlige holdning til programmering, men ikke er af teknisk
karakter).
[snip]

Ja, det er rigtigt. Men det er jo heller ikke en teknisk nødvendighed at
programmere overskueligt. Jeg mener at god skik ikke blot er at overholde de
tekniske regler, men f.eks. også sørge for at andre kan rette i ens
programmer og nemt forstå betydningen af det man gør.
Selvfølgelig har det ikke så stor betydning ved små stykker kode, der bliver
postet i denne nyhedsgruppe.

Men egentlig er det op til den enkelte programmør at bestemme sig for hans
programmeringsstil. Det kan være mit eget problem at jeg går og ærgrer mig
over der ikke er den samme mængde konventioner og retningslinier i Visual
Basic, som der f.eks. er i C++.

Mvh. Bjarke