brunialti:
la libreria String.h consuma parecchio di più ...
solo 20-30 byte in più, in pratica pesano uguali come occupazione di flash, la vera soluzione, per non sprecare flash, è non usare ne la sprintf e nemmeno il formato dati stringa, lavorare con un array di char.
dalla veloce prova empirica sono circa 400.
ma cosa intendi per lavorare con un array di char?
Tanto per avere una idea se posti l'esempio per il problema di questo topic facciamo una rapida verifica di occupazione di memoria ...
Semplicemente usare "char pippo[n]" ove n è il numero massimo di caratteri previsti, come si è sempre fatto in C.
? ma la variabile buf[10] dell'esempio che cos'è?
Scusami, ma non capisco qual'è la tua proposta: niente string e sprintf, ok.
Ma cosa proponi? Se posti il codice vediamo se c'è una soluzione migliore in termini di occupazione per ottenere la stringa che vole Marcoffio.
brunialti:
Scusami, ma non capisco qual'è la tua proposta: niente string e sprintf, ok.
Appunto non usare ne il tipo dati string e tantomeno la sprintf, si lavora direttamente sull'array e non credo che devo spiegarti come ci si caricano sopra i dati e come si fa l'eventuale concatenazione.
Quello che avevo percepito nella richiesta di Marcoffio era un aiuto a capire quali sono i diversi approcci per formattare stringhe apartire da variabili di tipo diverso. Poi sono usciti i discorsi da smanettone sulla occupazione memoria
Io suggerivo la sprintf perchè la richiesta riguardava anche la conversione di un numerico, in questo caso un int.
Lo suggerisco sopratutto a chi inizia e probabilmente non ha problemi di memoria, perchè è molto flessibile.
Io personalmente non amo molto il tipo string in ambienti minimali come arduino, anche perchè spesso crea subdoli problemi di memoria al crescere del codice. Ma credo che sia una questione di abitudine o si stile....
Aggiungo un altro esempio sull'onda di astobeed, usando itoa. In effetti si risparmia circa (ad occhio) 1k.
brunialti:
poi sono usciti i discorsi da smanettone sulla occupazione memoria
Non sono da smanettone, sono discorsi, e metodi, validi per chi con i micro ci lavora e spesso deve combattere con le limitate risorse, oltre all'esigenza produttiva di usare il micro meno costoso possibile, risparmiare decine, se non centinaia, di byte flash/ram è un must