Newsgroup: it.comp.lang.c
Titolo: Non conosco quest'operatore >>

Sto cercando di decifrare il significato di questa espressione qualcuno mi 
puň aiutare:
(
      (
      (
            (data[1] >> 4) * 10 +
            (data[1] & 0xF) +
            (data[0] >> 4) / 10.0 +
            (data[0] & 0xF) / 100
      )
      - 30.0
      )
)
data[1] e data[0] sono array di tipo char.
Operazione č una formula che converte un dato in HEX in un DEC mediante 
l'uso di questa formula per raggiungere l'obietivo.
Ma non so cosa significa ">>"
e poi vorrei avere conferma dell'operatore &, che mi pare effettui una 
conversione di dati, in questo caso da chat a byte. Giusto?

 conversione di dati, in questo caso da chat a byte. Giusto?
un'altra operazione con i bit: & e' un AND (vedi sempre link sopra)
PS: ma di preciso cosa volevi fare? convertire una stringa hex in un 
numero decimale?
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

> Operazione č una formula che converte un dato in HEX in un DEC mediante 


 quindi cosa restituisce?
in pratica restituisce gli ultimi 4 bit di data[1],
perche' 0xF vale 15, ovvero  1111 in binario.
Naturalmente puoi vederlo anche come il resto della divisione
di data[1] per 16.
ciao,
g.


--
Giorgio Silvestri
DSP/Embedded/Real Time OS   Software Engineer

 CHAR_BIT = 8 (com'è di solito).
Giustissimo. Nel mettere un tipo di dato 'al volo' mi e' sfuggito :)


 Operazione è una formula che converte un dato in HEX in un DEC mediante 


 posso implementarlo matematicamente?
("un implementa" == non implementa?)
Senza 'shift' e 'and':
...
         double f;
         unsigned char data[2] = { 0x32, 0x45 };
         f = (data[1] / 16) * 10.0 +
         (data[1] % 16) +
         (data[0] / 16) / 10.0 +
         (data[0] % 16) / 100.0;
         printf("%.2f\n", f);
...
NB: pero' e' importante (come gia' fatto notare) che il tipo di "data[]" 
sia "unsigned char".


 16 e poi dividere per 100  --> (data[0] %16 ) /100
...e comunque l'esempio che usi e' sbagliato: non converte correttamente 
in un double ("... / 100" anziche' "... / 100.0")
Ragiona con questa:
         unsigned char data[2] = { 0x87, 0x98 };
         double f = ((data[1] >> 4) & 0xf) * 10.0 +
		(data[1] & 0xf) +
		((data[0] >> 4) & 0xf) / 10.0 +
		(data[0] & 0xf) / 100.0;
         printf("%.2f\n", f);
oppure con questa (che imho e' meglio):
 
	unsigned char data[2] = { 0x87, 0x98 }; /* "unsigned" qui e' opzionale */
         double f = ((data[1] >> 4) & 0xf) * 10.0 +
		(data[1] & 0xf) +
		((data[0] >> 4) & 0xf) / 10.0 +
		(data[0] & 0xf) / 100.0;
         printf("Num = %.2f\n", f);



Dove differiscono ?
A parte la printf naturalmente!
Comunque dovresti usare sempre l'unsigned, non è opzionale.
Infatti staresti assegnando un intero (0x87 o 0x98) ad un
char "signed" con CHAR_BIT = 8 (il caso problematico) con
un valore NON rappresentabile nel range.
Questo invoca "Comportamento Definito dall'Implementazione".
Oppure ci può essere una "signal" sempre definita
dall'implementazione: "Standard C99: 6.3.1.3.p3"


 dall'implementazione: "Standard C99: 6.3.1.3.p3"
Ciao


     char data[2] = { -121, -104 };
...oppure, in modo piu' leggibile, con delle "character costants",
eg.:
	char data[2] = { '\x87', '\x98' };
Questa assegnazione (se non ho commesso errori di interpretazione) e' 
considerata dallo std. C99. Perche', comunque, *in questo caso*:
    '\x87' viene convertito in un "int" == -121
    '\x98' viene convertito in un "int" == -104



Il caso <problematico> era effettivamente solo 0x80 (-128).
Gli altri valori sono esprimibili.
Considera anche che non essendo univoco il modo
di rappresentare i negativi (complemento a 2, a 1 e modulo e segno)
quando si fanno cose del tipo:
    a & 0xF
con "a" negativo potresti avere delle sorprese.
Per questo preferisco, in questi casi, usare i tipi 'unsigned'.
Riducono le sorprese.
Tutto qui! :-)


 di rappresentare i negativi (complemento a 2, a 1 e modulo e segno)
Anche questo e' vero.
PS: e' anche da dire (ovviamente sempre imho) che lavorando con i bit e' 
facile cadere in algoritmi non universalmente portabili - anzi, sarebbe 
meglio conoscere molto bene il sistema (o i sistemi) di destinazione e 
concentrarsi su quelli.
