Newsgroup: it.comp.lang.c++
Titolo: For.

Salve a tutti.
Quando si costruisce un costrutto for per un array, la condizione di
continuazione deve essere per forza i < n??
Perchè ho provato a scrivere i != ! ( cioè fermati quendo trovi il carattere
"!") ma il compilatore mi dà errore proprio lì.
Dove sbaglio?
Ah! Scusate, qualcuno mi può far vedere un esempio di programma che legge
una stringa di numeri e restituisce a video solo quelli pari?
Vi anticipo che non ho studiato le classi e sono proprio all'inizio, quindi
se decidete di scrivermi quest'algoritmo, per favore che sia semplice.
Grazie mille
Ciao a tutti

 Dove sbaglio?
Fammi capire, tu scrivi:
char myArray[100];
int i;
for (i=0; i != !; ++i) {
........
}
forse volevi scrivere:
for (i=0; myArray[i] != '!'; ++i) {
........
}
In ogni caso devi stare attento a non sforare il limiti dell'array,
ti consiglio:
for (i=0; myArray[i] != '!' && i<100  ; ++i) {
........
}
Ciao
Gaetano
--
#exclude <windows>
#include <CSRSS>
printf("\t\t\b\b\b\b\b\b");.
printf("\t\t\b\b\b\b\b\b");

 for (i=0; myArray[i] != '!' && i<100  ; ++i) {
Idea giusta, ma se i arriva a valere 100 l'uso di myArray[i]
potrebbe dare errore; basta un piccolo cambiamento:
for (i=0; (i<100) && (myArray[i] != '!') ; ++i) {
la && e` valutata da sinistra verso destra con "corto circuito",
quindi la parte destra dell'&&, che implica l'accesso all'array,
viene evitata se i>=100.
Alex

 for (i=0; (i<100) && (myArray[i] != '!') ; ++i) {
giusto.
Sto iniziando a rilassarmi nello scrivere il codice
visto che poi tutto quello scrivo ha un test case??
Potrebbe essere un difetto di XP!! O un pregio ?


 Potrebbe essere un difetto di XP!! O un pregio ?
Pregio, se i tuoi test case sono veramente fatti cosi` bene
(e il compilatore/runtime collaborano) da giustificare il relax.
Per intenderci, garantire ad esempio che l'off-by-one, che
e` possibile, MORDA, se succede.  Il C++ standard di per
se non garantisce il disastro, lo lascia solo possibile; molti
specifici compilatori/librerie/runtime aiutano, in debug-mode,
a garantire che a qualsiasi errato comportamento provochi
una diagnostica.  Beh, "garantire" e` difficile, ma e` una
questione di probabilita`.
Alex

 (e il compilatore/runtime collaborano) da giustificare il relax.
Speriamo bene.


Io scrivevo:
for (int i=0;i!=!;i++)
e mi dà errore
ma ho visto che tu fai ++i e non i++ come me.
Forse è questo l'errore?


 Forse è questo l'errore?
Sicuramente no.
Non sto a spiegarti la differenza fra pre e post incremento,
visto che sei all'inizio. Mi limito a dirti che
ALL' INTERNO DI UN FOR
e' leggermente meglio ++i di i++, ma l'effetto dei due e' lo stesso.
Se invece vuoi i dettagli sulla differenza chiedi.
--
Gerolamo

 Forse e` questo l'errore?
No, quello che scrivi tu e` assolutamente sbagliato.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
ATTENZIONE: il mio indirizzo email e` cambiato, quello vecchio verra` 
disabilitato a breve.
Se non puoi convincerli, confondili.

 Kronos
, confondili.

e' leggermente meglio ++i di i++, 
Perche' ???
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

Potrebbe essere un difetto di XP!! O un pregio ?
Hmmm... io stavo per proporre che in ditta da noi si
iniziassero a utilizzare le suite di test come parte
del processo di build, ma non avevo considerato che
questo potesse portare qualcuno a "rilassarsi".
Se il rilassamento e' qualcosa di frequente allora
personalmente credo questo sia un difetto di XP
(se con XP intendevi l'ultima buzzword e non l'ultimo
buzz-OS).
I bug sono convinto che in linguaggi come il C/C++
sia molto piu' facile cercare di non metterceli del
tutto che metterceli per poi trovarli e toglierli...
questo perche' in C/C++ esiste il concetto di
"undefined behaviour" che spesso, malauguratamente,
si traduce in "nulla di visibile in tutte le prove
e in tutti i test case e danno tremendo quando si
lavora sul serio".
Il VC++ ad esmepio cerca di aiutare lo sviluppatore
grazie ai controlli aggiuntivi e alle precauzioni
prese nelle compilazioni di debug (ad esempio con
l'inizializzazione con pattern assurdi di tutte le
aree di memoria sia in allocazione che in
deallocazione) ma questo non credo che dovrebbe
autorizzare nessuno a "rilassarsi".
Detto in altri termini non sono convito che un team
che usi test case e che sia composto da programmatori
"rilassati" possa scrivere codice migliore di un team
di programmatori "non rilassati".
Andrea

e mi dà errore

 Perche' ???
Perche' in un operatore di post incremento la valutazione dell'
espressione richiede un temporaneo in piu'.
Questo accorgimento a senso quando tali operatori sono applicati agli
oggetti.
--
Ivan Molella
__LINUX__ the choice of the  __GNU__ generation

oggetti.
Quello che voglio precisare e' che nel caso specifico, le
due espressioni sono del tutto equivalenti.


 due espressioni sono del tutto equivalenti.
certo certo... infatti avevo scritto che, all'interno di un for,
" l'effetto dei due e' lo stesso"
--
Gerolamo

 Forse non posso usare il ciclo for per uno condizione di stop anticipato?
come vedi puoi...
--
Ciao by Allanon

 Scusa, ma precisamente mi puoi dire dove e` sbagliato?
No e` sbagliata la sintassi, oltra alla logica.
for (int i=0; i != !; i++)
Il carattere ! va scritto come '!', il ciclo diventerebbe:
for (int i = 0; i != '!'; i++)
Ora,  i e`  un  iteratore che  va  da 0  a 33  (codifica  ASCII di  '!')
*sempre*. Visto che,  presumibilmente, i  e` l'indice dell'array  il tuo
ciclo dovra` essere scritto cosi`:
for (int i = 0; mio_array[i] != '!'; i++)
Visto che poi manca un controllo sulla lunghezza:
for (int i = 0; i < dimensione_array && mio_array[i] != '!'; i++)
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
ATTENZIONE: il mio indirizzo email e` cambiato, quello vecchio verra` 
disabilitato a breve.
La vasca da bagno fu inventata nel 1850, il telefono nel 1875.
Se fossi vissuto nel 1850, avrei potuto restare in vasca per 25 anni
senza sentir squillare il telefono

OK.
Finalmente ho capito.
Grazie mille



Caro Beppe Grillo, se evitassi di rendercelo noto con un
messaggio esplicito sul gruppo, faresti a tutti un grande
piacere.
Grazie.


 wrote:
NON cambiare il subject se rispondi ad un messaggio e se non c'č un
valido motivo (ad esempio perché č cambiato l'argomento del thread).
ALcuni newsreader in questo caso spezzano il thread.
-- 
Marco Barisione (ICQ 84277092)

 questo potesse portare qualcuno a "rilassarsi".
... snipped long rant
Quello che dici non è del tutto sbagliato. Ma neppure del tutto
corretto. Il rischio del "rilassamento" esiste. Ma questo non significa
che il codice scritto dai programmatori rilassati sia per forza molto
peggio di quello scritto dai programmatori "attenti". Probabile che
quello che guadagni dal "rilasamento" lo possa sfruttare per maggiore
produttività o per una visione più completa del progetto ad un livello
di astrazione diverso.
Ti faccio un parallelo: quando scrivi il sorgente, quanto sei rilassato
rispetto a chi scriveva i sorgenti ai tempi in cui compilare un
programma di qualche centinaio di righe richiedeva parecchi minuti
macchina su un sistema che costava 10 mila lire al minuto?
Ovviamente sei MOLTO più rilassato. Errori banali, punti-e-virgola
mancanti e tante altre cosette oggi sono all'ordine del giorno. Molto ma
molto spesso si scrive il codice in maniera estremamente rilassata e poi
si lancia il compilatore e si vede che errori ci sono.
Fai un esperimento. Prendi un progetto non troppo impegnativo. Per
esempio un problema risolvibile da due programmatori in 2 giorni di
lavoro. Dai a quei programmatori tutto il tempo che vogliono (vabbè,
diciamo non più di due settimane) e un premio in denaro: 5 milioni a
testa. Però falli lavorare su un editor banale (per esempio notepad)
senza che abbiano accesso a color-highlight vari, a indentatori
automatici o altre amenità simili. E ovviamente senza accesso ad un
compilatore. Devono risolvere il problema (non difficile ma neppure
banale dato che è un problema che oggi valuteresti in 4 giorni uomo) da
zero e facendo il minor uso possibile del compilatore e senza usare un
debugger (ok invece eventuali file di log all'interno del programma). Di
loro che quando sono pronti a compilare dovranno fornirti i sorgenti e
il makefile belle che pronti. Tu procederai alla compilazione e gli
restituirai l'output della sessione di compilazione e link salvato su
file testo e (se c'è) l'eseguibile. Questo giochetto costerà loro un
milione (detrarrai quindi 500 mila a ciascuno dal famoso premio di 5
milioni). Questo significa che di fatto il premio è di 9 milioni in
tutto dato che almeno una compilazione dovranno farla per forza. Ma
dubito che spenderai più di un paio di milioni a testa. Ammesso che
arrivino in fondo senza doverti loro dei soldi (nota: se sono furbi non
ci provano neppure a cavarsela con una sola compilazione ma faranno fin
da subito una versione del codice "instrumentato" con varie assert e
#ifdef _DEBUG con i vari "clog << ...", quindi passeranno dalla
compilazione almeno due volte).
Se arrivano in fondo prova a paragonare il codice che hanno prodotto con
quello che producono normalmente e vedrai quanti bachi nascosti in meno
ci sono (o meglio, dato che in un progetto come questo è possibile che
arrivino a non avere nessun baco, quanto più curato sarà il codice e il
relativo commento). Se poi gli dici che non rivedranno il codice per 8
mesi e poi glielo restituirai per una "feature upgrade" con difficoltà
(e tempi) previsti il doppio dello sviluppo iniziale e "premio" triplo,
vedrai quanto più curati saranno commenti, astrazioni, modularità etc.
etc.
Eppure ti renderai conto che questo esercizio è abbastanza sterile. O
meglio: non significa che la rilassatezza conseguente all'uso degli
strumenti di sviluppo moderni sia per forza un danno.
Semmai bisogna trovare un modo per avere tutti i vantaggi e il minimo
possibile dei danni. Quindi rilassarsi sui ; ma non sull'analisi e
l'accuratezza del lavoro. Come fare? In parte obbligando a fare il
lavoro nel modo giusto (per esempio scambiando apposta i sorgenti e i
problemi da risolvere una volta ogni mese in modo che chiarezza del
codice e completezza della documentazione diventino "paramount"). In
parte "allenandosi". Per esempio organizzando una volta all'anno un
progettino da sviluppare proprio in una situazione controllata come
quella suddetta (senza debugger, con molto piò tempo e con un grosso
premio ... subordinato al minimo uso del compilatore). O altri metodi
simili.
--
Andrea Ferro
IHHC - Member of HT-Group  DVD Authoring operator  Fan of I.Asimov
C++ Master: 
http://www.brainbench.com/transcript.jsp?pid=2522556
This post expresses personal opinions which may or may not be the
opinions of the company(s) I work for. I speak for myself only.