Das Problem ist, dass auf einer x86 Architektur die Bytegrößte eines normalen Integers (und der ist eigentlich ein: signed long int) 4 ist, also 32 Bit.
Ein char ist allerdings nur 1 Byte groß (8 Bit).

Mit expliziten Typecasts von signed long int zu char kommt man zwar weiter, aber die übrigen 3 Bytes bleiben dann auf der Strecke. Wenn du wirklich nur chars übertragen kannst, dann wirst du wohl nicht um 4 Übertragungen von je 1 Byte (also char) herumkommen.
Aber wie rippchen ja schon gesagt hat, ich würde mal gucken ob das nicht auch anders geht.

cya
liquid

PS:
[code]
void split_int_into_char(signed long int the_int, char* the_chars)
{
char* ptr = &the_int; // guck mal welcher typecast da passt

// kein loop wegen dem overhead
the_chars[0] = ptr[0];
the_chars[1] = ptr[1];
the_chars[2] = ptr[2];
the_chars[3] = ptr[3];
}

EDIT: Da die Datentypen nicht verwandt sind, würde ich die Holzhammermethode, also reinterpret_cast benutzen.

Zitat von »Sebastian«

Hallo,
mir würde spontan sowas dazu einfallen,
CHR --> INT

int Zahl;
unsigned char a,b,c,d;
// A = msb C = LSB

Zahl = ( (a<<24)&#124(b<<16)&#124c<<&#124d) );



INT --> CHR

int Zahl;
unsigned char a,b,c,d;
// A = msb C = LSB

a= (zahl>>24);
b= (zahl<<&(zahl>>24); // erst nach lins schieben um die MSB zu löschen dann nach rechts um in 8 bit zu kommen
c= ..
d...


-------------------------------------------------
in ANSI C funtioniert das , da C ja eine untermenge von C++ ist sollte es auch in C++ funkt. ,.. das einzige problem ist das diese routien von der implementation des Compilers abhängen und unter umständen nicht auf eíner 64bit maschiene oä. laufen.


MfG
Sebastian

Ist das nicht ein wenig zu viel Bitshifting? Nichts gehen die Methode, aber sie ist recht ineffizient.
Ich finde sowieso das diese Konvertierung nicht die Lösung für das Problem sein sollte. Versuch lieber irgendeine Möglichkeit zu finden, die Datenmenge zu spezifizieren, sonst musste wirklich jeden Datentyp erst zerlegen vorm Senden.

cya
liquid

Zitat von »cobra224«

Hi,

ich würde es ein bisschen wie LiquidAcid machen, nur schneller.

Casting von int nach char:

int iInteger = 0;
char* pCharToInteger = &iInteger;


Casting von char nach int:

char cCharInteger[sizeof(int)];
int* pInteger = cCharInteger;


Natürlich sollte beim Senden die Länge des Integers berücksichtigt werden. Somit sind für ein Int auf jeden Fall 4 chars zu senden.

mfg,
cobra224

Ich glaube dennoch, dass cobra Code am schnellsten laufen wird, besonders wenn man gegen die C++ Regeln C-Style-Cast benutzt, die sind ja ungeprüft und erzeugen keinen zusätzlichen Code.
Das einzige was hierbei geschieht sind Allokierung von 32Bit für den Pointer und eine Zuweisung.
Bei deinem int_to_char haben wir auch eine Allokation von 32Bit (4 mal einen Char), aber gleich 4 Zuweisungen und mehrere Bitshifts.

Korrigier mich wenn ich da falsch liege, aber wenn die Daten richtig bereitliegen, dann ist cobras Code doch optimal. Zwar ein wenig unschöne Pointergeschichte, aber darüber kann man ja wohl hinwegsehen.

cya
liquid

Zitat von »cobra224«

Was nützt den das Anlegen eines neuen Char-Feldes?
Nach meinem Erinnerungsvermögen muß dem Win32API od. MFC Befehl eh ein Char-Pointer übergeben werden.
Ausserdem liegt der Vorteil im Casting darin, daß du nicht eine weitere Variable mit Werten anlegen mußt.
Desweitern dauert das Shiften auf eine neue Var länger als nur einen Pointer zu verweisen. Es wird nur die Adresse des Char-Feldes dem Int zugewiesen und das macht der Compiler.

mfg,
cobra224

Full ACK, besonders wenn die Zuweisung ungeprüft stattfindet.

EDIT: -> C Wars - Return of the wild pointer ;D

EDIT2: Jemand eine Ahnung ab welcher Optimierungsstufe Divisionen mit konstanten Variablentypen in Multiplikationen mit dem reziproken Wert umgewandelt werden?
Also wenn ich jetzt folgendes schreibe


Dann wär man ja schön doof, wenn man die Division da so einfach stehen lassen würde. Das verbrät ja Takte en masse.

Also wann fudelt der Compiler das um?

Zitat von »cobra224«

Ich vermute, daß der Compiler beim Übersetzen dies direkt optimiert. Hängt wahrscheinlich von der Optimierungseinstellung des Compilers ab.
Beim MS Studio ist es eine Grundeinstellung das Konstanten in Verbindung mit Operatoren optimal compiliert werden.
Aber 100% bin ich mir nicht sicher.

mfg,
cobra224

EDIT: -> C Wars - The NULL-Pointer strikes back

Na dann muss ich mal wohl den kompilierten Code auseinandernehmen und mir das ASM angucken. Vielleicht werd ich draus schlau... :

@hus: Du hast nicht zufällig auch Ahnung von i386/x86 Assembler? Im speziellen vielleicht auch AT&T Assembler Style? Nur so eine Idee, ich bräuchte da nämlich ein wenig Hilfe.

cya
liquid

Ich weiß auch nicht genau, ob es überhaupt eine Spezialfrage ist. Jedenfalls geht es um folgendes. Ich hab versucht Intel Assembler Code auf AT&T Assembler zu "übersetzen", damit ich diesen im GCC verwenden kann. Allerdings funzt das ganze überhaupt nicht.
Problem ist, dass er mir beim Linken meldet "undefined reference to valueX".



Ich wundere mich nur, weil in der Doku steht, dass im Assembler Code die gleichen C-Variablennamen gelten, wie im C-Code. Also warum kann er dann value0, value1, value2 und value3 net finden? Irgendwie hab ich glaubich den Syntax nicht so richtig.

cya
liquid