Newsgroup: it.comp.lang.c++
Titolo: pre e post incremento

Salve,
vorrei un chiarimento:
int main () {
        while (++i < 10) {  // Quì l'output sarà da 1 a 9 perchè prima c'è il 
l'incremento e poi il confronto 
                std::cout << i << std::endl;
        };
        i = 0;
        std::cout << std::endl;
        while (i++ < 10) {  //Quì l'output sarà da 1 a 10 perchè prima c'è il 
confronto e poi l'incremento .
                std::cout << i << std::endl;
        };
}
Giusto?
Inoltre quando scrivo
int x = 3, y = 1;
int main () {
        x = y++; // Assegna senza incrementare
        std::cout << x << std::endl; // Stampa 1
        x = 3;
        y = 1;
        x = ++y; // Incrementa e assegna
        std::cout << x << std::endl; // Stampa 2
        return 0;
}
Giusto?
Grazie
-- 
Luigi
--
bug windows [5] = {"95", "98", "NT", "Me", "2000"};

Giusto?
Si', ma questi argomenti sono relativi alla programmazione
in C, ancor prima che in C++, per cui per questo genere di
cose ti conviene chiedere su it.comp.lang.c.
--
CyberWalkie - walkietalkie(at)
libero.it

 cose ti conviene chiedere su it.comp.lang.c.
Non sono assolutamente concorde !
Molte persone studiano il C++ senza prima studiare il C.
C++ e C sono due linguaggi distinti. Potrei anche dire che la stessa domanda
la si poteva fare su it.comp.lang.perl visto che anche in perl questi
operatori funzionano nello stesso modo.
La verita' e' che se lui sta studiando il C++ senza passare dal C non vedo
perche' mai dover passare dal NG di C. Il tuo consiglio e' solo motivo di
confusione visto che ci sono alcune differenze tra C e C++, anche nella
parte del C++ simile al C, e quindi postare su it.comp.lang.c vorrebbe solo
dire rischiare di ottenere una risposta sbagliata.
Come fa uno che non ha studiato il C a sapere quali cose sono uguali tra C e
C++ e quali diverse ? Quali domande possono essere indistintamente postate
su ....c e ...c++ ?!?
Mah......
Alex

Non sono assolutamente concorde !
Anche io non concordo con AndreaCyberLaForgiaTalkie... vedi thread da
me iniziato 'Strano problema di incremento'. Perchè mai devo chiedere
su un altro gruppo... E poi ci si lamenta dei programmatori C++
provenienti dal C e li ancora troppo 'radicati'...
Luc.

 cose ti conviene chiedere su it.comp.lang.c.
Non e` mica detto che per imparare il C++ si debba prima
passare dal C, anzi io consiglio di evitare proprio il C
se poi si vuole passare al C++. Ci sono troppe differenze
tra l'approccio alla C e quello all C++.
Paolo
--
Paolo Marotta
Home: 
http://web.tiscalinet.it/paolo_marotta
Master's Level in C++ Certified by Brainbench
http://www.brainbench.com/transcript.jsp?pid=2440649

Alex ha scritto:
Va be, so che si usano anche in C, ma io sto studiando C++ senza passare da 
C.


 tra l'approccio alla C e quello all C++.
Che è proprio il mio caso :)


C.
Ok, ma siccome sono elementi che rimangono invariati, ti
conviene chiedere su quel gruppo.
--
CyberWalkie - walkietalkie(at)
libero.it

tra l'approccio alla C e quello all C++.
Retorico.
Io non ho affatto detto questo.
--
CyberWalkie - walkietalkie(at)
libero.it

 chiedere in un gruppo legato al C.
non sono d'accordo.
pre e post incremento esistono in C++?
si.
allora perchè uno deve sottoscrivere anche iclc per chidere una sola cosa? (e
dover scaricare kb e kb di msg inutili... che tanto qui ci si incazza per quei
pochi kb di msg OT).
sono d'accordo che è OT un messaggio che parla di printf(), fopen() o altra
roba del C.
ma il fatto che il C++ deriva dal C non giustifica che un messaggio che parla
di qualcosa che esiste sia in C che in C++ (per esempio gli operatori di
incremento) sia OT o sia meglio postare di la'...
...IMHO...
ciao
xaero

dal C e li ancora troppo 'radicati'...
Hmmm... contami quanti programmatori C++ provengono da Ada.
[VEDI ALTRO MSG]
--
CyberWalkie - walkietalkie(at)
libero.it

incremento) sia OT o sia meglio postare di la'...
Hai la strana tendenza, congiuntamente ad altre persone, a
fraintendere cio' che gli altri dicano.
Dovreste fondare un club.
Il "club dei fraintenditori" non sarebbe male, potreste per
esempio restituire il resto alla 100.000 annuale dei vostri
soci con il resto di una 50.000.
Sicuramente a qualcuno sfuggirebbe il particolare, ma
potreste sempre giustificarvi con un "ah, scusa, pensavo mi
avessi dato 50.000".
"Sei OT" e' una cosa, "e' meglio postare li'" e' un'altra
cosa.  
La prima e' un riconoscimento di qualcosa di "illegale", la
seconda e' un *consiglio*.
Io non ho detto al nostro amico "DEVI chiedere su
it.comp.lang.c e non ti azzardare a farlo mai + qui dentro,
altrimenti ti spappoliamo la testa con una mazza da baseball
e con la tua pelle ci rivestiamo il divano posto
nell'ingresso di iclc++".
Queste cose le dico (e le faccio), generalmente, a chi e'
OT.
Ho solo *suggerito* (sottolineando la *convenienza* nei
confronti del nostro amico) di compiere un'azione del
genere.
Poi, ricordati una cosa, l'OT si puo' intendere non soltanto
nei riguardi dell'anello + grande, rispetto all'anello +
piccolo, ma anche viceversa.
Vuoi un esempio ? te lo produco punto : discutere su
it.comp.programmre.win32 di C e C++ e' OT.
OOOOOOOHHHH MERAVIGLIA ! : leggi il manifesto che traccia le
linee del topic.
Questo accade nonostante C e C++ siano i due linguaggi con
cui si sviluppano il maggior numero di applicazioni per
Windows.
Estas claro ?
Ti dico un'altra cosa che riguarda tutti noi dal punto di
vista umano : i thread che trattano un argomento,
generalmente, si allungano e leggere piu' messaggi che
riguardano la *base* del C++, spudoratamente ereditata dal
C, non e' cio' che chi frequenta questo gruppo si aspetta
(ti diranno il contrario, ma nel loro cuoricino sanno bene
che non e' cosi').
Se si discute di C++, si danno per scontati tanti argomenti
basilari, che si trattano meglio in it.comp.lang.c e vorrei
vedere quante di queste persone sopporterebbero bene dei
thread su questi argomenti, ripeto, *di base*, in codesto
gruppo.
Poi, e' facile e fin troppo retorico affermare : qui va bene
anche qualsiasi cosa riguardi il C, perche' C++ avalla il
99,99% della semantica del C.
Questo lo sappiamo tutti, come sappiamo tutti che per
imparare il C++ non e' necessario imparare prima il C, ma il
problema vero e' che io non ho detto questo.
Chiudo qui, sperando di essere stato abbastanza chiaro, il
mio intervento.
--
CyberWalkie - walkietalkie(at)
libero.it

 mio intervento.
????
Alex

 conviene chiedere su quel gruppo.
Ti ripeto la domanda:
Una persona che ha iniziato il C++ senza prima aver imparato il C come fa a
sapere che "sono rimasti invariati! ?!?
Semplicemente non lo puo' sapere ! Quindi dove postera' mai la domanda ?!?
Prova ad indovinare ....
Alex

int i=0;
A me la segnalazione sembra giusta. L'inizializzazione di i non
compare nel listato e quindi é giusto segnalare che la variabile
potrebbe non essere impostata a 0.
Sono quelle piccole cose tipiche del c++ che sembrano banalità e che
se tralasciate possono compromettere il funzionamento dell'intero
programma.
Hai idea di quante persone sbattono regolarmente la testa in dettagli
apparentemente futili come il puntoevirgola in fondo alla
dichiarazione di una classe?
Il Ghenio
-----
ZIO : Fun and games are over with. Anyone who dares
get in my way shall perish.
DIO ci salvi dagli ocx del Viral Basic.
-----

> l'output non e' definito.
Beh, no.... MI chiedo come faccia ad essere sicuro che non sia inizializzato
quando non puo' vedere la dichiarazione !!! Sara' sensitivo ?!?
Alex

 Che è proprio il mio caso :)
Neanche io sono passato dal C (pascal, lisp, clips, qualche righa di prolog e 
qualche linguaggio di uso esclusivamente accademico).


 chiedere in un gruppo legato al C.
Non sono neanche specifici del C, proprio perche` esistono anche in C++
(e non solo).
Considerato qundi che la cosa puo` rientrare in entrambi i NG, non
vedo perche` forzare la discussione sull'altro,


 basilari, che si trattano meglio in it.comp.lang.c e vorrei
Ripeto che si puo` imparare il C++ senza conoscere (e volere
conoscere)
una sola virgola di C... Non vedo quindi perche` dovrei sottoscrivere
iclc per avere una risposta che mi puo` essere data da iclc++
rimanendo pienamente nel topic.


e` considerata obsoleta in C++".
Dove sta scritto che printf e' obsoleta ? Ma obsoleta nel
senso Java (che cioe' dal prossimo standard potrebbe non
essere piu' supportata) ? Io ne dubito fortemente.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 invece di vedere subito la preview perche' ...
[cut]
Innanzi tutto perdonami se, nella mia grande inesperienza, posso
dire stupidate.
Anzi, se ne dicessi ti sarei molto grato se me lo facessi notare.
Se non e' una voluta esagerazione mi pare strano. Io, utilizzando i
normali stream IO, ho sempre ottenuto prestazioni piu' che adeguate;
sul mio PII400 la lettura di un file binario di 50 MB non porta via
piu' di 2-3 secondi. Sei secondi per 700K mi parrebbero esagerati
pure su PC antidiluviani.
Ciao.

Sei secondi per 700K mi parrebbero esagerati pure su PC antidiluviani.
Mi e' rimasto impresso questo tempo di sei secondi per 700K
ma non ricordo i dettagli (forse si riferivano addirittura alla
versione di debug). Il mio PC di allora in ufficio era un credo
un PII/400... ricordo solo che cambiato da iostream a stdio le
cose sono migliorate notevolmente.


 essere piu' supportata) ? Io ne dubito fortemente.
Non in quel senso... (avrei detto "deprecated").


   stdio = 75 (n = 10000)
Pero' ... tra 7.000% e 60% c'e' un bella differenza !!! ;-)
Cavolo, interessante...
Provero' anche io, appena ho tempo, per cercare di capire come mai VC++
abbia "stdio" appena piu' lento degli altri due.
Alex

    Hmmm... forse il termine piu' adatto e' "ignobili".
Non è per caso che tu facevi:
while (infile.get(ch)) {
   [calcolo percentuale]
   cout << "Sei al " << xx << "%% della copia..."
   outfile.put(ch);
}
Ho cercato di usarli e avevo 6-7 sec per un file di 700kb. Usando solo while
(infile.get(ch)) outfile.get(ch); faccio con 4-5 sec faccio 500 MB (forse di
più)

    "questo non si puo' fare" e "no problem").
magari, dato che dovevi leggere il file, se usavi operator>> le cose 
andavano meglio :-)))
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 >   stdio = 280 (n = 10000)
Allora... A me VC++ in modalita' "Debug" ha tempi simili a quelli da te
indicati come BCC55. Mentre VC++ in modalita' "Release" ha tempi simili a
quelli da te indicati come VC++. Sapevo che tra le due "modalita'" ci fosse
differenza, ma non credevo cosi' tanta !!!
Ad ogni modo la differenza tra stdio e fstream da me non e' del 60% ma del
50% (anche se non cambia molto in realta').
Alex

>
fstream = 180 (n = 1)
stdio = 370 (n = 25011)
fstream = 171 (n = 1)
stdio = 380 (n = 25011)
Aggiungendo l'estrazione dei dati chiaramente i tempi per il ciclo
sugli stream sale, ma non credo possa andare oltre (o molto oltre)
quello di fscanf.
Non ho idea di come fare in C una unica chiamata per leggere tutto il
file
in un sol colpo... sarebbe interessante vedere i risultati.
Il punto e` cmq che ogni strumento ha caratteristiche proprie e se non
si e` pienamente consci di cio` fare paragoni e` molto difficile.
Ad ogni modo i tempi possono essere abbattuti al punto che le
differenza di prestazioni diventano irrilevanti all'atto pratico.
Tutti i test sono stati condotti su un file contenente la
riga da te postata, ripetuta 25011 volte (760Kb circa).


50% (anche se non cambia molto in realta').
Anche il BCB ha una modalità Full Debug(nessuna ottimizzazione)ed una
modalità Release(tutte le ottimizzazione per la velocità attivate),
quindi se proprio volete fare una prova completa dovreste utilizzarla.
Purtroppo adesso non ho tempo di fare prove ( comunque ho spesso fatto
confronti fra le funzioni del C e quelle del C++ sotto BCB e non ho
mai rilevato grosse differenze), ma stasera forse riuscirò ad inviare
un test eseguito su ben 4 compilatori differenti.


 un test eseguito su ben 4 compilatori differenti.
Aspetto con ansia ;-)
No, scherzi a parte, ero al corrente della 2 modalità del BCB ma non
avendolo attualmente installato sul PC non ho potuto fare prove. Mi sono
fidato invece delle prove di Andrea Griffini che avendo utilizzato la
modalità release per il MS credo la abbia utilizzata anche perl il Borland.
Alex

>  is >> x >> y >> z
se vuoi in un altro modo, ma pur sempre con lo stesso risultato...
(ah, lavorare poi sulla stringa e' un modo per aggirare il problema e che
tra le altre cose non e' nemmeno tanto veloce).
Alex
P.S. se ho tempo ci provero pure io ...

modalità release per il MS credo la abbia utilizzata anche perl il Borland.
Ti sbagli. Con prestazioni simili probabilmente non varrebbe neanche
la pena di scrivere il programma con il C++ ,anche il Visual Basigh
riuscirebbe a fare di meglio.
Inoltre un simile collo di bottiglia non passerebbe di certo
inosservato visto che capita molto spesso di dover leggere dei file
anche parecchio grossi.
E' evidente che nel BCC55 versione freeware(che io peraltro non ho mai
usato)avranno disabilitato qualche opzione che permette di avere le
ottimizzazioni migliori, altrimenti non si spiegherebbe il perché di
una tale differenza nelle misurazioni.
Eccoti comunque le prove che tanto aspettavi.
Il codice é lo stesso usato da A.G. , preso con il copia-incolla e
provato su un P2 400MHz(il mio), con un file di 700Kb contenente 23117
righe con la stringa "1234.5678 1234.5678 1234.5678".
BCB 3 Release Mode
--------
fstream= 1073 (n=23117)
stdio= 767 (n=23117)
fstream= 1078 (n=23117)
stdio= 665 (n=23117)
Visual C++ 6 Release Mode(Maximize Speed)
--------
fstream= 1260 (n=23117)
stdio= 770 (n=23117)
fstream= 1320 (n=23117)
stdio= 710 (n=23117)
MinGw 2.95.2(Best Optimization)
--------
fstream= 660 (n=23117)
stdio= 720 (n=23117)
fstream=  220(n=23117)
stdio= 710 (n=23117)
Djgpp 2.9.52
--------
fstream= 20 (n=23117)
stdio= 20 (n=23117)
fstream= 20(n=23117)
stdio= 20 (n=23117)
Probabilmente in quest'ultimo caso é meglio non affidarsi ai risultati
del test.


differenza di prestazioni diventano irrilevanti all'atto pratico.
Non mantenendo la "bella" interfaccia type-safe del C++.
Ho messo "bella" fra apici perche' ci sono molte cose che
non mi convincono delle scelte fatte da BS per l'I/O...
Magari appena ho un po' di tempo provo a far partire un
thread su questo subject se qualcun altro e' interessato
a discuterne. Sarei felice di convincermi che si tratta
di un design ragionevole...


andavano meglio :-)))
Whoooooops ... ovviamente nel codice ho usato
l'operatore corretto :)


 programma mantenendolo senza stravolgerlo.
Non puoi ottimizzare un algoritmo che gia` in partenza non e` valido.
Nella fattispecie hai confrontato un meccanismo che usa una lettura
con una che usa ben 3 distinte operazioni... I vari modi che hai poi
di accedere agli
stream non sempre sono equivalenti, anzi alcuni sono comodi in certe 
circostanze, altri in casi diversi.
Poi non e` mica detto che >> non sia implementato in termini di get()
e quindi
paghi anche overhead aggiuntivi...


 di un design ragionevole...
Mah... perfetto non e`... ma non e` neanche cosi` malvagio.


 stdio= 710 (n=23117)
ok, prendo atto.
La cosa strana e' che i tempi di stdio del BCB3 in release sono molto
peggiori di quelli del BCC55, strano, no ?!? Insomma quello freeware non
ottimizza fstream, ma ottimizza stdio ?!?
E quello a pagamento ottimizza fstream e si rifiuta di ottimizzare stdio ?!?
Mah....... Che strani compilatori questi !
Scherzi a parte noto che quando si fanno queste prove ad ogni persona
vengono fuori risultati diversi... Non si riesce mai a capire nulla.
Peccato!  (prendo atto cmq dei tuoi risultati!)
Alex

sarebbero stati stupidi!
Neanch'io l'ho mai usato, ma conosco benissimo le versioni freeware
rilasciate dalla Borland e so che spesso vengono tolte delle feature
importanti, del resto non credo che il loro Builder venderebbe molto
se fosse possibile scaricare liberamente dal loro sito una versione
gratuita con le stesse possibilità, non trovi?


 gratuita con le stesse possibilitą, non trovi?
Se vai alla pagina 
http://www.borland.com/bcppbuilder/freecompiler/
 e guardi
i testi (blazingly fast & Ultra high-performance optimizing compiler) ma
soprattutto la scheda riassuntiva delle caratteristiche sembra chiaro che
che il BCC5.5 free compiler sia di fatto il compilatore usato dal builder.
La scheda in fondo lo fa capire bene: la prima riga "Ultra high-performance
32-bit Borland ANSI C++ native code compiler (bcc v5.5)" e' contenuta sia in
FreeBCC che in CBStd-Pro-Ent. Insomma le crocette sono ovunque, anche sulla
versione free, indice che il compilatore sia lo stesso delle versioni a
pagamento.
Rispetto al builder ovviamente mancano molte cose: IDE (ambiente di
sviluppo), debugging avanzato etc... (ma la compilazione non sembra essere
diversa e/o meno ottimizzata).
Alex
P.S. questo e' quello che traspare dal sito, non mi assumo responsabilita'
;-)

pagamento.
Beh, non so cosa dirti , anche se a questo punto sarei quasi tentato
di prendere il BCC55 e fare qualche prova, ma siccome sono in molti ad
avere segnalato prestazioni non proprio ottimali da parte di questo
compilatore il sospetto che ci sia qualche limitazione rispetto alla
versione commerciale(che ripeto,questi problemi non li ha)esiste.
Comunque direi che il discorso é decisamente trasceso, visto che lo
scopo della mia prova era solo dimostrare che quello delle prestazioni
di fstream é un falso problema, perché può essere tranquillamente
risolto con delle adeguate ottimizzazioni(come quelle effettuate dal
g++ , ma io credo che ci siano compilatori che ottimizzino ancora
meglio), e comunque anche in mancanza di esse la differenza con le
vecchie funzioni del C non é elevata.


stream ti renderai conto come siano flessibili...
Io invece trovo che alcune scelte di rigidita' siano
decisamente molto discutibili. Il subject di questo thread
e' pero' ormai abbastanza fuorviante da consigliare un
nuovo thread ("dubbi sugli stream").


 decisamente molto discutibili. 
Ad esempio?


 Il tutto era partito dal confronto fra fscanf e operator<<.
allora sei recidivo :-)!!!


Ad esempio?
In questi giorni sto provando a costruire una mia alternativa
(come tutti sanno e' molto piu' facile distruggere che costruire,
criticare che proporre). Se arrivo a qualcosa di decente saro'
felice di sentire pareri sul risultato...
Al momento trovo il design degli stream brutto da un punto di
vista filosofico per molte ragioni... solo per citare le quattro
principali:
 - fare in modo che una operazione infulenzi quale sara' il
   comportamento di una istanza nella prossima chiamata ad
   un suo metodo (ma solo in quella successiva) la trovo una
   scelta molto discutibile in programmazione OO. Una sorta di
   "coupling temporale" decisamente brutto e fonte di potenziali
   problemi. Eppure e' il sistema base usato per la
   formattazione dell'output su stream.
 - Il fatto che nelle classi base di fondazione del sistema ci
   si sia occupati di cose come il numero di decimali e'
   secondo me indice di un problema. Quello sarebbe dovuto
   essere qualcosa in qualche modo incapsulato per i numeri
   in virgola mobile: le modalita' di formattazione di un tipo
   di dato dovrebbero essere localizzate nel tipo di dato.
   Come si puo' pensare altrimenti realmente di estendere la
   cosa ? Modificando ios::base nelle proprie applicazioni
   con l'aggiunta di cio' che serve per formattare i nostri
   oggetti ?
 - La gestione della formattazione output in C++ e'
   terribilmente scomoda, prolissa e meno leggibile se
   paragonata a quella basata su un formalismo alla "printf".
 - Le operazioni di I/O su stream non sono ben individuate
   da un punto di vista temporale se con operazione intendiamo
   una sequenza di "<<" concatenati. In particolare lo stream
   non sa quando l'operazione e' iniziata e quando e' finita.
   Con "printf" questa informazione e' salva (e a volte utile).


    Con "printf" questa informazione e' salva (e a volte utile).
questa non l'ho capita...


questa non l'ho capita...
Immagina di dover gestire l'output su stream in un programma
multithread... (es. una facility di logging).
Con una bella funzione "di quelle di una volta"
  void Log(int level,char *fmt,...);
con un numero variabile di argomenti hai risolto brillantemente.
Con gli stream come fai ?


 Con gli stream come fai ?
Potresti accumulare l'output in un buffer thread-specific e al primo flush
(pubsync) scriverlo dove devi scriverlo (file/syslog).
Ammetto però che il ricorso a delle TSS non è proprio il massimo in fatto
di performance.
Recentemente ho provato un diverso approccio. Anzichè usare direttamente
un unico logger globale, ho tanti oggetti locali ognuno con un suo buffer,
i quali al momento del flush trasmettono l'output a un singleton
condiviso. (In realtà non ho usato proprio gli stream standard, bensì
classi che con gli stream hanno in comune soltanto l'uso di operator<<.
Però l'idea di base dovrebbe applicabile comunque.)
Max

Però l'idea di base dovrebbe applicabile comunque.)
In realta' il problema di base e' che mentre printf e' pensato per
incapsulare in un'unica operazione l'output di piu' variabili (cosa
comoda) l'approccio basato su operator<< e' invece "frammentato".
L'output C++ non e' molto diverso da
   void print_an_int(int x);
   void print_a_float(float x);
   void print_a_char_literal(const char *x);
   void next_field_width_is(int width);
   ...
con semplicemente un po' di "zucchero sintattico" per rendere la
cosa non assolutamente oscena (come invece sarebbe con chiamate
come quelle che ho descritto). Poi uno puo' anche cercare "trucchi"
per aggirare il problema di approccio di base... ma quello resta.
Io sono convinto che sarebbe stato meglio cercare di estendere
il concetto di "output formattato" verso cose piu' dinamiche...
ad esempio con printf il formato elenca tutti i campi passati
a printf in ordine e questo e' secondo me una limitazione che
a volte pesa... sarebbe bello poter avere delle linee di formato
che accedono ai campi in un ordine diverso (in linguaggi che hanno
una certa specializzazione sulla formattazione I/O si possono
direttamente citare i nomi delle variabili nella stringa di
formato... ma un simile approccio in C++ sarebbe troppo pesante).
Il C++ e' secondo me piu' "primitivo" del C su questa cosa...
semplicemente c'e' un overload di operatori che cerca di
nascondere un approccio all'I/O piu' rozzo (dal punto di
vista dell'uso).


 Con gli stream come fai ?
Su questo ti hanno gia` dato una risposta: n oggetti buffer dedicati
agli n thread e poi il flush ricorrendo ad un singleton che gestisce
lo stream.
