[C] Programma va in crash

[oregon]

Per farla breve, con C++ dovresti definire l'array una sola volta in modo globale, .

No, non è consigliabile un array globale. Meglio preparare gli array nel main e passarli come argomenti a tutte le funzioni.

[CaMpIoN]

Perché non è consigliabile?

[oregon]

Perché non è consigliabile?

http://forum.html.it/forum/showthread/t-887694.html

[M.A.W. 1968]

L'uso di variabili globali è deprecato ingegneristicamente, in tutti i linguaggi nei quali esistono delle alternative (controesempio: quasi nessun assembler supporta variabili "locali" o con scope segregato) e in particolare nei linguaggi procedurali. Nei linguaggi OOPL puri l'uso di globals è idealmente inibito a livello sintattico, a meno di non ricorrere ad implementazioni di aspects o altre esotiche peculiarità, mentre la natura ambigua di C++ è confermata ulteriormente dal fatto che eredita tali variabili sic et simpliciter dal C.

Questo perché, principalmente, l'uso di variabili globali viola il principio di information hiding di Parnas (vedi anche qui, oppure qui) e la sua specializzazione già citata dal nostro ottimo oregon nel thread sopra referenziato, ovvero il principio dell'accoppiamento debole.
Inoltre si creano dei potenziali pitfall nel momento in cui non vi sono meccanismi di controllo su quale routine o funzione possa alterare il valore di tali variabili e in quale momento, creando problemi di sincronizzazione e potenziali conflitti.

Naturalmente, lontano dal solito mainstream, prevalgono le situazioni nelle quali non vi è alternativa all'uso di globals, anche perché tale approccio rimane prestazionalmente vincente in una maggioranza di casi rispetto al classico uso dello stack frame per il passaggio di parametri.

A proposito del thread già citato, alcune affermazioni lì riportate non sono corrette: ad esempio, le variabili globali possono essere inizializzate o meno, e fin dagli albori dall'informatica applicata (anzi, a maggior ragione quando lo spazio sui dischi era un asset preziosissimo!) i compilatori fanno in modo da separare le une dalle altre, impiegando esattamente zero bytes per ogni variabile non inizializzata e minimizzando così l'occupazione di spazio dell'immagine dell'eseguibile sul supporto di massa. Per contro, è ovvio che anche le costanti (in particolare quelle usate a runtime per inizializzare dinamicamente variabili automatiche) occupano spazio nell'immagine dell'eseguibile, sicché l'intera argomentazione in merito risulta speciosa e poco consistente, dipendendo in modo molto stringente da fattori puramente statistici e soprattutto sostanzialmente indipendenti dal tipo di visibilità assegnato ad una variabile.

Le reali ragioni per cui nei manuali di stile e di engineering l'uso di variabili globali è deprecato, in un contesto mainstream, sono quelle riportate poco sopra: violazione del criterio di Parnas e sue specializzazioni, e diminuzione del controllo sugli accessi alla variabile, quindi scarsa affidabilità dei "contratti" relativi.

[CaMpIoN]

Quindi modernamente si tratterebbe solo di un fatto di logica?
Se è così, secondo me dipende dal programmatore, perché se uno progetta bene, prima dello sviluppo vero e proprio, il suo programma, non credo che questi siano dei problemi.
Però vedo che è un argomento più ampio di quanto sembri e non credo che uno che sta imparando a programmare debba preoccuparsi già di questo problema.

[M.A.W. 1968]

Esistono delle regole di engineering e dei manuali di stile molto rigorosi. In taluni mercati (es. embedded critico) tali norme sono obbligatorie, e sono fortemente consigliabili ovunque vi sia cooperazione di più sviluppatori.
Dunque, tanto prima si impara ad applicare questi concetti, tanto meglio è per il programmatore. Non esiste una fase di apprendimento separata e secondaria in cui si impara a "programmare bene", lo si deve fare da subito.

[CaMpIoN]

Significa che io non ho speranza di programmare bene, dato che ho iniziato senza conoscere questa cosa?

[M.A.W. 1968]

La schiacciante maggioranza dei programmatori, anche con titoli di studio post-lauream, ignora l'applicazione delle fondamentali regole di engineering. Per questo le aziende più solide investono annualmente cifre ingenti nei loro centri di formazione interni, per insegnare ai neoassunti come calare le idee asseverate del software engineering nella prassi della programmazione.
Puoi apprenderlo anche tu: anche se il costo per la correzione di una errata forma mentis già instaurata è rilevante, si tratta comunque di un compito tranquillamente affrontabile, una volta acquisita consapevolezza del problema.

Al di là dei testi sacri generalisti sull'engineering del software (Pressman, Sommerville, Mandrioli-Ghezzi...), esistono testi applicativi legati ai singoli linguaggi. Ad esempio, in questa bibliografia sono citati i più validi testi inerenti l'applicazione dei criteri di engineering avanzato al linguaggio C.

[CaMpIoN]

Conosci il SICP? http://en.wikipedia.org/wiki/Structu...puter_Programs
Una volta me lo hanno consigliato dicendo che parla di programmazione in generale, chissà se parla anche di questi argomenti.

[M.A.W. 1968]

Il SICP è un testo di nicchia, strutturato come lo Sprankle & Hubbard ma basato addirittura su Scheme, un dialetto LISP.
Ti può essere utile ai fini dell'engineering, ad un dipresso, tanto quanto ad un pesce oceanico può far comodo uno svitacandelette.

I testi più idonei per il linguaggio C, convalidati in anni di prassi didattica, sono solamente quelli consigliati nella bibliografia già citata.