Array e dimensione

Buona sera,
oggi mi sono trovato in una situazione alquanto bizzarra, che mi ha fatto perdere un bel po' di tempo. Premesso che ormai da molti anni in azienda usiamo un linguaggio (molto simile al c++, anche troppo) nel quale il primo elemento di un array e' 1, e non zero come nel c++, pertanto ho fatto confusione per abitudine. ma la cosa strana (almeno per me) e' che con codice analogo a questo

  byte apippo[] = {000, 000, 000, 000};
  apippo[1] = 255;
  apippo[2] = 255;
  apippo[3] = 255;
  apippo[4] = 0;
  Serial.print(apippo[1]);Serial.print(".");
  Serial.print(apippo[2]);Serial.print(".");
  Serial.print(apippo[3]);Serial.print(".");
  Serial.println(apippo[4]);              //Stampa 255.255.255.0

non ottengo nessun tipo di segnalazione dall'ide, inoltre se tento di stamparlo il risultato e' esatto, ma nel momento in cui vado a scrivere l'array sulla EEPROM... il dto e' ovviamente sbagliato.
E' normale che l'ide compili il codice senza nemmeno una segnalazione, o e' il mio ide che ha problemi?

Si, è normale che non esca alcun errore o warning.

Scusa rileggendo il codice, penso che almeno un warning l'avrebbe dovuto sollevare. Non so devo verificare. Comunque prova tra le opzione del IDE quella per abilitare tutti i warning, perché di default un tempo erano tutti disabilitati, ora non so.

L'IDE usa il compilatore gcc, anche questo non si accorge di questi "errori", ma non è che debba accorgersi. Diciamo che è un linguaggio molto efficiente specie con gli array (derivati dal linguaggio C). Ma entrambe i linguaggi assumono per scontato che il programmatore sappia il fatto suo.

In genere con le primitive (gli array) non c'è modo per il compilatore di intervenire, mentre con gli oggetti (classi) questo non accade, ma qui stiamo programmando una CPU che ha risorse limitate e non c'è spazio a sufficienza per le librerie C++. Però esiste una libreria STL, la trovi qui.

Ok, ho fatto solo qualche piccolo test al simulatore online wokwi con questa funzione:

void testArray() {
  byte apippo[] = {000, 000, 000, 000};
  Serial.print("indirizzo di apippo: ");
  Serial.print((uint16_t)&apippo);
  Serial.print("("); 
  Serial.print((uint16_t)&apippo, HEX);
  Serial.println(")");
  apippo[1] = 255;
  apippo[2] = 255;
  apippo[3] = 255;
  apippo[4] = 0;
  Serial.print(apippo[1]);Serial.print(".");
  Serial.print(apippo[2]);Serial.print(".");
  Serial.print(apippo[3]);Serial.print(".");
  Serial.println(apippo[4]);              //Stampa 255.255.255.0
}

Ciao.

Impostando su ALL, l'altro giorno ha rilevato che l'array ver (p. es. v1.5_prova_t1, estratta dai caratteri dopo la 'v' nel nome della cartella del progetto) era di 12 caratteri, mentre era dimensionato per 10!

Ma ti ha dato un warning il che significa che ha compilato.
Potresti provare la funzione che postato.

Dovrebbe stampare:

indirizzo di apippo: 2296(8F8)
255.255.255.0

Sono quasi certo che non solleva alcun warning figuriamoci un errore.
Ciao.

Grazie per le tempestive risposte.
E' vero che un programmatore dovrebbe conoscere il fatto suo, ma a volte si e' portati a pensare che tutti gli strumenti funzionino nello stesso modo e quindi da li nascono gli errori.
Pero' pensandoci bene in effetti l'istruzione viene eseguita correttamente, e siccome io sono un ottimista, ho pensato ... vuoi vedere che ora si puo' cambiare la dimensione degli array dinamicamente? ... sarebbe una cosa fantastica., ma la documentazione dice il contrario.
In realta' sembra che si comporti come una memset, bisogna solo capire se poi si ricorda di avere utilizzato un'altra locazione ... faro' alcune prove.
Grazie ancora.

Tutto normale, sei stato fortunato ... il compilatore prende l'array, vede la dimensione di ogni elemento, parte dall'indirizzo del primo elemento (elemento 0) e, per ogni indice, calcola di quanto si deve spostare ... se il tuo elemento 4 finisce su una zona di memoria non utilizzata, la cosa funziona e ti sembra che non ci siano problemi, se invece sovrascrive qualche cosa ... iniziano i guai, incluso perdere completamente il controlo del programma.

Qui non hai un sistema operativo con un sistema di memoria protetta in cui, se ti azzardi ad uscire dalla memoria che avevi allocato, il sistema operativo di blocca; qui sono semplici istruzioni in sequenza che vengono SEMPRE eseguite così come il programmatore le ha scritte e se ha commesso un errore ... ne paga le conseguenze. :roll_eyes:

Guglielmo

come immaginavo, ma l'ho detto sono ottimista di natura :-).
Il fatto e' che sto lavorando al mio data logger e contemporaneamente scrivo sul pc con un linguaggio e su arduino con un altro ..... a volte faccio confusione (sara' l'eta').
Ora che ci penso mi pare che quando usavo il turbo c sui pc xt... Con una istruzione del genere ti arrivava una scossa ad alta tensione sulla tastiera :slight_smile:
Grazie per la risposta

Già che hai fatto questa riflessione, tienila sempre a mente. Tieni anche a mente che ciò che fai con le applicazioni equivale a vedere uno spettacolo al teatro dove non sai nulla di ciò che accade dietro il sipario. Il meglio dello spettacolo è dietro e davanti il sipario, quello che c'è davanti è solo una rappresentazione semplificata di comodo che gli sviluppatori si sono inventati.

Mal comune mezzo gaudio, si dice così ma non corrisponde mai alla realtà.
Chi ha già esperienza con la programmazione su PC e passa al lato oscuro (embedded) cade sempre negli stessi errori. Purtroppo non c'è modo di evitarli poiché sono tanti ma l'unica cosa vantaggiosa può essere quello di dare per scontato che è un altro mondo con altre regole e principi fisici sconosciuti. Ad esempio sul PC la memoria ram è considerabile come una risorsa infinità, cioè non accadrà mai che un allocatore di memoria dinamica fallisca. Con arduino e simili questo accade e quando accade sei nelle sabbie mobili 1 metro sotto la superficie. :smile:

Ciao.

Bene, buono a sapersi, effettivamente gli avr sono un altro mondo, ed e' gia' una grande cosa che si possano programmare con un linguaggio "universale" se pur con i limiti del caso. Certo e' che gli array sono molto potenti soprattutto quelli multidimensionali ... si possono fare cose incredibili in ram. Vorra' dire che si fara' attenzione.
Grazie ancora a tutti per i suggerimenti e le informazioni