Go Down

Topic: Classe "SafeString" una valida alternativa alla pessima "String" ... (Read 2965 times) previous topic - next topic

docdoc

tanto vale usare gli array di char e debellare il resto.
Concordo, e se è per questo io non avrei proprio implementato la String sotto Arduino.
IMHO uno che vuole programmare microcontrollori non dico che debba saper programmare in Assembler, ma il C è fondamentale che lo conosca per restare più possibile "a basso livello" con l'hardware, per questioni sia di conoscenza di ciò che si sta gestendo, sia per maggiore controllo dell'efficienza del codice.
Ma se anche fosse, mi vanno ad implementare una classe che fa uno spreco di risorse proprio su una MCU con pochissima RAM? Ok, implementala ma fallo "decentemente" (intendo entro i limiti dell'hardware ovviamente), ed un esempio è proprio questo SafeString che "maschera" la gestione classica C per gestire le stringhe "quasi" come su sistemi più evoluti, ma di fatto ad uso esclusivo degli utenti "abituati" a linguaggi e sistemi di livello più alto.

... in realtà, se andate a leggere, vedrete che era stato chiesto proprio di "riscrivere" la classe String seguendo quanto fatto nella SafeString  ;D  ... la richesta è stata declinata ...
Uh, non me lo spiego, ma ok, no comment...
Alex "docdoc"
- "Qualsiasi cosa, prima di rompersi, funzionava"

gianlucaf

Farò sicuramente una prova.
Devo ammettere che per pigrizia non ho più modificato il mio programma come mi aveva intimato di fare Guglielmo. :D
A mia discolpa c'è da dire che uso le stringhe in lettura quindi non c'è un consumo costante di memoria e non mi ha mai dato problemi.

Qualcuno ha provato a scrivere uno sketch consuma memoria con entrambe le librerie e vedere cosa succede?
Una curiosità, le stesse raccomandazioni valgono anche per altre MCU, tipo una a caso, ESP32?

nid69ita

Qualcuno ha provato a scrivere uno sketch consuma memoria con entrambe le librerie e vedere cosa succede?
Una curiosità, le stesse raccomandazioni valgono anche per altre MCU, tipo una a caso, ESP32?
Cioè NON usare String, ?    Assolutamente si.   Su ESP32 hai solo più memoria SRAM, quindi la microframmentazione potrebbe insorgere dopo più tempo, ma  i problemi intrinseci rimangono.    Non hai un S.O. che fa pulizia/compattazione della memoria
my name is IGOR, not AIGOR

cotestatnt

Cioè NON usare String, ?    Assolutamente si.   Su ESP32 hai solo più memoria SRAM, quindi la microframmentazione potrebbe insorgere dopo più tempo, ma  i problemi intrinseci rimangono.    Non hai un S.O. che fa pulizia/compattazione della memoria
Non è del tutto corretta la tua affermazione. 
La gestione della memoria RAM su ESP32 è completamente diversa da quella degli Arduino AVR.
Inoltre viene usato il kernel FreeRTOS che offre un minimo di gestione della memoria più avanzata (http://https://www.freertos.org/a00111.html).
Ciò detto, tendenzialmente anche io evito di usare il più possibile la classe String, ma ci sono alcune situazioni in cui alla fine si rivela la scelta migliore e tutto dipende da come la usi. Ad esempio, se vuoi sviluppare una libreria per Arduino, dove la classe String è stra-usata soprattutto negli esempi, "constringere" l'utente neofita ad usare metodi più memory safe può essere complesso e controproducente (la maggior parte delle persone al primo segno di difficoltà passa oltre).
Ecco allora che una bella funzione in overload può salvare capra e cavoli.

maubarzi

...
Ciò detto, tendenzialmente anche io evito di usare il più possibile la classe String, ma ci sono alcune situazioni in cui alla fine si rivela la scelta migliore e tutto dipende da come la usi. Ad esempio, se vuoi sviluppare una libreria per Arduino, dove la classe String è stra-usata soprattutto negli esempi, "constringere" l'utente neofita ad usare metodi più memory safe può essere complesso e controproducente (la maggior parte delle persone al primo segno di difficoltà passa oltre).
Io non sono d'accordo.
Una strada semplice ma sbagliata, porta solo a problemi, fa si che le persone si adagino e si abituino sempre alle cose semplici innescando un circolo vizioso verso il peggio.
Le persone sono in grado di imparare ogni cosa, quando gli serve, se però gli affianchi una cosa facile, li rendi pigri e non si impegneranno mai a studiare perchè a prima vista non gli pare sensato e quando si accorgono che la strada facile è sbagliata, ormai è troppo tardi. Invece di ripartire nel modo corretto cercano accrocchi di ogni tipo pur di non cambiare, perchè a questo punto vuol dire dover rimettere mano a troppe cose.
Lo vedo di continuo.
E vedo che cose difficili, senza scorciatoie, vengono assimilate senza problemi se adeguatamente spiegate ma soprattutto senza che ci siano strade apparentemente più facili e consuete.

Maurizio
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

cotestatnt

Maurizio il tuo discorso non fa una piega e lo trovo del tutto condivisibile.
Il fatto è che io non ritengo a priori "una strada sbagliata" usare la classe String, mentre lo è di sicuro usarla male.

E' come se io dicessi a qualcuno che il saldatore non te lo faccio usare perché è pericoloso.
Non è meglio insegnare ad usare qualcosa facendo le dovute raccomandazioni sui rischi che si possono incontrare e su come evitarli?

Standardoil

il socio si è dimostrato di nuovo mio "fratello di quaderno a quadretti", il suo ultimo intervento potrei averlo scritto io,

comunque usare la classe String senza un sistema operativo è la versione informatica della roulette russa

non è 'possibile' che succedano casini: è "sicuro"

l'unica parte incerta è "quando" succederanno

e non cominciamo con le storie che basta dichiarare l'oggetto String locale perchè le cose tornino a posto quando l'oggetto stesso "decade" alla fine della funzione

chi dice che sia vero? la classe string usa la gestione dinamica della memoria, tutte le considerazioni sul "tempo di vita" delle variabili sono aria fritta

e comunque, un programmatore che è in grado di fare di queste sottigliezze conosce abbastanza della programmazione per NON usare la classe String, e quindi mi fa, a me personalmente, il favore di non farlo con arduino, altrmenti lo metto nel nel cerchio Settimo, Terzo girone dell'Inferno: Bestemmiatori e 'String'oisti

Prima legge di Nelson (che sono io): fare cappelle solo perché non si vuole imparare a lavorare bene ti declassa agli occhi di chi invece bene ci lavora
Non presurrò più la buona fede di chi:
NON indenta, USA la classe String o NON esegue le ricerche
E di chi non risponde alle domande Tante volte è stato segnalato che è sbagliato, quindi NON sono in buona fede
Non bado a studenti, che copino altrove

gpb01

... Il fatto è che io non ritengo a priori "una strada sbagliata" usare la classe String, mentre lo è di sicuro usarla male. ...
... il fatto è che la maggior parte di quelli che qui arrivano (oltre il 90%) sono utenti di MCU AVR, spessissimo di piccolo taglio ... ATmega328P e ... con soli 2 KB di SRAM, mettila come vuoi ... alla fine vai nei casini, quindi ... meglio prevenire e dirgli di non usarla (poi, se mai un giorno andranno a programmare su qualche cosa di più completo, magari con un OS che gestisce la memoria, allora vedranno che le cose cambiano ;)).

Guglielmo

PS: mi sono sovrapposto al post di Standardoil ... :D
Search is Your friend ... or I am Your enemy !

maubarzi

Continuo a non essere d'accordo.

E' come se io dicessi a qualcuno che il saldatore non te lo faccio usare perché è pericoloso.
In realtà, per fare un paragone corretto, si dovrebbe considerare un saldatore che dopo un certo tempo, dipendente dal lavoro che se ne deve fare, fa saldature fredde (cioè talmente bacate da non far contatto).
Ok, normalmente lo fa dopo ore, quindi se lo usi per piccoli lavoretti non incappi nel problema, ma perchè usare questo saldatore se con un piccolo costo aggiuntivo ne puoi avere uno che non avrà mai problemi?

Ecco, questo sarebbe un paragone un po' più calzante.

Una classe che frammenta la memoria, non può essere usata bene o male. Se la usi ti tiri dietro il suo problema se non la usi no.

La questione è tutta qui.
Poi, tutti i linguaggi di alto livello usano una implementazione della classe String, ma li è tutta un'altra storia, c'è un gestore che si occupa di tenere la memoria in ordine e non si hanno risorse così limitate.

Personalmente ritengo che chi scrive librerie per Arduino usando la classe String, non pensa che le sue librerie possano venire usate in progetti che devono girare per molto tempo.
Altrimenti non userebbero certe bombe ad orologeria.

Poi, ognuno è libero di farsi del male come meglio crede, ma ritengo che sia un approccio culturalmente sbagliato.

Maurizio

P.S.
il socio si è dimostrato di nuovo mio "fratello di quaderno a quadretti", il suo ultimo intervento potrei averlo scritto io,
Socio, lo ammetto, ho copiato  ;D
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

cotestatnt

Ragazzi io non voglio insistere più di tanto, però qui mi sembra che ci sia un po' di talebanesimo nei confronti di questa povera classe quindi vedo di finirla prima di essere passato a fil di Kalashnikov (sto scherzando eh ;) ;)).
Voi dite che frammenta la memoria a prescindere, io dico dipende e che sicuramente ci sono "pratiche da neofita" molto più dannose dell'utilizzo di String (abuso del delay, convertire 2/3 volte la stessa informazione, utilizzo eccessivo di variabili globali etc etc).

P.S.
Volevo solo aggiungere che io ho realizzato dei progetti dove se ne fa un uso appropriato (a mio modo di vedere) che girano H24 senza il minimo problema ormai da anni, sia su MCU Espressif, ma anche e soprattutto su dei "miseri" ATMega328.
A mio avviso, se un firmware crea problemi, la colpa non è del saldatore ma di chi lo usa.

maubarzi

Io non ho intenzione di passare nessun a fil di spada, per cui tranquillo.
Però il paragone con il saldatore, purtroppo non calza, perchè con il saldatore è ovvio che la colpa è sempre di chi lo usa...
Per il resto, quel che c'era da dire è stato detto sia da parte tua che da parte mia, per cui, non serve continuare ripetendo le stesse cose  ;)

Maurizio
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

nid69ita

e non cominciamo con le storie che basta dichiarare l'oggetto String locale perchè le cose tornino a posto quando l'oggetto stesso "decade" alla fine della funzione
Chi lo dice prende un abbaglio grosso.
Quando un oggetto String viene dichiarato locale, l'oggetto è in memoria stack. Ma la classe String usa internamente malloc,free,realloc,  quindi prende spazio in Heap, che l'oggetto sia locale o globale.   Ovvero il suo membro puntatore a char buffer sempre punta a qualcosa in heap. Ed è quella che si frammenta.

Ragazzi io non voglio insistere più di tanto, però qui mi sembra che ci sia un po' di talebanesimo nei confronti di questa povera classe quindi vedo di finirla prima di essere passato a fil di Kalashnikov (sto scherzando eh ;) ;)).
Voi dite che frammenta la memoria a prescindere, 
Non a prescindere, è facile però avere un uso che frammenta la memoria. E l'utente medio non lo sa/capisce.
my name is IGOR, not AIGOR

gpb01

Vorrei rammentare a tutti un mio post della pagina precedente ...

...
Questo thread è SOLO per informare l'utenza sull'esistenza di un'alternativa e per cercare si aiutare (nei limiti del possibile) chi avesse difficoltà nel suo uso .......
... quindi, magari ora finiamola qui con questa lunga (... se pur interessante) discussione. Grazie ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

drmpf

SafeString V2 is now out. See the  updated tutorial

V2 adds wrapping of char * and char [] in SafeStrings for safe processing that updates the original c-string directly.  
(please excuse my lack of Italian)

gpb01

>drmpf: Hi, thanks a lot for the info ! :)


Quote
E' disponibile l'aggiornamento alla V2 di SafeString V2. QUI il tutorial aggiornato.

La V2 aggiunge il wrapping di "char *" e "char []" in SafeStrings per trattamento corretto e sicuro che aggiorna direttamente la c-string originale.
Guglielmo
Search is Your friend ... or I am Your enemy !

Go Up