C#: Konvertere int til string - error!

[Jonas]

class Program
{
   static void Main()
   {

       int Test;
       Test = 2;
       string Test2;
       Test2 = Test.ToString;

   }
}

Etter navnet å bedømme skulle jeg tror at funksjonen kunne brukes slik, men det kan den tydelighvis ikke.

 

Cannot convert method group 'ToString' to non-delegate type 'string'. Did you intend to invoke the method?

 

Har også prøvd Test2 = (string)Test, men det funket like dårlig.

 

Cannot convert type 'int' to 'string'

 

Hvordan konverterer jeg int (eller andre tall-typer for den saks skyld) til string? Og finnes det noe lignende Variant fra VB, en type som kan holde hva som helst?

 

- Jonas

 

 

Edit: Mens jeg har en tråd - hvorfor gir ~2 -3 ?

2 = 10

~2= 01

 

01 = 1

 

Edit: Blir mye prøving og feiling nå, og jeg skulle gjerne hatt noe bruker-input å leke med. Hvordan er letteste måte å gjøre det på fra et console-program?

Endret 14. oktober 2006 av Jonas

[JeyKey]

int tall = 2;
string streng;
streng = tall.ToString();

Du må huske parantesene etter en metode vet du.

 

 

noe som kan holde hva som helst: System.Object.

object tall = 1;
object streng = "Heisann";

 

burde funke. Fordi alt i C# opprinnelig arver fra System.Object burde det også være mulig å implisitt caste til type object.

 

Skjønner ikke helt hva du mener med den første editen, det med ~2 -3. Aldri sett før, men kanskje noen andre skjønner mer av det enn meg

Endret 14. oktober 2006 av JeyKey

[Jonas]

Takker for svar, skal teste dette ut senere i dag!

 

Boka (C# Bible) forteller meg at tegnet "~" reverserer bitsa.

 

Understanding bitwiise complement opreator

C# enables you to apply a bitwise complement operation to int, uint, long and ulong expressions. Bitwise complement operations view your value as if they are a binary, and flip all of the bits. Bits that had a value of 1 become 0, and bits that had a value of 0 become 1.

 

~6 = 1 fordi

 

110

001 = 1

[JeyKey]

Det må du ikke spørre meg om, syns det virket rart selv. Jeg prøvde ut dette og ~6 burde gitt 1, men ga isteden -7. Hvis jeg var deg ville jeg ikke tatt dette så tungt, du trenger vel strengt tatt nesten aldri noen av bitoperatorene i C#, og hvertfall ikke denne. Selv har jeg aldri brukt ~ operatoren i annet enn destructors, slik:

~myClass() {}

Endret 15. oktober 2006 av JeyKey

[j000rn]

Det må du ikke spørre meg om, syns det virket rart selv. Jeg prøvde ut dette og ~6 burde gitt 1, men ga isteden -7. Hvis jeg var deg ville jeg ikke tatt dette så tungt, du trenger vel strengt tatt nesten aldri noen av bitoperatorene i C#, og hvertfall ikke denne. Selv har jeg aldri brukt ~ operatoren i annet enn destructors, slik:

~myClass() {}

7072959[/snapback]

 

int:

6 = 00000000.00000000.00000000.00000110 b

 

~00000000.00000000.00000000.00000110 b

=11111111.11111111.11111111.11111001 b = -7

 

Første bit'n sier ifra om det er + eller -.

 

Prøv det samme med byte (8 bits, unsigned), så skal resultatet bli dette:

00000110 b

~00000110 b = 11111001 b = 249

 

Som du ser er det mange 0'er forran som også blir reversa, så for å få svaret til Jonas må vi kun telle 3 bits:

 

" ~6 = 1 fordi

110

001 = 1

"

 

(~6) & 7 = 1

fordi:

(~...00000110) & ...00000111 = ...001

[GeirGrusom]

~ kalles bitwise not, i motsetning til ! som kalles logical not.

Hvis du bruker uint istedet for int så vil du ikke få et negatvit svar.

[JeyKey]

det skjønte jeg hvertfall litt av. hva betyr b-en på slutten på alle bitsene?

 

Og hva mener du med at den første biten bestemmer om tallet er positivt eller negativt?

 

Og er det egentlig noen vits å bruke operatorene & og | på boolske verdier når man har && og || som gjør det samme, bare raskere?

 

Mener ikke å ta over tråden her, men er litt nysgjerrig på dette her selv.. og det plager meg enda mer at eksemplene til msdn bruker heksadesimale tallverdier, som gjør det hele enda mer uforståelig.

Endret 15. oktober 2006 av JeyKey

[j000rn]

det skjønte jeg hvertfall litt av. hva betyr b-en på slutten på alle bitsene?

 

Og hva mener du med at den første biten bestemmer om tallet er positivt eller negativt?

 

Og er det egentlig noen vits å bruke operatorene & og | på boolske verdier når man har && og || som gjør det samme, bare raskere?

 

Mener ikke å ta over tråden her, men er litt nysgjerrig på dette her selv.. og det plager meg enda mer at eksemplene til msdn bruker heksadesimale tallverdier, som gjør det hele enda mer uforståelig.

7076797[/snapback]

 

b betyr bare at det er bit Men i denne sammenhengen var det egentlig ikke noe poeng å presisere det.

F.eks. skrives hexadecimale verdier sånn: 0xFFFF = 65535. , 0xF = 15..etc

11111111b = 0xFF = 255

 

"Og hva mener du med at den første biten bestemmer om tallet er positivt eller negativt?"

Akuratt det jeg sier

F.eks. (med signed byte - selv om den ikke finnes i C#, men det gjør eksemplet litt enklere):

1 = 00000001

-1 = 11111111

2 = 00000010

-2 = 11111110

 

Du kan prøve selv med calc.exe i windows. (sett view- scientific)

-2 gir:

1111111111111111111111111111111111111111111111111111111111111110

Grunnen her til antallet 1-tall er fordi calc bruker 64bits long.

En liten finurlighet er at calc også alltid konverterer til unsigned long når den går fra bit -> decimal. Slik at:

1111111111111111111111111111111111111111111111111111111111111110 blir til 18446744073709551614... :|

 

 

 

&, |, % brukes på tall. && og || brukes på boolske uttrykk (true/false).

 

F.eks.:

int a = Counter & 0xFF; <-- her virker ikke &&.

 

 

& og &&, | og || er heller ikke det samme når det gjelder boolske uttrykk.

Disse to linjene vil ikke gjøre det samme:

if( a() > 5 | b() > 5 )

if( a() >5 || b() > 5 )

|| er short-circuited versjonen av |. Det betyr at hvis a()>5 vil ikke b() kjøre. I den første linjen vil begge funkjonene kjøre. Og du har rett i at || og && som regel vil være raskere (fordi mindre kode vil kjøres), men av og til kan det hende man ønsker å kjøre begge funksjonene

[JeyKey]

greit, så hvis den første biten er 1, er tallet negativt. er den 0 er tallet positivt.

 

sbyte tallet =  ~1; // 11111110b
Console.WriteLine(tallet); // gir -2

Det jeg ikke skjønner er hvorfor dette skal gi -2. Det starter på 1, så tallet skal være negativt. greit nok. Men hvordan skriver man da 255 med bits i en byte? Hvis jeg prøver å bytte ut sbyte med byte får jeg compiler error. Såvidt jeg forsto dette skulle 11111110b = -254

 

Jeg trodde at 00000000 = 0. når du da snur alle bitsa skulle det bli 11111111. Så hvorfor blir ikke det 255?

128  64   32   16   8      4     2    1  = 255
1     1     1     1     1     1     1     1  = 11111111b

 

Så hvorfor er ikke 11111111b = 255?

 

Skjønner at jeg kan virke litt masete og plagsom nå, så jeg skal si meg fornøyd med en link til et sted dette er godt forklart...

 

EDIT: men da kunne man kanskje skrevet 255 som 011111111b? problemet er da at du har brukt 9 bits, ikke 8. og ~255 blir -256 fordi du kan skrive det som 100000000b. Dette kunne jeg godtatt som en forklaring, men en byte rommer jo ikke 9 bits!

 

så hvordan kan

byte Byte = 255;

funke, hvis dataen tolker det som 011111111b? en byte kan inneholde tallet 255, men ikke inneholde de 9 bitsene som min tankegang krever for å skrive det.

Seriøst forvirra her jeg

Endret 15. oktober 2006 av JeyKey

[j000rn]

For byte vil ikke det første bit'n ha noe å si på +/-. Fordi den er unsigned. (0-255)

sbyte derimot vil den første bit'n si om det er +/-. I tillegg kan denne også max være 127. (-128 til 127).

 

Så det stemmer at en byte aldri vil være 9 bits, men samtidig vil aldri en signed-byte kunne bli høyere enn 127

 

 

Prøv:

byte a = 0;

byte b = (byte)~a;

int c = (~a) & 0xFF;

 

Så ser du b vil være 255. Det vil også c være. Fordi med & 0xFF fjerner vi alle bits bortsett fra de 8 siste (11111111.11111111.11111111.11111111).

 

 

Prøv også:

sbyte tallet = ~1;

Console.WriteLine((byte)tallet);

[JeyKey]

byte a = 0; // 00000000b

byte b = (byte)~a; // 11111111b = -1... Why? Skulle etter min mening gitt 255.

 

gir System.OverFlowException.

Arithmetic operation resulted in an overflow.

Endret 16. oktober 2006 av JeyKey

[j000rn]

byte a = 0; // 00000000b

byte b = (byte)~a; // 11111111b = -1... Why? Skulle etter min mening gitt 255.

 

gir System.OverFlowException.

Arithmetic operation resulted in an overflow.

7081009[/snapback]

 

Hos meg får jeg dette:

 

byte a = 0;
byte b = (byte)~a;
Console.WriteLine( b );

Resultat: 255

 

Men jeg har vist ikke krysset av "Check for arithmetic overflow/underflow" under properties på prosjektet - Build - Advanced.

 

checked
{
  byte a = 0;
  byte b = (byte)~a;
  Console.WriteLine( b );
}

Gir samme exception som deg.

 

Du kan skru av overflow checking i en kodesnutt også ved å bruke unchecked{}.

 

For å unngå overflow exception'n kan du passe på at tallet aldri overflow'er en byte ved å AND'e med 255 (0xFF):

checked
{
  byte a = 0;
  byte b = (byte)(~a & 0xFF);
  Console.WriteLine( b );
}

 

 

Du har helt rett:

byte b = (byte)~a; // 11111111b = -1... Why? Skulle etter min mening gitt 255.

Det skal bli 255.

 

Men bytt ut med sbyte så vil det bli -1.

[JeyKey]

men det blir jo ikke 255.

 

byte a = 0;
byte b = (byte) ~a;
Console.WriteLine(b);

gir bare OverflowException, fordi ~a returnerer -1. Den gir -1 uansett data type. Og uansett hvordan du snur og vender på det skjønner jeg ikke hvordan dataen får åtte 1-tall til å bli -1.

 

byte a = 0;
byte b = (byte) (~a & 255);
Console.WriteLine(b);

den gir derimot det jeg hadde forventet i første kodesnutt også. Men jeg ser ikke poenget å å legge til & 255 når byte datatypen ikke inneholder mer enn 8 bits uansett

Endret 16. oktober 2006 av JeyKey

[GeirGrusom]

byte a = 0xff;

MessageBox.Show(((byte)~a).ToString()) gir meg 0, akkurat som forventet...

kanskje det har med casting å gjøre?

[JeyKey]

det gir meg et exception. i unchecked context gir det meg også 0. Slenger jeg på en & 255 etter ~a gir det 0 uten unchecked også.

Endret 16. oktober 2006 av JeyKey

[j000rn]

det gir meg et exception. i unchecked context gir det meg også 0. Slenger jeg på en & 255 etter ~a gir det 0 uten unchecked også.

7082455[/snapback]

 

 

[Gråskjegg]

Og uansett hvordan du snur og vender på det skjønner jeg ikke hvordan dataen får åtte 1-tall til å bli -1.

7082348[/snapback]

Sjekk wikipedia for en forklaring.

 

- grå -

[j000rn]

La oss si at vi har en "signed-half-byte" da (4 bits, første +/-, -8 til +7):

 

Og så plusser vi på 1 for hver steg:

 

0000 = 0

0001 = 1

...

0111 = 7

1000 = -8

1001 = -7

1010 = -6

1011 = -5

1100 = -4

1101 = -3

1110 = -2

1111 = -1

0000 = 0

...

 

På denne måten ser du at tallet "loop'er" ved overflow. Det samme skjer med SIGNED byte (sbyte), bare med 8 bits istedenfor 4 og -128 til 127:

 

00000000 = 0

00000001 = 1

...

01111111 = 127

10000000 = -128

10000001 = -127

...

11111110 = -2

11111111 = -1

00000000 = 0

....

 

Mens med vanlig UNSIGNED byte:

00000000 = 0

00000001 = 1

...

01111111 = 127

10000000 = 128

10000001 = 129

...

11111110 = 254

11111111 = 255

00000000 = 0

Endret 17. oktober 2006 av jorn79

[JeyKey]

Og så plusser vi på 1 for hver steg:

Takk, det var den lille biten med info jeg manglet for å skjønne det. Jeg gikk da utifra at du skulle subtrahere for hvert steg, ikke addere. Endret 17. oktober 2006 av JeyKey