Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
Codificatore - Versione 1.3

Codificatore

Sommario | Admin | Forum | Bugs | Todo | Files

Pagine: [ 1 2 ] Precedente | Prossimo
Avatar
AldoBaldo (Member)
Expert


Messaggi: 345
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 16:29
Sabato, 14/02/2015
Terminata l’avventura coi 104 “piccoli diavoli” che mi han tenuto impegnato (e quanto!) lungo la settimana, ho potuto tornare ad occuparmi del “Codificatore”. Tenendo conto delle osservazioni di TheDarkJuster ho ritoccato alcune cose:

1. Le proprietà private “dati” e “chiave” ora sono completamento opache all’esterno della classe.
2. La classe si occupa direttamente del salvataggio dei dati codificati/decodificati tramite il metodo salva_dati(), che riceve come parametro il percorso del file nel quale registrare i dati stessi.
3. Le stringhe dei dati e della chiave sono accessibili sotto forma di copie ottenibili tramite i metodi ricava_dati() e ricava_chiave().
4. Anche l’array “carMancanti” è ora opaco all’esterno della classe, mentre i suoi elementi possono essere conosciuti solo uno ad uno tramite il metodo carattere_mancante().

Un’altra piccola miglioria che m’è venuta in mente in questi giorni riguarda l’allocazione del buffer temporaneo per la codifica dei dati. In precedenza, per quel buffer veniva allocata una quantità di memoria pari al numero dei caratteri del testo da codificare moltiplicato per 12 (un numero ottale entro i limiti imposti dal tipo unsigned long ha un massimo di 11 cifre, alle quali occorre aggiungere un ulteriore spazio per il delimitatore). Considerando che è alquanto improbabile che qualcuno voglia codificare un testo usando una chiave costituita da oltre 4 miliardi di caratteri, ora viene allocata memoria in quantità equivalente al numero dei caratteri del testo moltiplicato per la quantità di cifre occorrenti per contenere in forma ottale il valore che corrisponde alla lunghezza della chiave (più lo spazio per il delimitatore). Nella maggioranza dei casi ciò si traduce in un bel risparmio di memoria.

Totalmente inutile nel contesto del programma così com’è, ma potenzialmente essenziale qualora la classe venisse usata in altri contesti è l’aggiunta del costruttore di copia e dell’operatore di assegnamento. Ora gli oggetti della classe CDF possono essere impunemente usati in tutte quelle circostanze nelle quali il costruttore di copia è indispensabile per evitare gravi problemi correlati alla gestione della memoria dinamica.

Altri consigli?


Ma cosa vuoi che ne sappia? Io ci gioco, col codice, mica ci lavoro!
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1452
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 20:38
Sabato, 14/02/2015
Scusa se ti rispondo con una domanda, ma visto che arrivati a questo punto del progetto che è ben organizzato e strutturato ti chiedo..... E se io volessi usare il codificatore in un arduino? Non è un algoritmo enorme o che richiede quantità enormi di memoria se la stringa da cifrare è piccola, quindi potresti pensare alla possibilità che venga usato in sistemi embedded dalle potenzialità di calcolo ristrette.....

PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 345
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 21:40
Sabato, 14/02/2015
Mmm... stai parlando di cose che non sono certo di conoscere quanto dovrei.

Arduino... è un hardware minuscolo che viene spesso usato come controller, vero? Incuriosito da alcuni riferimenti che ho letto in questo forum sono andato a leggermi qualcosa, ma non sono mica certo d'aver capito bene...

Dato per scontato che sia così, cosa dovrei fare per andare nella direzione che mi suggerisci? Perché credo che quando negli anni '90 giocavo a programmare in System 7 con una macchina con un MB di ram e 25 MHz di clock già avevo a che fare con qualcosa che oggi sarebbe considerato ben più che un sistema "dalle potenzialità ristrette".

Secondariamente, sono andato a leggermi cosa significa "sistema embedded" e credo d'aver capito il concetto generale. Quel che non mi è chiaro è, in concreto, cosa mi stai proponendo da un punto di vista pratico. Se mi dai una mano, magari (magari...) imparo qualcosa di cui non ho la benché minima conoscenza. Guidami, che provo (provo...) a seguirti.


Ma cosa vuoi che ne sappia? Io ci gioco, col codice, mica ci lavoro!
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1452
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 22:30
Sabato, 14/02/2015
1MB di ram? 25MHz? L' atmega328p la CPU ad architettura harvard è una CPU che ha 2kb di memoria RAM e supporta al massimo un clock da 20MHz (arduino uno monta un clock di 16MHz). In pratica arduino è formato da questa CPU, un convertitore USB-seriale, un quarzo (il generatore di 16MHz di clock) e un pulsante di reset. Questa CPU può essere programmata semplicemente collegando il cavo usb al pc grazie al software (bootloader) pre-caricato sulla CPU. Da notare che parte della flash è stata quindi occupata dal bootloader.

PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 345
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 22:41
Sabato, 14/02/2015
Sì, sto leggendo dei tutoria proprio in questo momento e ho trovato le specifiche di diversi modelli di scheda arduino. La memoria disponibile è davvero risibile. Però continuo a non capire cosa mi stai suggerendo/proponendo (è un mio limite: vienimi incontro perché non ti seguo).


Ma cosa vuoi che ne sappia? Io ci gioco, col codice, mica ci lavoro!
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1452
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 23:01
Sabato, 14/02/2015
Testo quotato

Postato originariamente da AldoBaldo:
Sì, sto leggendo dei tutoria proprio in questo momento e ho trovato le specifiche di diversi modelli di scheda arduino. La memoria disponibile è davvero risibile. Però continuo a non capire cosa mi stai suggerendo/proponendo (è un mio limite: vienimi incontro perché non ti seguo).


Ti sto dicendo che gli algoritmi di cifrazione di solito vengono portati e pensati per lavorare dove lo spazio è ridottissimo e le risorse minime. Su Arduino non hai la gestione dei file senza schede aggiuntive, quindi ti proponevo di fare una classe cifrario per questi dispositivi sempre che sia possibile.... Questo per fare esercizio a pensare e lavorare con i soli algoritmi indipendenti dal dispositivo (per quanto sia possibile ovviamente). Perché ho notato che (secondo me) pensi troppo all'algoritmo associato a files. E i file in questo caso sono i 'fronzoli' ma a quando vedo hai incluso l'interazione con i file nella tua classe.

PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 345
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 23:19
Sabato, 14/02/2015
Sì, c'è sia l'output su file, sia l'accesso ai dati in formato stringa C.


Ma cosa vuoi che ne sappia? Io ci gioco, col codice, mica ci lavoro!
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1452
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 23:42
Sabato, 14/02/2015
Ma il tuo algoritmo non è indissolubilmente legato ai file, quindi non mi sembra una cosa molto logica gestire i file dalla classe dell'algoritmo. Per il resto controlla che gli avr c'è la faccia a compilare

PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 345
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 23:47
Sabato, 14/02/2015
Ho inserito quel metodo che salva direttamente su file solo per evitare di dover accedere ai dati tramite copia o rendendoli proprietà pubblica... Credevo mi permettesse di seguire al meglio un tuo consiglio.

Cosa sono gli "avr"?


Ma cosa vuoi che ne sappia? Io ci gioco, col codice, mica ci lavoro!
PM Quote
Pagine: [ 1 2 ] Precedente | Prossimo