Modo discussione | Modo lineare

TheCrib · 17-10-2010 1:35

(17-10-2010 0:36)Eclipse ha scritto: Gli errori vanno gestiti internamente all'applicazione, le exception dovrebbero essere usate al massimo solo durante la fase di sviluppo come aiuto al debugging e poi rimosse..

Concordo ma solo in parte..
Non so cosa intendi di preciso con "rimosse".. magari usando il preprocessore per switcharle, oppure disabilitare il supporto dal compilatore, ma non so poi cosa succede. Spero non a mano fisicamente dal codice 8)
Io ad esempio cross-compilando C++ tra PC e mobile, uso il preprocessore per rimpiazzare le eccezioni con una specie di assert() su Android (visto che mi dicono che non sono comunque supportate..).

Su PC pero' tornano utili.. perche' e' la piattaforma dove l'eseguibile diventa parzialmente anche un tool e quindi e' importante che non crashi ogni volta che propino dei dati sballati.

Quindi, considerando che la fase di sviluppo e' quella che deve essere maggiormente agevolata, allora io userei le exceptions come conviene senza preoccuparsi della performance (che non e' detto peggiori piu' di tanto a priori).
L'importante e' usare le exceptions per la gestione degli errori e non come parte integrante di un algoritmo. Almeno se uno vuole riservarsi l'opzione di poter funzionare senza exceptions.

Va anche aggiunto che il runtime finale non e' necessariamente limitato ad assets predefiniti. Giochi che permettono di customizzare assets, tramite modding, editors interni, files di config generosi, etc. non possono essere sicuri dei dati che andranno a manipolare.
Stessa cosa per networking, che aggiunge tante incognite a run-time..

Quindi per applicazioni piu' avanzate, dove serve una gestione dinamica degli errori, le exceptions tornano utili.. anzi, in C++ diventano indispensabili, perche' i costruttori non hanno un return value 8)

Concordo pero' sul fatto che se si puo' evitare il controllo dinamico degli errori, allora tanto meglio.

mumble mumble

**Eclipse** · 17-10-2010 9:11

sì sono concorde, sono da evitare come parte di algoritmi, o come risposta ad un caricamento di un file non andato bene.
Personalmente le uso tramite macro che diventano vuote se compilate in release, qualcosa del tipo

Codice:

#ifdef _DEBUG

   #define TRY try

   #define CATCH catch... ecc ecc

   #define THROW_EXCEPTION(....

#elseif

   #define TRY 

   #define CATCH 

   ...

#endif

lato compilatore su visual studio basta togliere il parametro /EHsc (quello attivo di default) o /EHa dal progetto.

Riguardo Mod e assets esterni se il caricamento delle risorse è robusto può cavarsela generando errori tramite la gestione errori dell'engine invece di crashare e tirare una exception. Diciamo che in teoria il codice con risultati incogniti è sempre abbastanza individuabile...

Linguaggi come Java o Python (ma specialmente Java) portano l'utente ad usare le exception anche in casi dove in C++ basterebbe una funzione con un return value di errore.
Anche se ho detto che evito di usarle proprio ieri ne ho fatto abbondante uso per scovare un bug non facilmente riproducibile Linguaccia

blgames · 17-10-2010 20:21

In Java ci sono metodi con la clausola "throws" che ti obbligano a gestire l'eccezione perché il compilatore viene avvisato che quel metodo può generare un eccezione, per esempio quando leggi o scrivi un file.

encelo · 17-10-2010 21:27

(17-10-2010 20:21)blgames ha scritto: In Java ci sono metodi con la clausola "throws" che ti obbligano a gestire l'eccezione perché il compilatore viene avvisato che quel metodo può generare un eccezione, per esempio quando leggi o scrivi un file.

Qualcosa di simile, ma senza i controlli statici che vengono fatti in Java, esiste anche in C++.

fzambetta · 17-10-2010 22:41

(17-10-2010 9:11)Eclipse ha scritto: sì sono concorde, sono da evitare come parte di algoritmi

Come diceva TheCrib, e come avevo detto pochi post fa, le performance non crollano se si usa un compilatore recente e si scrive del codice sensato.
Nessuno con un minimo di esperienza penserebbe di rendere la gestione delle eccezioni parte integrante di un algoritmo.
Che poi certa gente lo faccia credo sia indicazione del loro "stile" di programmazione (sempre tornando agli studenti alle prime armi potrei raccontare cose turche ma faro' finta di niente) Asd

Tornado poi al fatto che i linguaggi varii "impongano" un'eccezione, ecc.
Considerate che questi linguaggi (e.g., Java, Python, C#, ecc. ecc.) generano codice intermedio (assembler della macchina virtuale), poi convertito in codice della macchina host dal jitter, che puo' essere ottimizzato davvero bene per gestire eccezioni, costrutti dinamici e cosi' via.
Non e' sempre cosi' ma in teoria la cosa si puo' fare benissimo, basta leggere paper nemmeno tanto recenti (fine anni '90) dove gia' si parlava di prototipi in grado di fare cose simili in maniera efficente, percio' figuriamoci se non si puo' fare 10-15 anni dopo.

TheCrib · 17-10-2010 22:42

(17-10-2010 9:11)Eclipse ha scritto: Personalmente le uso tramite macro che diventano vuote se compilate in release, qualcosa del tipo

Cosi' e' ideale perche' puoi sempre sostituire la throw con un bel message box ed una exit().. o magari scrivere in un bel logfile, in modo da avere un minimo di info per quando il software gira su macchine esterne.

(17-10-2010 22:41)fzambetta ha scritto: Non e' sempre cosi' ma in teoria la cosa si puo' fare benissimo, basta leggere paper nemmeno tanto recenti (fine anni '90) dove gia' si parlava di prototipi in grado di fare cose simili in maniera efficente, percio' figuriamoci se non si puo' fare 10-15 anni dopo.

Sono sicuro che l'ottimizzabile viene gia' ottimizzato 8)
Un problema nel caso almeno del C++ e' che abilitare le eccezioni crea un effetto a catena e richiedere lavoro addizionale (per lo stack unwinding) per ogni funzione, anche quelle che non hanno direttamente costrutti per la gestione delle eccezioni.

Quanto questo pesi pero' ovviamente e' da vedere.. in pratica se uno chiama gia' una funzione cosi' tante volte che l'overhead di entrare ed uscire dalla funzione ha un peso rilevante, allora probabilmente quella funzione andrebbe quanto meno resa inline.

Comunque l'ultima parola va sempre data al profiler sulla piattaforma specifica.

mumble mumble

fzambetta · 18-10-2010 0:15

(17-10-2010 22:42)TheCrib ha scritto: Un problema nel caso almeno del C++ e' che abilitare le eccezioni crea un effetto a catena e richiedere lavoro addizionale (per lo stack unwinding) per ogni funzione, anche quelle che non hanno direttamente costrutti per la gestione delle eccezioni.

Quanto questo pesi pero' ovviamente e' da vedere.. in pratica se uno chiama gia' una funzione cosi' tante volte che l'overhead di entrare ed uscire dalla funzione ha un peso rilevante, allora probabilmente quella funzione andrebbe quanto meno resa inline.

Comunque l'ultima parola va sempre data al profiler sulla piattaforma specifica.

mumble mumble

Lo stack unwinding e' un problema generale, non solo per quanto concerne le eccezioni chiaramente.
C# fa stack unwinding (come del resto la maggior parte dei linguaggi derivati dal C e tanti altri ancora) ma ci sono delle differenze con C++ (se non erro c'era qualcosa relativo a come le risorse vengano distrutte ma al momento la cosa mi sfugge).
Concordo che senza fare un po' di sano profiling la risposta non la sapremo mai: se ho qualche minuto oggi provo a mettere su qualche riga in croce ed analizzare col profiler di Unity Asd

Reitero che se usate con accortezza (e perche' no, assieme a defensive code come diceva Eclipse) possono toglierci le castagne dal fuoco in molte circostanze.

TheCrib · 18-10-2010 2:22

(18-10-2010 0:15)fzambetta ha scritto: Lo stack unwinding e' un problema generale, non solo per quanto concerne le eccezioni chiaramente.
C# fa stack unwinding (come del resto la maggior parte dei linguaggi derivati dal C e tanti altri ancora) ma ci sono delle differenze con C++ (se non erro c'era qualcosa relativo a come le risorse vengano distrutte ma al momento la cosa mi sfugge).

ummm.. volevo dire che lo stack unwinding non serve in C++ se le exceptions sono disabilitate.
Visto che ci sono, tanto per chiarire per chiunque stesse ancora leggendo (^^;), per "stack unwinding" intendo la capacita' in un qualsiasi momento non solo di tornare indietro di diverse chiamate, ma anche di chiamare automaticamente tutti i distruttori degli oggetti allocati sullo stack ("variabili" auto) fino a quel momento.
Quindi potenzialmente un bel po di overhead in qualsiasi funzione (o metodo), perche' ogni funzione deve tenere conto degli oggetti attivi e non semplicemente jumpare indietro e dimenticarsi dei contenuti sullo stack... come invece e' libero di fare il C++ senza le eccezioni.

mumble mumble

fzambetta · 18-10-2010 3:25

(18-10-2010 2:22)TheCrib ha scritto: ummm.. volevo dire che lo stack unwinding non serve in C++ se le exceptions sono disabilitate.
Visto che ci sono, tanto per chiarire per chiunque stesse ancora leggendo (^^;),

Ok, adesso ho colto interamente il senso Smile

Tuttavia penso che siano stramazzati gia' tutti al suolo colla bava alla bocca 4-5 post fa Asd

Xaldyz · 18-10-2010 9:41

(18-10-2010 3:25)fzambetta ha scritto: bava alla bocca 4-5 post fa

mi intrippano ste conversazioni Asd

anche se mi sento in dovere di quotare quel che ha detto encelo tempo fa Ahsisi

lele85 · 18-10-2010 9:47

(18-10-2010 3:25)fzambetta ha scritto: Tuttavia penso che siano stramazzati gia' tutti al suolo colla bava alla bocca 4-5 post fa

Io sto ancora seguendo con interesse... ma preferisco non intervenire per la mia conoscenza superficiale dei linguaggi c like (utilizzati solo in maniera "scolastica" all'università). Asd

TheCrib · 18-10-2010 10:28

(18-10-2010 9:41)Xaldyz ha scritto:
(18-10-2010 3:25)fzambetta ha scritto: bava alla bocca 4-5 post fa

mi intrippano ste conversazioni

anche se mi sento in dovere di quotare quel che ha detto encelo tempo fa

..effettivamente... brrooom brooomm !!

**Eclipse** · 18-10-2010 11:06

(18-10-2010 2:22)TheCrib ha scritto: ummm.. volevo dire che lo stack unwinding non serve in C++ se le exceptions sono disabilitate.
mumble mumble

Si anche io per "problemi di performance\memoria" intendevo quello. Basta anche solo abilitarle da compilatore (senza usarle!) per avere dell'overhead nelle chiamate a funzione, ovviamente la performance dell'exception stessa non è importante, visto che non si usa come parte di algoritmi o simili. In c++ il fatto è che conviene proprio disabilitarle almeno in release. Ora non ho neanche misure di quanto possa incidere, e dipende strettamente da quanto il codice sia complicato e "nested", però basta essere a conoscenza della cosa.

Tornando IT a pySFML Asd

SFML è una ottima libreria (almeno la versione C++) Python è un linguaggio carino e molto comodo da usare, per iniziare senza badare a problemi di performance "hardcore" è ottimo Smile

Come pratiche di coding generale, consiglio a tutti, con qualsiasi linguaggio, l'approccio defensive programming (stando a tenti a non infarcire troppo il codice di controlli inutili ovviamente) Sisi

blgames · 18-10-2010 20:35

Perdonatemi la domanda conoscete libri / siti che spiegano come fa a funzionare un PC? Cioè quando programmo ed il codice viene compilato e poi va in esecuzione che succede? Perdonatemi l'ignoranza ma queste cose penso le spieghino ad informatica.

P.S.
se qualcuno sa la risposta e se la sente di rispondere faccia pure.
P.P.S.
spero che chi ha aperto la discussione trovi la forza di perdonarmi per tutti gli OT Inchino

Corralx · 18-10-2010 21:23

(18-10-2010 20:35)blgames ha scritto: Perdonatemi la domanda conoscete libri / siti che spiegano come fa a funzionare un PC? Cioè quando programmo ed il codice viene compilato e poi va in esecuzione che succede? Perdonatemi l'ignoranza ma queste cose penso le spieghino ad informatica.

P.S.
se qualcuno sa la risposta e se la sente di rispondere faccia pure.
P.P.S.
spero che chi ha aperto la discussione trovi la forza di perdonarmi per tutti gli OT

Qualsiasi libro che riguardi linguaggi di programmazione (non linguaggi che trattano uno specifico linguaggio, ma che ne trattano le caratteristiche generali, sintassi, semantica, macchina astratte) e sui compilatori (interpreti, compilatori, macchine virtuali, parsing tree, traduzione del codice, ottimizzazione).
Puoi cercare i libri di riferimento dei corsi universitari che trattano tale argomento.

Questo per quanto riguarda i linguaggi e la loro traduzione.

Per quanto riguarda il codice macchina e la sua realizzazione fisica sulla CPU ti serve un libro di architettura dei calcolatori, e qui mi permetto addirittura di consigliare un libro specifico, del mio autore preferito.
"Architettura dei calcolatori" di Andrew Tanenbaum.

Modo discussione \| Modo lineare Prime prove con pySFML
Autore	Messaggio