40 replies to this topic

[monelli]

Il C è il MEGLIO.
Non sfottetemi il thread che devo capire ancora cosa mi scrive a cazzo in memoria.

[toyo]

io quando scrivo in C# commento in inglese e attacco una foto dello zio ben alla finestra

[trallallero]

trolled trollallero

Ah quindi trollavi... mi sembrava strano, infatti non puoi esistere un essere vivente che possa apprezzare una merda come il vb6

[trallallero]

Il C è il MEGLIO.
Non sfottetemi il thread che devo capire ancora cosa mi scrive a cazzo in memoria.

Postalo tutto il prog dai.

[yorkeiser]

Il C è il MEGLIO.
Non sfottetemi il thread che devo capire ancora cosa mi scrive a cazzo in memoria.

Solo perchè non hai visto il Memory Laser Blast del c#, che accopiato con il Fotonic Supercazzola Tornado della Microsoft Sarcazzo Technology 47.1 per il Framework .NET 89 offre prestazioni inarrivabili.

[matti157]

Ah quindi trollavi... mi sembrava strano, infatti non puoi esistere un essere vivente che possa apprezzare una merda come il vb6

[monelli]

Postalo tutto il prog dai.

Non posso, e ora non sto lavorando a ciò, quando ho tempo metto i cast come mi hai consigliato e aggiusto le varie sprintf e sscanf testo e mi rifaccio vivo.

[yorkeiser]

Ah quindi trollavi... mi sembrava strano, infatti non puoi esistere un essere vivente che possa apprezzare una merda come il vb6

Sicuro? Ho conosciuto un team leader che ne decantava la pulizia, l'integrabilità con Excel per la reportistica (la metà delle aziende italiane credo faccia reportistica in Excel ), la velocità di sviluppo e l'affidabilità (!).
Ma ho anche conosciuto professori universitari che decantavano le lodi del Prolog, per cui vale sempre il detto "ogni scarrafone è bell' a mamma so'", anche in programmazione

[monelli]

Vedi cose strane in questo:

void Buffer16(uint16_t value, uint8_t *buff)

{

  uint8_t i=0;  

  for (i=0; i<2; i++)

  {

		buff[i]=value%256;

		value/=256;

  }

  return;

}

void Buffer32(uint32_t value, uint8_t *buff)

{

  uint8_t i=0;  

  for (i=0; i<4; i++)

  {

		buff[i]=value%256;

		value/=256;

  }

  return;

}

uint8 a[6];

char buf[100];

uint16 b[4];

uint32 c,d;

Azzero tutto....

sscanf(buffValue,"*%hd/%hd/%hd-%hd:%hd:%hd %d.%d/%d.%d-%ld %ld", &a[0], &a[1], &a[2], &a[3], &a[4], &a[5], &b[0], &b[1], &b[2], &b[3], &c, &d);

memcpy (&buf, a, 6);

Buffer16(b[0], &buf[6]);

Buffer16(b[1], &buf[8]);

Buffer16(b[2], &buf[10]);

Buffer16(b[3], &buf[12]);

Buffer32(c, &buf[14]);

Buffer32(d, &buf[18]);

Tipo il fatto che buf è un char e le funzioni usano uint8...

Edited by monelli, 07 June 2012 - 11:40.

[trallallero]

Per adesso vedo questo:

1) "return" non serve, la funzione torna da sola
2) 256 può dare fastidio al uint_8 perché il max value è 0xff (255) quindi meglio tenerlo fuori dall'operazione in cui c'è un uint8
2) il ciclo non serve, basta un

void Buffer16(uint16_t value, uint8_t *buff)

{

   int val = value%256;

   buff[0] = uint8_t(val);

   val = (val / 256) % 256;

   buff[1] = uint8_t(val);

}

ma visto che cicli nella seconda funzione forse è meglio ciclare anche qui.

[trallallero]

memcpy (&buf, a, 6) è sbagliato.

Ma non ti dico perché

[monelli]

memcpy (&buf, a, 6) è sbagliato.

Ma non ti dico perché

Ho copiato e modificato il codice al volo e mi è sfuggito... ma quello non è il problema, anzi non dovrebbe neanche compliarlo....

[trallallero]

Si infatti almeno un warning dovrebbe dartelo.
Non vedo altri problemi se non troppe costanti.
Io avrei fatto un iteratore che si muove via sizeof, molto più sicuro.

[trallallero]

Però prova a fare i cast come t'ho detto perché se ti si sputtana la variabile "i" del ciclo, sicuramente succede qualcosa di brutto copiando "value".

[monelli]

Visto che sei esperto ti devo chiedere un'altra cosa:

Nella mia architettura:
char sono 8bit: -128 - 127
int sono 16bit -32,768 - 32,767
long sono 32bit ....

Se io utilizzo invece
uint8
uint16
uint32
Dichiaro la stessa cosa?

uint8 a=0;
a--;
Cosa ottengo? 255 se stampo uint8, -1 se casto a char?

uint8 a=255; è corretto no?
char b=a; Cosa ottengo? -1?

Perchè in byte 11111111 se unsigned = 255 se signed = -1
Giusto?

Mi chiarisci sta roba? Grazie

Edited by monelli, 07 June 2012 - 13:20.

[trallallero]

Perché non fai un mini prog di test ?

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char *argv[])

{

   unsigned int a = 255;

   char b = a;

   printf("a: <%hu>n", a);

   printf("b: <%hu>n", B);



   return 0;

}		

compili ed esegui:

gcc test.c -o test
./test

uint8 e char sono diversi, semmai uint8 e uchar sono uguali (e non dovresti avere neanche problemi di little/big endianness).

Perchè in byte 11111111 se unsigned = 255 se signed = -1

Non ho capito se è una domanda

Edited by trallallero, 07 June 2012 - 13:38.

[monelli]

Perché non fai un mini prog di test ?

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char *argv[])

{

   unsigned int a = 255;

   char b = a;

   printf("a: <%hu>n", a);

   printf("b: <%hu>n", B);



   return 0;

}		

compili ed esegui:



uint8 e char sono diversi, semmai uint8 e uchar sono uguali (e non dovresti avere neanche problemi di little/big endianness).



Non ho capito se è una domanda

Con il %hu mi stampa 255 e 65535 perchè li vede come interi, col %hd mi stampa 255 e -1?????

Edited by monelli, 07 June 2012 - 13:57.

[trallallero]

Giusto, perché la printf è un'interpretazione del dato (viene formattato come lo vuoi tu tramite le %).
Per sapere il vero valore dovresti fare delle if/switch.
Ma non ho capito quale sia il problema.

[monelli]

Giusto, perché la printf è un'interpretazione del dato (viene formattato come lo vuoi tu tramite le %).
Per sapere il vero valore dovresti fare delle if/switch.
Ma non ho capito quale sia il problema.

il problema è 65535 mi spieghi da dove viene fuori? e che senso ha? sono su 8bit, perchè tira fuori quel volore?

[trallallero]

Non ne ho idea ma non ci starei troppo a menarla visto che gli stai dicendo di interpretare un 8bits signed come se fosse un unsigned.
Infatti
unsigned char b = a
diventa 255