[C++] int, array byte

[Q_Q]

INT32 a = 0x00401600;
char c[] = { 0x00, 0x40, 0x16, 0x00 };

perchè sprintf c dà 0x0028fec4

[lorenzo001]

Quale sprintf ?

[Q_Q]

    INT32 a = 0x00401600;
    INT32 b = 0x004016B0;

    char c[] = { 0x00, 0x40, 0x16, 0x00 };
    char d[] = { 0x00, 0x40, 0x16, 0xB0 };

    printf("0x%08x\n0x%08x\n\n", a, b);

    printf("0x%08x\n0x%08x\n\n", c, d);

M'è scappata una s di troppo

[van9]

printf("%s\n", c == &c[0] ? "y" : "n" );

[Q_Q]

y

[lorenzo001]

c e d sono array e quindi visualizzi l'indirizzo dell'array, ovvero del suo primo elemento (che è quello che ti ha spiegato van9)

Per quello che vuoi fare tu, devi indicare che l'indirizzo in questione punta ad un intero e quindi visualizzare il valore puntato, ovvero

printf("0x%08x\n0x%08x\n\n", *((int *)c), *((int *)d));

Tieni presente però che in memoria i valori sono in ordine inverso e quindi devi scrivere

char c[] = { 0x00, 0x16, 0x40, 0x00 };
char d[] = { 0xB0, 0x16, 0x40, 0x00 };

[Q_Q]

Originariamente inviato da lorenzo001

c e d sono array e quindi visualizzi l'indirizzo dell'array, ovvero del suo primo elemento (che è quello che ti ha spiegato van9)

Per quello che vuoi fare tu, devi indicare che l'indirizzo in questione punta ad un intero e quindi visualizzare il valore puntato, ovvero

printf("0x%08x\n0x%08x\n\n", *((int *)c), *((int *)d));

d'oh mi confondo sempre con i puntatori

Originariamente inviato da lorenzo001

Tieni presente però che in memoria i valori sono in ordine inverso e quindi devi scrivere

char c[] = { 0x00, 0x16, 0x40, 0x00 };
char d[] = { 0xB0, 0x16, 0x40, 0x00 };

Quindi i byte di a e c in memoria sono invertiti ?

[lorenzo001]

I byte che compongono l'intero a sono nell'ordine che ti ho indicato, dal meno significativo al più significativo ( per i processori Intel, ordine little-endian, vedi http://it.wikipedia.org/wiki/Ordine_dei_byte )

[Freaxxx]

in realtà tutti gli esempi riportati sino ad ora sono più "scorciatoie" che altro.

è possibile trattare array con l'aritmetica dei puntatori ma un array non è un puntatore e soprattutto ci sono modi migliori di informare il tuo compilatore che stai trattando un array.

Inoltre questo codice è puro C, non esiste nulla che sia C++, non confondete i due linguaggi.

Se dato un array sei interessato ad estrarre o visualizzare gli indirizzi dei suoi elementi ( mi sembra di capire che il problema sia questo ) questo piccolo programma in C ( C99 ) con relativa funzione dovrebbe fare al caso tuo

#include <stdlib.h>
#include <stdio.h>
void printAddr(int (*arr)[], size_t s)
{
    for (size_t i = 0; i < s; i++)
    {
        printf("%p %d\n", &(*arr)[i], *(&(*arr)[i]));
    }
}
int main()
{
    int c[] = {1, 54, 42, 44, 33};
    // esempio su singola riga senza uso
    // di alcuna funzione
    // printf("%p %d\n", &c[2], *(&c[2]));
    printAddr(&c, 5);
    return EXIT_SUCCESS;
}

il punto chiave è che se hai un array arr e vuoi l'indirizzo dell'elemento che trovi con un indice di valore 3, per avere l'indirizzo di quell'elemento usi la sintassi &arr[3] .

[Q_Q]

Originariamente inviato da Freaxxx

è possibile trattare array con l'aritmetica dei puntatori ma un array non è un puntatore

non è un puntatore costante che punta al primo elemento

[Freaxxx]

Originariamente inviato da Q_Q

non è un puntatore costante che punta al primo elemento

dipende a cosa ti riferisci e in quale contesto.

in breve non è possibile dare una risposta in un post, bisogna conoscere il linguaggio e come la macchina e il compilatore opera, comunque sia ritorno a specificare che

puntatore != array

nel mondo della programmazione, specialmente in C e C++, esiste il fenomeno dell'aliasing, e specialmente in C++ l'aliasing è una brutta bestia che può nascondere perdite di performance, https://it.wikipedia.org/wiki/Aliasi...grammazione%29

quando tratti un array come puntatore introduci dell'aliasing, e questo è il motivo per cui all'atto pratico non vedi differenze, ma concettualmente usare un array come o attraverso un puntatore è una cattiva soluzione per diversi motivi.

il problema è anche teorico perché a tutti i "prof" che ho conosciuto piace semplificare e pure troppo; il concetto di puntatore è molto più facile da spiegare e assimilare di tutto il resto, e quindi ogni buon prof di informatica ti ripete che tutto può essere un puntatore e tutti son felici e contenti, stessa cosa dicasi per alcuni libri. Inutile dire che non è così.

se sei interessato a studiare il linguaggio ci sono gli standard ISO ( ISO/IEC 9899:1999 per il C99 ) se sei un programmatore occasionale il tuo codice sarà orribile ma all'atto pratico non vedrai molte differenze ( "il programma funziona!" cit. ) e vivrai contento .

[WarDuck]

Tralasciando le questioni di performance (premature optimization is the root of all evil), la cosa è un pelo delicata.

Un esempio semplice per capire come il compilatore tratta differentemente le cose:

char mio_array[20];

printf("SizeOf: %lu\n", sizeof(mio_array)); // stampa 20

char* mio_array = alloca(20); // alloca 20 bytes sullo stack

printf("SizeOf: %lu\n", sizeof(mio_array)); // stampa 4 o 8 (a seconda dei casi)

[vbextreme]

@freaxx io avrei preferito altre alternative al tuo codice, quali:

void old_printAddr(int (*arr)[], size_t s)
{
    for (size_t i = 0; i < s; i++)
    {
        printf("%p %d\n", &(*arr)[i], *(&(*arr)[i]));
    }
}

void simple_printAddr(void *arr, size_t s)
{
    int* a = (int*) arr;
    while(s--)
    {
        printf("%p %d\n", a, *a);
        a++;
    }
}

void versatile_printAddr(void *arr, size_t s, size_t n, const char* vw)
{
    char* a = (char*) arr;
    char v1[80];
    char v2[80];

    while (n--)
    {
        sprintf(v1,"%p ",a);
        sprintf(v2,vw,*a);
        strcat(v1,v2);
        puts(v1);
        a += s;
    }
}

int main()
{
    int c[] = {1, 54, 42, 44, 33};
    char x[] = {'a','b','c'};
    // esempio su singola riga senza uso
    // di alcuna funzione
    // printf("%p %d\n", &c[2], *(&c[2]));
    puts("Simple Vector int");
    simple_printAddr(&c, 5);

    puts("Versatile Vector int");
    versatile_printAddr(&c, sizeof(int), 5,"%d");
    puts("Versatile Vector char");
    versatile_printAddr(&x, sizeof(char), 3,"%c");

    return 0;
}

Ho poi bloccato lo standard c99 quindi non l'ho nemmeno compilato il tuo codice.

||=== Build: Debug in iop (compiler: GNU GCC Compiler) ===|
main.c||In function ‘old_printAddr’:|
main.c|71|error: ‘for’ loop initial declarations are only allowed in C99 mode|
main.c|71|note: use option -std=c99 or -std=gnu99 to compile your code|
||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Niente flame però! solo questione di gusti personali.

[van9]

Originariamente inviato da Antonio23

in soldoni, si. la principale differenza è che è un puntatore costante e la memoria è sempre allocata al momento della definizione dell'arra stesso.

No, e basta passare il nome di un array come parametro ad una function per dimostrarlo: il nome dell'array decade immediatamente a puntatore ed è possibile assegnare al nome stesso un nuovo valore (ovvero niente comportamento da "puntatore costante"). Per un esempio di array la cui memoria non è allocata a tempo di definizione vedi i flexible members in C99.

[van9]

Originariamente inviato da Q_Q

non è un puntatore costante che punta al primo elemento

No. Un array, un puntatore e un puntatore costante sono tre cose differenti.
Il nome di un array viene convertito ("decade") a puntatore quando serve, ma questo non lo rende o trasforma in un puntatore.

Due sono le cose: o ha ragione Dennis Ritchie (autore del C) quando dice che, date le evidenti difficoltà dei più a capire la natura di arrays e puntatori in C, stiamo parlando di un errore di design e quindi è facile che i più trovino difficoltà.
Oppure i programmatori non si applicano davvero/non vanno in fondo alle questioni.

Se vuoi imparare una volta e per tutte come stanno (semplicemente) le cose, studiati attentamente http://cm.bell-labs.com/who/dmr/chist.html e dopo vedrai non ci sarà più alcuna confusione.

[Q_Q]

Mi hanno passato questo:
Deitel & Deitel - C, Corso completo di programmazione
va bene se (re)inizio con quello

[van9]

Originariamente inviato da Freaxxx

in realtà tutti gli esempi riportati sino ad ora sono più "scorciatoie" che altro.

Ma se non hai nemmeno centrato la richiesta dell'OP! (vedi sotto)

è possibile trattare array con l'aritmetica dei puntatori ma un array non è un puntatore e soprattutto ci sono modi migliori di informare il tuo compilatore che stai trattando un array.

A vole essere precisi semmai dovevamo informare noi l'OP che aveva un overflow in atto. Noia e pigrizia da parte mia l'altro giorno.

Inoltre questo codice è puro C, non esiste nulla che sia C++, non confondete i due linguaggi.

Io non confondo proprio nulla e nemmeno Lorenzo mi pare - quanto scritto è per definizione codice C++ e quindi non si capisce di che ti lamenti. Tra l'altro come qualunque esperto di C++ dotato di senso pratico e gusto, uso sempre stdio al posto di quella schifezza stateful di iostream e proprio in questo esempio non c'è discussione al riguardo.

Se dato un array sei interessato ad estrarre o visualizzare gli indirizzi dei suoi elementi ( mi sembra di capire che il problema sia questo )

No, l'OP si chiedeva perché due chiamate a printf non producessero lo stesso risultato - il problema è il classico di chi pensa che attraverso il solo nome di una struttura dati possa avere accesso unitario/completo ad essa.

questo piccolo programma in C ( C99 ) con relativa funzione dovrebbe fare al caso tuo

Ma non era taggato "C++" il thread? In C++ valido, e molto più chiaramente:

void _printAddr(int arr[], size_t s)
{
    for (size_t i = 0; i < s; i++)
    {
        printf("%p %d\n", (void *) &arr[i], arr[i]);
    }
}

il punto chiave è che se hai un array arr e vuoi l'indirizzo dell'elemento che trovi con un indice di valore 3, per avere l'indirizzo di quell'elemento usi la sintassi &arr[3] .

Più che altro restava da chiarirgli la questione dello storage, con cui può divertirsi tramite qualcosa tipo

size_t n = sizeof(c)/sizeof(c[0]);
for (size_t i = 0; i < n; i++)
    printf("%s%02x%s", !i ? "0x" : "", c[i], i == n-1 ? "\n" : "");

e/o

printf("0x%02x%02x%02x%02x\n",
     *((int *)c) & 0xff,
    (*((int *)c) >> 8) & 0xff,
    (*((int *)c) >> 16) & 0xff,
    (*((int *)c) >> 24) & 0xff);

Tutto rigorosamente scritto al volo e non testato. Il problema dell'overflow è lasciato come esercizio per l'OP.

[van9]

Originariamente inviato da WarDuck

Tralasciando le questioni di performance (premature optimization is the root of all evil), la cosa è un pelo delicata.

E' più una questione strutturale e di linguaggio che altro - chi conosce anche Fortran (arrays "veri", restricted pointers, etc.) lo sa bene. E no, ovviamente non si risolve nulla utilizzando solo ed esclusivamente gli arrays piuttosto che i puntatori (perché questo non garantisce all'optimizer l'assenza di aliasing - vedi anche la keyword restrict in C99 per una direzione standardizzata sulla faccenda).

[Freaxxx]

@var9 di precisazioni se ne possono fare sempre tante, il codice era chiaramente un esercizio in C a differenza di quanto scritto nel titolo ( C++ ).

Considero comunque quanto postato un passo in avanti nella giusta direzione per l'OP, è inoltre una soluzione molto più asciutta e compatta, con 1-2 novità che OP può studiare per comprendere meglio come si possa implementare quanto chiesto.

Onestamente in questi frangenti gradisco più usare C++ che C, il motivo per il quale non ho offerto un esempio l'ho già menzionato, peraltro OP ha appena citato un libro sul C .

La gestione della memoria in C e/o C++ è sempre un punto critico, è talmente importante che molto spesso la fonte dei problemi in termini di affidabilità e performance in software scritto usando questi due linguaggi è quasi sempre da ricercare li e raramente altrove ( considerando un codice grammaticalmente e logicamente corretto ) .

Ma non mi metto certo a discutere di gestione della memoria in un post su un forum, solo per trattare gli allocatori in C++ servirebbe un libro, se ci mettiamo pure le varie differenze specifiche alle varie piattaforme, come il comportamento delle funzioni della famiglia *alloc* ci servono mesi di trattazione in C e C++ .

Tutto ciò è sicuramente interessante ma inopportuno per un post di risposta ad una domanda semplice come questa che è in realtà un piccolo esercizio per inziare. Se OP vorrà si prenderà un bel compilatore, debugger e profiler, un bel manuale o libro sul C, e approfondirà da solo.

Non intendo entrare in polemica con nessuno ma è la mia personale visione su come si dovrebbe insegnare un linguaggio come il C o il C++ ad un novizio; un esempio che può apparire stupido ma stupido non è

listato 1

int main()
{
  ...
  return 0;
}

listato 2

#include <stdlib.h>
int main()
{
  ...
  return EXIT_SUCCESS;
}

e la domanda in questo caso è: quale dei due prototipi scegliereste come modello per creare esempi in codice C per un novizio ?

Adesso fate mente locale a quante volte avete visto persone scrivere

return 0;

anziché

return EXIT_SUCCESS;

, oppure quante volte persone che fanno questo lavoro hanno usato

return EXIT_SUCCESS;

senza usare la giusta inclusione, il giusto header. Questo genere di cose viene prima della teoria sulla memoria e le allocazioni e deallocazioni, se non conosci la sintassi da usare per dichiarare un puntatore ad un array o come si può dedurre l'indirizzo di un elemento di un array dato il suo indice, della teoria sulla memoria non te ne fai nulla; anche perché poi inizi a prendere questa sintassi come abitudine e finirai per scrivere sempre

return 0;

anche sapendo che è un approccio non standard e meno portabile.

[Freaxxx]

Originariamente inviato da Q_Q

Mi hanno passato questo:
Deitel & Deitel - C, Corso completo di programmazione
va bene se (re)inizio con quello

si, i Deitel credo che vadano bene per un novizio.

da notare anche che il libro di riferimento per il C ( http://www.amazon.com/The-Programmin...dp/0131103628/ , esiste anche l'edizione tradotta in italiano ) è più strutturato come un manuale che come un libro per i novizi che vogliono partire con il C, è un po' più formale e meno incentrato su questioni di programmazione generale, rimane tuttavia una ottima alternativa.