Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine porta Logan in un'avventura inedita, violenta e fortemente narrativa, costruita attorno alla sua natura di combattente e al difficile rapporto con il proprio passato. Insomniac Games punta su combattimenti spettacolari, progressione e personalizzazione, inserendo l'azione in un mondo segnato dalla persecuzione dei mutanti. Un viaggio intenso, che alterna mattanza, esplorazione e momenti sorprendentemente emotivi.
DJI Romo 2: tante novità lo rendono un robot completo
DJI Romo 2: tante novità lo rendono un robot completo
Romo 2 è la seconda generazione di robot lavapavimenti di DJI, un modello che si caratterizza per la precisione nel sistema di navigazione e per il funzionamento particolarmente silenzioso. Con le modifiche introdotte in questa seconda versione, e un posizionamento di prezzo più allineato alla concorrenza, rappresenta una valida alternativa sul mercato delle soluzioni di pulizia domestica
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED
Il primo Sony con retroilluminazione True RGB alla prova del banco di misura e dei contenuti: luminanza enorme, colori accurati in HDR e un antiriflesso molto efficace. I limiti sono due sole HDMI 2.1 e il blooming fuori asse
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 23-01-2007, 09:36   #1
d@vid
Senior Member
 
L'Avatar di d@vid
 
Iscritto dal: Jan 2005
Città: Napoli
Messaggi: 2424
LA LOGICA DEL BRAVO PROGRAMMATORE

Salve. Vorrei un vostro parere su quale potrebbe essere la logica di un bravo programmatore di fronte ad un certo ventaglio di possibilità.


Mi spiego (l'ambiente specifico cui si riferisce il mio quesito è quello del MatLab, ma ovviamente esporrò il problema in modo generale, perchè a me preme capire la 'logica' del comportamento, che non è necessariamente vincolata ad uno specifico ambiente di lavoro, anzi): c'è un programma principale (main) che chiama vari sottoprogrammi (nella fattispecie 3 o 4 mi sembra ). Uno di questi sottoprogrammi produce un oggetto grafico, i cui attributi devono essere diversi a seconda del punto, all'interno del main, in cui vien fatta la chiamata
Per procedere ho individuato due possibilità:
1) il sottoprogramma restituisce, oltre all'output di interesse, anche un puntatore all'oggetto grafico, i cui attributi saranno modificati all'interno del main
2) il main fornisce al sottoprogramma chiamato, oltra ai vari parametri di input di interesse, un ulteriore parametro sulla base del quale, mediante un costrutto switch-case, ilsottoprogramma stesso stabilirà gli attributi dell'oggetto grafico restituito all'atto della chiamata

Le due soluzioni sono sostanzialmente equivalenti dal punto di vista dell'effetto finale, ma diverse nell'esecuzione nonchè nella 'pulizia' del codice (e, non ultimo, nella 'coerenza logica')

Nel primo caso avremo una nuova variabile che il sottoprogramma restituisce al main, il quale, per ogni chiamata, dovrà presentare delle righe di codice aggiuntive per modificare gli attributi di questa variabile:
Vantaggi
-modo semplice e immediato di risolvere la questione
Svantaggi
-'ridondanza' (il main si caricherà di nuove righe di codice, che andranno eseguite dopo ogni chiamata al sottoprogramma)
-'minore velocità di esecuzione' (legata all'aspetto precedente)
-'incoerenza del sottoprogramma' (esso esaurirà solo in parte la sua funzione, dal momento che richiederà sempre, nel programma chiamante, delle righe di codice che, a tal punto, diventano essenzaili per la rappresentazione dell'oggetto grafico - in assenza di tali righe, il sottoprogramma NON fornisce l'oggetto grafico [ma solo un puntatore ad esso])

Nel secondo caso avremo una nuova variabile che il main dovrà passare, all'atto di ciascuna chiamata, al sottoprogramma, il quale, tramite un costrutto switch-case, fisserà poi gli attributi dell'oggetto grafico che fornirà in output:
Vantaggi
-'coerenza' (il sottoprogramma esaurisce la sua funzione nel fornire i parametri di output richiesti, compreso un oggetto grafico finito. Per dire, laddove fosse necessario chiamare lo stesso sottoprogramma da altri programmi, questo avrebbe una sua ragion d'essere indipendente, legata al fatto che le sue mansioni sono ben delineate)
Svantaggi
-a meno di non sovraccaricare il costrurro switch-case, esso risulterà comunque limitato per esaurire tutte le possibili scelte che dovessero presentarsi circa la modifica degli attributi grafici, nonchè queste risulterebbero "prestabilite" nel sottoprogramma
-è necessario passare un'ulteriore variabile al sottoprogramma, all'atto di ogni chiamata

Attendo vostri pareri: voi come fareste e perchè?
__________________
~ ~ ho concluso con: capzero, DarkSiDE, Iron10, 12379, Hyxshare, Gort84, kristian0, scrafti, as2k3, gegeg, Kyrandia, Feroz, asta, nyko683, mstella, 00700, WotanBN, [COLOR=]Warez[/color], sesshoumaru, ...
nel we potrei non essere davanti al pc

Ultima modifica di d@vid : 23-01-2007 alle 09:55.
d@vid è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 11:57   #2
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
a mio avviso dipende dalla relazione che intercorre tra il main e il sottoprogramma. Se il sottoprogramma deve essere una scatola nera, vista dall'esterno, in modo tale da produrre un prodotto finito che non richieda ulteriori modificazioni allora e' meglio che il main sappia meno cose possibili e che la produzione sia demandata totalmente al sottoprogramma. sara' compito del main fornire informazioni sul suo stato e sara' compito del sottoprogramma analizzare tale stato e produrre di conseguenza l'oggetto in questione.
Spezzare, di fatto, la produzione dell'oggetto grafico tra sottoprogramma e main e' quantomeno scomoda per il mantenimento e la pulizia del codice.
A livello prestazionale, che il case tu lo faccia nel main o nel sottoprogramma e' praticamente la stessa cosa, dato che ai fini della produzione dell'oggetto grafico, il case verra' comunque eseguito.
Per i motivi esposti e per aderire ai principi della programmazione a oggetti ritengo che la soluzione logicamente migliore sia di passare al sottoprogramma tutte le info necessarie alla produzione dell'oggetto grafico.
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 12:15   #3
d@vid
Senior Member
 
L'Avatar di d@vid
 
Iscritto dal: Jan 2005
Città: Napoli
Messaggi: 2424
Quote:
Originariamente inviato da mad_hhatter
a mio avviso dipende dalla relazione che intercorre tra il main e il sottoprogramma. Se il sottoprogramma deve essere una scatola nera, vista dall'esterno, in modo tale da produrre un prodotto finito che non richieda ulteriori modificazioni allora e' meglio che il main sappia meno cose possibili e che la produzione sia demandata totalmente al sottoprogramma. sara' compito del main fornire informazioni sul suo stato e sara' compito del sottoprogramma analizzare tale stato e produrre di conseguenza l'oggetto in questione.
Spezzare, di fatto, la produzione dell'oggetto grafico tra sottoprogramma e main e' quantomeno scomoda per il mantenimento e la pulizia del codice.
A livello prestazionale, che il case tu lo faccia nel main o nel sottoprogramma e' praticamente la stessa cosa, dato che ai fini della produzione dell'oggetto grafico, il case verra' comunque eseguito.
Per i motivi esposti e per aderire ai principi della programmazione a oggetti ritengo che la soluzione logicamente migliore sia di passare al sottoprogramma tutte le info necessarie alla produzione dell'oggetto grafico.
grazie del parere, sei stato chiarissimo
in realtà anch'io pensavo preferibile una soluzione di tal tipo

Un dubbio: se ho ben capito, tu affermi che a livello puramente prestazionale le due soluzioni sono equiparabili, ovvero che l'esecuzione del case nel sottoprogramma (mettiamo che sia un case "ridotto all'osso", giusto per soddisfare i bisogni del main su cui sto lavorando ora) è identica, come velocità di esecuzione, all'esecuzione delle varie operazioni di modifica fatte direttamente nel main dopo ogni chiamata (eliminando il case dal sottoprogramma, ovviamente). Ho inteso correttamente? A me l'ultimo punto sembrerebbe più oneroso a livello prestazionale
__________________
~ ~ ho concluso con: capzero, DarkSiDE, Iron10, 12379, Hyxshare, Gort84, kristian0, scrafti, as2k3, gegeg, Kyrandia, Feroz, asta, nyko683, mstella, 00700, WotanBN, [COLOR=]Warez[/color], sesshoumaru, ...
nel we potrei non essere davanti al pc
d@vid è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 14:05   #4
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da d@vid
grazie del parere, sei stato chiarissimo
in realtà anch'io pensavo preferibile una soluzione di tal tipo

Un dubbio: se ho ben capito, tu affermi che a livello puramente prestazionale le due soluzioni sono equiparabili, ovvero che l'esecuzione del case nel sottoprogramma (mettiamo che sia un case "ridotto all'osso", giusto per soddisfare i bisogni del main su cui sto lavorando ora) è identica, come velocità di esecuzione, all'esecuzione delle varie operazioni di modifica fatte direttamente nel main dopo ogni chiamata (eliminando il case dal sottoprogramma, ovviamente). Ho inteso correttamente? A me l'ultimo punto sembrerebbe più oneroso a livello prestazionale
di preciso dipende da cosa cambia facendo il case nel main o nel sottoprogramma... se i casi presi in considerazione sono gli stessi e se le operazioni da eseguire in ciascun caso sono le stesse (nel main e nel sottoprogramma) allora non vedo differenze.

Voglio dire (e spero di aver capito bene il problema)

main{
statements...
call sottoprogramma;
case result_sottoprogramma of:
caso1: elaborazione1;
...
casoN: elaboraioneN;
}

fa le stesse cose rispetto a:

main{
statements...
call sottoprogramma (+ parametro di stato)
}
sottoprogramma{
prima_elaborazione;
case stato of
caso1: elaborazione1;
...
casoN: elaborazioneN:
}
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 14:07   #5
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
inoltre, nel primo caso il main puo' anche non sapere un piffero di cosa fa sottopragramma, nel secondo caso, i due moduli sono indissolubilmente correlati... questo in un ottica di modularita' e modifica del codice

e sempre secondo il mio parere, ovviamente (che non e' quello, ancora, di un coder professionista)
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 14:50   #6
d@vid
Senior Member
 
L'Avatar di d@vid
 
Iscritto dal: Jan 2005
Città: Napoli
Messaggi: 2424
Quote:
Originariamente inviato da mad_hhatter
di preciso dipende da cosa cambia facendo il case nel main o nel sottoprogramma... se i casi presi in considerazione sono gli stessi e se le operazioni da eseguire in ciascun caso sono le stesse (nel main e nel sottoprogramma) allora non vedo differenze.

Voglio dire (e spero di aver capito bene il problema)

main{
statements...
call sottoprogramma;
case result_sottoprogramma of:
caso1: elaborazione1;
...
casoN: elaboraioneN;
}

fa le stesse cose rispetto a:

main{
statements...
call sottoprogramma (+ parametro di stato)
}
sottoprogramma{
prima_elaborazione;
case stato of
caso1: elaborazione1;
...
casoN: elaborazioneN:
}
non mi sono spiegato bene
nel main il case non ci dovrebbe essere, poichè il main può modificare direttamente i parametri restituiti dal sottoprogramma, e la modifica da apportare (cha varia in base al punto del main da cui vien fatta la chiamata) è diretta (ossia non occorre case per farla)

Seguendo il tuo schema dovrebbe essere:

main{
statements...
call sottoprogramma;
result_sottoprogramma: elaborazione1
statements...
call sottoprogramma;
result_sottoprogramma: elaborazione2
statements
call sottoprogramma;
result_sottoprogramma: elaborazione3
statements...
}



oppure, per contro:

main{
statements...
call sottoprogramma (+ parametro di stato: s1)
statements...
call sottoprogramma (+ parametro di stato: s2)
statements...
call sottoprogramma (+ parametro di stato: s3)
statements...
}
sottoprogramma{
prima_elaborazione;
switch s
case1: elaborazione1;
case2: elaborazione2;
case3: elaborazione3:
}
__________________
~ ~ ho concluso con: capzero, DarkSiDE, Iron10, 12379, Hyxshare, Gort84, kristian0, scrafti, as2k3, gegeg, Kyrandia, Feroz, asta, nyko683, mstella, 00700, WotanBN, [COLOR=]Warez[/color], sesshoumaru, ...
nel we potrei non essere davanti al pc
d@vid è offline   Rispondi citando il messaggio o parte di esso
Old 23-01-2007, 21:05   #7
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
ah, ok ora ho capito...
beh, tutto dipende da quanto stringente e' il tuo vincolo prestazionale... e a pensarci bene, anche i parametri di stato del main messi all'interno del sottoprogramma possono essere o non essere una buona soluzione: dipende dalla loro semantica all'interno del programma... se riguardano soltanto il main e non l'oggetto grafico come entita' concettuale allora e' meglio che il sottoprogramma non ne sappia niente... a questo punto e' molto meglio andare nello specifico del tuo problema e non stare nel caso generale.
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa Marvel's Wolverine, la recensione: Logan torna p...
DJI Romo 2: tante novità lo rendono un robot completo DJI Romo 2: tante novità lo rendono un ro...
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED Sony Bravia 9 II: il True RGB alla prova, dove l...
Geely EX5, un mese al volante: il SUV elettrico cinese che ci ha sorpreso (quasi) senza riserve Geely EX5, un mese al volante: il SUV elettrico ...
Mova Z70 Ultra Roller Complete: motore potente, rullo di lavaggio e l'IA a guidare Mova Z70 Ultra Roller Complete: motore potente, ...
Dopo 23 anni di silenzio, Warcraft 3 spi...
Roblox sfida l'ecosistema gaming: app st...
OpenAI accusata di plagio dai migliori m...
Altro attacco hacker dell'IA: gli agenti...
Stiamo davvero perdendo il controllo del...
Microsoft perde un pilastro: Frank Shaw ...
Diablo V annunciato a sorpresa: il colpo...
Meno di 5 euro per il 5G: l'offerta Kena...
World of Warcraft: Forever è il Classic+...
La Serie A con DAZN e Amazon Prime con l...
Giochi Ubisoft su Steam senza Ubisoft Co...
Miami Beach ha autorizzato la maxi opera...
Apple regala un altro anno di funzioni s...
Alla fine è successo davvero: Vol...
Il meglio di Amazon del weekend in uno s...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 03:15.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v