[C++] conversie char naar int

[Verwijderd]

Voor een procedure die een char-buffer meekrijgt en LAME moet aanroepen met een short-int buffer moet ik dus een conversie uitvoeren, maar ik kom er niet uit.

Ik geef hier de illustratie voor het geval 8-bits/mono:

char Buffer0[n];
short int value;
short int Buffer1[n];
for (i=0; i<n; i++)
{
value = Buffer0[i];
Buffer1[i] = value;
}

Uiteraard kan dit niet zomaar, maar hoe los ik dit op gegeven dat het probleem in de loop opgelost moet worden (dus Buffer0, Buffer1 en value moeten dezelfde structuur houden).

[Dash2in1]

[topic=496061/1/25]

[HansMij]

probeer eens ATOI....

Zoek het eens op op MSDN en je hebt absoluut de oplossing.

[Soultaker]

Op donderdag 16 mei 2002 15:18 schreef zeronegative het volgende:
Uiteraard kan dit niet zomaar

Waarom zou dat niet kunnen? Zelfs zonder value als tijdelijke variabele werkt 't gewoon.

Als je iets anders wilt dan char's naar int's converteren (wat je nu dus doet), dan zul je het wat duidelijker uit moeten leggen.

[Verwijderd]

Als ik met een hex-editor het resultaat bekijk, dan is de oorspronkelijke buffer:
80 80 80 74 74 74
en het resultaat
80 00 80 00 80 00 74 FF 74 FF 74 FF
dus... vandaar zei ik: "dit kan niet zomaar".

Is het ook niet mogelijk door een shift (<<8) te doen ofzo? Als ik value=atoi(Buffer0[i]) doe geeft de compiler een warning (atoi makes pointer from integer without a cast) en het programma crasht bij het runnen.

[farlane]

Is Buffer0[i] een pointer dan ? Back to basics my son

[Verwijderd]

Op donderdag 16 mei 2002 16:29 schreef farlane het volgende:
Is Buffer0[i] een pointer dan ? Back to basics my son

Hm, ja, vergeten te vermelden. Buffer0 is een lokale copie van een char *Buffer dus inderdaad een pointer. Maar mijn vraag blijft, hoe los ik dit dan op

[Soultaker]

Op donderdag 16 mei 2002 16:00 schreef zeronegative het volgende:
Als ik met een hex-editor het resultaat bekijk, dan is de oorspronkelijke buffer:
80 80 80 74 74 74
en het resultaat
80 00 80 00 80 00 74 FF 74 FF 74 FF
dus... vandaar zei ik: "dit kan niet zomaar".

Volgens mij begrijp ik je probleem nog steeds niet. Als je op die FFjes doelt; dat komt door de sign-extension (je convert signed chars naar signed ints). Als je die kwijt wilt, moet je je char values eerst naar unsigned chars casten.

ie.

code:

  buffer1[i] = ((unsigned char*)buffer0)[i];

[Marcj]

short int is toch hetzelfde als WCHAR?

[topic=184916]

oud topic van mij

[Soultaker]

Op donderdag 16 mei 2002 16:52 schreef Marcj het volgende:
short int is toch hetzelfde als WCHAR?

Ow, is DAT de bedoeling! Daarvoor hebben we toch standaardfuncties als btowc (en de rest in wchar.h)?

[Marcj]

Op donderdag 16 mei 2002 16:58 schreef Soultaker het volgende:

[..]

Ow, is DAT de bedoeling! Daarvoor hebben we toch standaardfuncties als btowc (en de rest in wchar.h)?

WideCharToMultiByte()

[MSalters]

Op donderdag 16 mei 2002 16:52 schreef Marcj het volgende:
short int is toch hetzelfde als WCHAR?

[topic=184916]

oud topic van mij

Nee, wchar_t heeft soms net zoveel bits, da's het enige verband.

[MSalters]

Op donderdag 16 mei 2002 16:00 schreef zeronegative het volgende:
Als ik met een hex-editor het resultaat bekijk, dan is de oorspronkelijke buffer:
80 80 80 74 74 74
en het resultaat
80 00 80 00 80 00 74 FF 74 FF 74 FF
dus... vandaar zei ik: "dit kan niet zomaar".

Oftewel:
sequence is eerst
-128 -128 -128 116 116 116
en daarna
-128 -128 -128 116 116 116

Klopt toch?

Sign extension wil je waarschijnlijk wel op een muziek signaal; een sinus golf is 50% van de tijd negatief.

[farlane]

Hm, ja, vergeten te vermelden. Buffer0 is een lokale copie van een char *Buffer dus inderdaad een pointer. Maar mijn vraag blijft, hoe los ik dit dan op

Ik zie in jouw code staan:

code:

char Buffer0[n];

Dus volgens mij is ga je bij:

code:

value = atoi(Buffer0[i]);

De fout in. ( Naast het feit dat dat kennelijk niet was wat je zocht... )

[Verwijderd]

Oftewel:
sequence is eerst
-128 -128 -128 116 116 116
en daarna
-128 -128 -128 116 116 116

Klopt toch?

Sign extension wil je waarschijnlijk wel op een muziek signaal; een sinus golf is 50% van de tijd negatief.

Buffer1 wordt vervolgens gebruikt door de procedure lame_encode(...) en die trekt het niet als er 00's en FF's instaan. Dus ik neem aan dat het een signed/unsigned probleem is... hmm...

[.oisyn]

even voor de mensen die denken dat hij strings gebruikt: hij gebruikt geen strings, maar geluids-data (char voor 8bits, en short voor 16 bits )

maar ik denk dat ik je probleem wel begrijp... een 8-bits geluidssignaal is meestal unsigned, en een 16-bits signaal meestal signed... Bovendien heeft een short (uiteraard) 8 bits meer precisie, dus je moet de uitkomst in de bovenste 8 bits zetten (dus een shift left van

ik denk dat dit beter werkt:

code:

for (i = 0; i < n; i++)
    Buffer1[i] = (short)(((int)Buffer0[i] - 0x80) << 8);

overigens moet je de 8 bits buffer (Buffer0) niet als char definieren, maar als unsigned char

Wat ik hier doe is eerst de waarde van Buffer0[i] converteren naar een int, zodat ik er beter mee kan rekenen. Die waarde ligt tussen 0 en 255, en het rustpunt is 0x80 (128 dus). Omdat 16 bits geluid meestal signed is, loopt dat van -32768 naar 32767, met 0 als het rustpunt.
Dus ik trek er eerst 0x80 vanaf, zodat de waarde tussen -128 en 127 komt te liggen. Daarna schuif ik het 8 bits naar links (zelfde als vermenigvuldigen met 256), zodat de waarde nu tussen -32768 en 32512 komt te liggen (dat klopt niet precies, maar dat hoeft ook niet)

vervolgens maak ik er een short van en zet dat in Buffer1[i]