Newsgroup: it.comp.lang.c
Titolo: Blocco dell'if ignorato

Salve, ho iniziato ad imparare il C da qualche giorno ed ho deciso di
esercitarmi sulla gestione dei file. Per farlo ho deciso di scrivere
un piccolo script che simuli una rubrica.
Nello script che ho scritto pero', c'è un errore di semantica che non
riesco a risolvere. Source:
http://sprunge.us/iIaB?c
Il blocco dell'if alla riga 41 non viene eseguito quando dovrebbe :-/
Probabilmente sara' un errore banale, non sono ancora pratico con il
C :P

 C :P
Il fatto � che non stai confrontando le stringhe ma degli indirizzi di
memoria. Per il confronto tra stringhe devi usare strcmp() o strncmp().
Il problema � dovuto al fatto che, in C, il nome di un array decade al
puntatore al primo elemento. Questo significa che il nome dell'array tmp
decade in puntatore al primo elemento (&tmp[0]) e viene confrontato con
"S", che � il puntatore all'area di memoria dove � presente la stringa. I
due indirizzi sono ovviamente diversi, quindi l'if fallisce.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 questo articolo e` stato inviato via web dal servizio gratuitohttp://
www.newsland.it/newssegnala
 gli abusi ad 
ab...@newsland.it
Ok, capito. Grazie mille per il chiarimento.

.....
Sti stramaledetti puntatori!!!  Farci l'abitudine è stato difficile (forse perchè vengo dal Pascal? Delphi amore mio :)) e ancora mi capitano questi errori stupidi che mi fanno perdere un sacco di tempo :((
-- 
"Quando colui che ascolta non capisce colui che parla, e colui che parla non sa cosa stia dicendo: questa e' filosofia" (Voltaire)


wrote:

Lol vero, io vengo dal Python, abituarmi è un po' difficile :D

 Ma se sono la parte divertente del C °_°
Forse quando ci fai l'abitudine ti viene automatico, ma io all'inizio ho perso un sacco di tempo a cercare questo tipo di errori perchè il compilatore ti dice che è andato tutto bene e il programma, invece, non funziona come dovrebbe. :))
-- 
Mi avvicino strisciando e trovo un segno della sua presenza: uno dei suoi scarponi! Il piede e' ancora dentro, lui non dev'essere lontano!  (Ratman)

il compilatore ti dice che è andato tutto bene e il programma, invece, non
funziona come dovrebbe. :))
Be', sarebbe un bella presunzione da parte del compilatore dirti anche se
a run-time andr� tutto a dovere. Un compilatore come gcc, al massimo
livello di warning, pu� garantirti gi� a compile-time che non ci sono
condizioni troppo critiche nel codice, per� di certo non pu� mettersi l� a
testare la semantica per te :) Purtroppo l'uso sbagliato dei puntatori �
molto frequente (di per s� sono un argomento molto semplice da apprendere,
se si studia) ed � per questo che sarebbe ora di dimenticarne l'uso
esplicito per usarli implicitamente. In tutti i linguaggi meno che il C �
cos�, C++ compreso (vedi i reference).


 così, C++ compreso (vedi i reference).
Forse la "potenza" del C sta anche nell'uso esplicito dei puntatori. In fondo sei "quasi" a contatto diretto con la macchina (forse al livello più basso per quanto riguarda i linguaggi ad "Alto livello". Sembra un gioco di parole :)), quindi se sai quello che fai OK altrimenti usa un altro linguaggio.
-- 
Il lavoro mi piace, mi affascina. Potrei starmene seduto per ore a guardarlo. (Jerome K. Jerome)

 invece, non funziona come dovrebbe.
Appena dai una definizione decente di "funzionare come si deve" (ovvero
formalizzi la semantica del programma in qualche modo) scopri che e'
indecidibile il fatto che il dato programma sia o meno conforme a quella
semantica. 
Ovvero il compilatore quello non puo' farlo e non potra' *mai* farlo (se
non per programmi banali). 
Una buona suite di test non ti da certezze, ma almeno ti acchiappa gli
errori piu' evidenti.
-- 
-riko

 non per programmi banali). 
In realt� il programma *funziona* come dovrebbe, cio� come � stato 
specificato tramite il codice sorgente. Dunque � perfettamente normale 
che il compilatore non si lamenti. In questo caso � il programmatore che 
si � espresso in maniera sbagliata, tramite il linguaggio.
E.

 Forse la "potenza" del C sta anche nell'uso esplicito dei puntatori.
Non lo credo. La "potenza", oggi, si misura su altri fattori. Essere
"vicini alla macchina" non � pi� cos� importante per la stragrande
maggioranza delle applicazioni (tanto � vero che sono molti i sistemi che
si basano su codice virtuale, vedi Java, .NET, Python, ecc..). Esistono
linguaggi pi� espressivi del C e che ti consentono di fare cose molto
complesse col minimo sforzo. In C persino gestire una stringa (che
formalmente non esiste come tipo) � inutilmente complicato. I puntatori
possono creare molti probelmi e sarebbe finalmente il caso di abbandonarli
o usarli solo in casi di emergenza estrema (quindi praticamente mai).


 errori piu' evidenti.
Quoto. Io la ritengo indispensabile. Ogni programmatore scrive, volente o
nolente, una buona parte di codice "al buio", nel senso che si fida del
suo funzionamento (la fiducia dell'uomo in s� stesso � sterminata...),
senza alcun test approfondito sul momento. Si preferisce testare l'intera
applicazione e se una parte del codice finisce per funzionare per puro
caso, allora evviva! il programma funziona!
Con il tempo e l'esperienza ho imparato che bisogna prestare attenzione
alla singola riga di codice; fare attenzione ad evitare errori nel momento
stesso in cui si scrive l'applicazione � molto meno banale di quel che
sembra ed � una questione cruciale. Il recupero dei bug � un'attivit�
altamente dispendiosa: 1 grammo di disattenzione mentre si scrive il
codice genera 1 tonnellata di costi in produzione.


 specificato tramite il codice sorgente.
Ma la semantica implementata non � quella cheil programmatore vuole
implementare, quindi non funziona "come dovrebbe". I test che Enrico
suggerisce servono apposta a verificare questa rispondenza.


 sembra ed � una questione cruciale. 
Gia'. Credo che non sia un caso che il TDD (in versione hard o soft)
ormai sia entrato come pratica standard anche in contesti non agile.
D'altra parte che i test andassero fatti lo si diceva pure ai tempi di
Brooks. Solo adesso e' entrato nella cultura popolare il fatto che i
test scritti in sostanza parallelamente al codice fanno risparmiare
tempo.
In effetti io devo dire che per me i test hanno anche un aspetto
puramente psicologico positivo. Se vedo del codice che puzza, che non mi
finisce di piacere, io tendo a correggerlo e metterlo a posto. Con una
buona suite di test, sono ragionevolmente sicuro di poter controllare
che il mio fix sia un fix e non un bug. Senza... beh, if ain't broken
don't fix it. Che porta a codice complessivamnte meno mantenibile,
perche' tante piccole migliorie vengono tralasciate per paura.
Ah, la paura. 
-- 
-riko


int main()
{
    func1();
    func2();
 
adesso_fai_quello_che_ho_scritto_pero_non_proprio_uguale_uguale_ma_piu_come_io_vorrei
();
    return 0;
}

 non per programmi banali).
Ovviamente non mi stavo lamentando del fatto che il compilatore non mi 
segnali un
errore che non � sintattico ma logico (anche se sarebbe molto utile un 
compilatore
in grado di capire al volo ci� che intendevi anche se sbagli a dirlo :))
Volevo solo dire che questo tipo di errori � molto "subdolo" e pu� farti 
perdere molto
tempo se non fai molta attenzione, specialmente se, come me, non sei un 
professionista ma
un semplice hobbista autodidatta senza un background scolastico.
Ciao. 

 senso :-)
ma valgrind non serve per rilevare errori di gestione della memoria, come 
quando dimentichi di liberare la memoria utilizzata?
-- 
Non rispettare la vecchiaia e' come demolire la casa dove si deve 
riposare la sera. (Alphonse Karr)

 C :P
Se tu avessi compilato con il massimo (o quasi) livello di warning il 
compilatore ti avrebbe messo la pulce nell'orecchio. Se usi gcc prova a 
compilare il programma originario con -Wall, vedrai che il compilatore 
protesta!
Se vuoi un consiglio, usa _sempre_ -Wall, e pretendi che i tuoi 
programmi compilino senza warning con tale switch, vedrai che eviterai 
tanti errori banali.
Giovanni