Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
lamarozzo ha scritto:Sono d'accordo. I programmatori devono cercare di prevenire tutte le mosse sbagliate dell'utente. In più aggiungerei che chi scrive un compilatore deve cercare di prevenire al meglio tutte le possibili mosse sbagliate dei suoi utenti, cioè i programmatori. E' solo questione di punti di vista, ma penso che in fondo stiamo dicendo le stesse cose. :)
NO!
Il compilatore e` un arnese, puo` essere piu` o meno intelligente.
Il programma e` scritto dal cervello umano, e gli utenti sono umani creativi!
Il compilatore e` un arnese, puo` essere piu` o meno intelligente.
Il programma e` scritto dal cervello umano, e gli utenti sono umani creativi!
Mario Vanoni
Guarda che anche il compilatore è un programma (peraltro in larga parte scritto in C). Non vedo perchè il compilatore debba essere uno stupido arnese che si rifiuta di segnalare gli errori, mentre i programmi invece gli errori li devono segnalare tutti ed il prima possibile. Questa asimmetria nel tuo ragionamento proprio non la capisco.
Ma non voglio convincerti. Alla fine nè io nè te (credo) stiamo scrivendo un compilatore.
Il compilatore e` un arnese, puo` essere piu` o meno intelligente.
Il programma e` scritto dal cervello umano, e gli utenti sono umani creativi!
Mario Vanoni
Guarda che anche il compilatore è un programma (peraltro in larga parte scritto in C). Non vedo perchè il compilatore debba essere uno stupido arnese che si rifiuta di segnalare gli errori, mentre i programmi invece gli errori li devono segnalare tutti ed il prima possibile. Questa asimmetria nel tuo ragionamento proprio non la capisco.
Ma non voglio convincerti. Alla fine nè io nè te (credo) stiamo scrivendo un compilatore.
Infatti, ma scriviamo programmi usando arnesi (compilatori) forniti.
Ma con l'arnese in mano, devi dare il meglio di te stesso,
magari in piu` del previsto, con qualche extra.
L'arnese e` quello che hai in mano, non puoi cambiarlo,
quindi recriminare che l'arnese potrebbe essere migliore ...
Tocca a te riempire le mancanze dell'arnese, il resto e` bla-bla.
Tanto per rientrare un filo in argomento il controllo sul limite dell'array manca per lo stesso motivo per cui manca un garbage collector o altre amenità ritenute indispensabili su altri linguaggi: velocità. E nessuno infatti ha prodotto mai un linguaggio veloce (e difficile, entusiasmante, che ti mette alla prova..) come il C.
ildiama ha scritto:il controllo sul limite dell'array manca per lo stesso motivo per cui manca un garbage collector o altre amenità ritenute indispensabili su altri linguaggi: velocità.
Certo che se intendi la velocità di esecuzione del binario prodotto, il controllo da fare sull'esempio citato da lamarozzo è al "compile time", quindi non va ad inficiare la velocità.
static double R[8];
int main()
{
R[8]=2.;
return 0;
}
Aggiungo, IMVHO, premettendo che nel settore della programmazione ho una esperienza "limitata", che più il compilatore ti aiuta ad evidenziare problemi "ovvi" ma difficili da vedere, più il programmatore si può concentrare su errori di concetto, ottimizzando i tempi di sviluppo dell'applicazione. In poche parole concordo con albatros del quale cito una frase che riassume il concetto
albatros ha scritto:avere la possibilità che un programma stupido, ma dannatamente più veloce di un uomo, possa controllare anche errori stupidi fatti una persona intelligente non la ritengo una idea stupida
ildiama ha scritto:il controllo sul limite dell'array manca per lo stesso motivo per cui manca un garbage collector o altre amenità ritenute indispensabili su altri linguaggi: velocità.
Certo che se intendi la velocità di esecuzione del binario prodotto, il controllo da fare sull'esempio citato da lamarozzo è al "compile time", quindi non va ad inficiare la velocità.
E invece sì! Ecco il problema, La creazione del vettore in C corrisponde esattamente alla creazione del puntatore + allocazione TOT spazi in memoria. STOP. Nessun controllo o struttura di controllo su di esso (anche da portarsi dietro nell'eseguibile, che porterebbe ad esempio ad un segmentation fault o giù di lì).
Se poi vuoi sbarellare e andare oltre.. sei libero. Anche di sbagliare. Bello no?
ildiama ha scritto:il controllo sul limite dell'array manca per lo stesso motivo per cui manca un garbage collector o altre amenità ritenute indispensabili su altri linguaggi: velocità.
Certo che se intendi la velocità di esecuzione del binario prodotto, il controllo da fare sull'esempio citato da lamarozzo è al "compile time", quindi non va ad inficiare la velocità.
E invece sì! Ecco il problema, La creazione del vettore in C corrisponde esattamente alla creazione del puntatore + allocazione TOT spazi in memoria. STOP. Nessun controllo o struttura di controllo su di esso (anche da portarsi dietro nell'eseguibile, che porterebbe ad esempio ad un segmentation fault o giù di lì).
Se poi vuoi sbarellare e andare oltre.. sei libero. Anche di sbagliare. Bello no?
No, hai frainteso quello che dice People. Il controllo che fa il compilatore Intel è a compile time e non a run time, quindi non ha nessuna conseguenza sull'eseguibile. Semplicemente si deve accorgere che ho dichiarato un array di dimensione 8 e da qualche parte nel codice sto usando la nona posizione. Questo è possibile a compile time perchè sto usando espressioni note al tempo di compilazione, come R[8] e non R[variabile_che_può_valere_8].
Dopodichè deve solamente sollevare un warning. Non può sollevare un errore perchè non è previsto nello standard e, per una qualunque ragione potrei voler implementare proprio quel comportamento.
lamarozzo ha scritto:Semplicemente si deve accorgere che ho dichiarato un array di dimensione 8 e da qualche parte nel codice sto usando la nona posizione. Questo è possibile a compile time perchè sto usando espressioni note al tempo di compilazione, come R[8] e non R[variabile_che_può_valere_8].
Esattamente, intendevo proprio questo... scusate se non sono stato abbastanza chiaro.
Poi, quel vettore, così controllato a compile time deve risultare, a livello di binario nulla più di quello che dice ildiama:
ildiama ha scritto:creazione del puntatore + allocazione TOT spazi in memoria. STOP.
Ovviamente, se l'indice del vettore non è una costante, ma una variabile... questo controllo non si può fare...
IMHO, questo è il giusto compromesso... anche a me non piacerebbe avere un compilatore che aggiunge codice con controlli a run time... su questo non ci sono dubbi...
P.
a prescindere dal compilatore che si usa , questi che si potrebbero definire problemi sono proprio la caratteristice intrinsiche del c .Quando qualcuno dice che è un linguaggio potente intende anche che non pone limitazioni , Ma come diceva uno spot la potenza è nulla senza controllo
se si immagina il c++ pensato come evoluzione del c ,si nota che sono stati aggiunti molti controlli in piu .esempio, I costruttori altro non servono che per far si che le variabili create non abbiano valori indefiniti come invece si puo fare con il c senza una esplicita assegnazione.
Mario Vanoni ha scritto:
Una Ferrari, alta gamma, controlla/corregge il pilota?
esempio infelice:
le ferrari da formula 1 hanno una quantità di spie e "warning" che fanno sembrare il volante un albero di natale, per non parlare poi di tutte le "telemetrie". Inoltre non dimentichiamoci che l'elettronica è bandita dalle corse perché il computer spesso guida meglio del pilota.
detto questo mi sembra che stiamo andando fuori tema:
il problema era che icc alza un warning per segnalare un comportamento che nel 99% dei casi è una svista del programmatore che normalmente ringrazia e va a giocare a tennis il resto del pomeriggio. Io ringrazio l'intel e non mi sento defraudato neanchè un attimo della mia creatività. Nell'uno per cento dei casi in cui il comportamento è voluto (in realtà non mi viene in mente quando potrebbe esserlo) ignoro il warning e basta.
puzuma ha scritto:
il problema era che icc alza un warning per segnalare un comportamento che nel 99% dei casi è una svista del programmatore che normalmente ringrazia e va a giocare a tennis il resto del pomeriggio. Io ringrazio l'intel e non mi sento defraudato neanchè un attimo della mia creatività. Nell'uno per cento dei casi in cui il comportamento è voluto (in realtà non mi viene in mente quando potrebbe esserlo) ignoro il warning e basta.
Forse neanche io mi sono spiegato tanto bene.. io prima cercavo di spiegare perché gcc non alza quello warning.
Però sta cosa di tennis e ferrari proprio non la capisco.
1) se uno programma per piacere, forse troverà piacere anche a debuggare errori non voluti che ti fanno "divertire", non "perdere" un pomeriggio. Si impara e ci si diverte. Se uno si diverte col tennis, vada pure.
2) se uno programma in C per lavoro, sa che questi controlli sono a suo carico e che se non li fa rischia. Io direi.. il lavoro
Mario Vanoni ha scritto:
Una Ferrari, alta gamma, controlla/corregge il pilota?
esempio infelice:
le ferrari da formula 1 hanno una quantità di spie e "warning" che fanno sembrare il volante un albero di natale, per non parlare poi di tutte le "telemetrie". Inoltre non dimentichiamoci che l'elettronica è bandita dalle corse perché il computer spesso guida meglio del pilota.
detto questo mi sembra che stiamo andando fuori tema:
il problema era che icc alza un warning per segnalare un comportamento che nel 99% dei casi è una svista del programmatore che normalmente ringrazia e va a giocare a tennis il resto del pomeriggio. Io ringrazio l'intel e non mi sento defraudato neanchè un attimo della mia creatività. Nell'uno per cento dei casi in cui il comportamento è voluto (in realtà non mi viene in mente quando potrebbe esserlo) ignoro il warning e basta.
Intendevo una macchina potente, con guidatore junior/poco esperto,
sulle strade di Cuasso al Monte (Va), riuscira` ad arrivare in Valganna?
Mario Vanoni ha scritto:
Una Ferrari, alta gamma, controlla/corregge il pilota?
esempio infelice:
le ferrari da formula 1 hanno una quantità di spie e "warning" che fanno sembrare il volante un albero di natale, per non parlare poi di tutte le "telemetrie". Inoltre non dimentichiamoci che l'elettronica è bandita dalle corse perché il computer spesso guida meglio del pilota.
detto questo mi sembra che stiamo andando fuori tema:
il problema era che icc alza un warning per segnalare un comportamento che nel 99% dei casi è una svista del programmatore che normalmente ringrazia e va a giocare a tennis il resto del pomeriggio. Io ringrazio l'intel e non mi sento defraudato neanchè un attimo della mia creatività. Nell'uno per cento dei casi in cui il comportamento è voluto (in realtà non mi viene in mente quando potrebbe esserlo) ignoro il warning e basta.
Intendevo una macchina potente, con guidatore junior/poco esperto,
sulle strade di Cuasso al Monte (Va), riuscira` ad arrivare in Valganna?
ildiama ha scritto:
1) se uno programma per piacere, forse troverà piacere anche a debuggare errori non voluti che ti fanno "divertire", non "perdere" un pomeriggio. Si impara e ci si diverte. Se uno si diverte col tennis, vada pure.
personalmente non trovo divertente ne un gran chè creativo debuggare il fatto che in una riga su 100.000 ho scritto 8 invece che 7, però questo è soggettivo.
ildiama ha scritto:
2) se uno programma in C per lavoro, sa che questi controlli sono a suo carico e che se non li fa rischia. Io direi.. il lavoro
ok, allora io non so programmare, che controllo dovrei mettere se in un'indice per sbaglio ho scritto un numero invece che un altro? sono daccordo controllare l'input dell'utente o di un programmatore che usa una mia funzione ma controllare anche l'input dello stesso programmatore che scrive il codice mi sembra difficile
il controllo sul limite dell'array manca per lo stesso motivo per cui manca un garbage collector o altre amenità ritenute indispensabili su altri linguaggi: velocità. E nessuno infatti ha prodotto mai un linguaggio veloce (e difficile, entusiasmante, che ti mette alla prova..) come il C.
