C++ Guru della Settimana #1

[Luc@s]

Originariamente inviato da fek

Se vi e' piaciuto, fra qualche giorno propongo un altro quesito.

E stato bellissimo

[downloader]

Originariamente inviato da fek
Bingo! Risposta esatta

Nel primo caso il compilatore produce un costruttore che assomiglia a:

int a;
int b;

// [...]

{
  a = b + 1;
  b = 10;
}

Si puo' chiaramente notare come il valore di b e' indefinito quando viene eseguita la prima inizializzazione, quindi il valore di a e' anch'esso indefinito.

Mentre nel secondo caso il costruttore assomiglia a:

int b;
int a;

// [...]

{
  b = 10;
  a = b + 1;
}

Da cui e' ovvio che a e b assumono rispettivamente valore 10 e 11.

Questo comportamento e' dettato dallo standard C++ e va implementato cosi' da ogni compilatore conforme.

Detto questo, si impara che e' buona abitudine non usare gli inizializzatori quando il valore di un membro della classe dipende dal valore di uno o piu' membri della classe. Usare normale codice nel costruttore. Questo vale anche quando di mezzo ci sono chiamate a costruttori di classi padri

In tutti gli altri casi e' buona norma abituarsi a usare gli inizializzatori che aiutano a scrivere codice piu' pulito e leggible.

Se vi e' piaciuto, fra qualche giorno propongo un altro quesito.

Piaciuto piaciuto...


Proponine degli altri!!! A discrezione dei Moderatori ovviamente

[cionci]

Cavolo...certo...altri altri

[downloader]

Ne posso proporre io uno al volo?

Cosa c'è di sbagliato in queste righe di codice?

void pippo(void)
{
int a[6], i = 0;

for(;i<6;i++)
i[a]=0;
}

[fek]

Originariamente inviato da downloader
Ne posso proporre io uno al volo?

Cosa c'è di sbagliato in queste righe di codice?

void pippo(void)
{
int a[6], i = 0;

for(;i<6;i++)
i[a]=0;
}

"i" non e' un'array e "a" non viene valutato come scalare, quindi i[a] e' sbagliata.

Noticina: preferite sempre ++i a i++, in altre parole preferite sempre il preincremento al postincremento a meno che non vi serva il valore della variabile da incrementare prima che venga incrementata (e' una caso raro).

Per tipi semplici non fa molta differenza, ma per oggetti che fanno overload degli operatori di incremento, potrebbe fare la differenza fra una semplice chiamata a funzione (preincremento) e la creazione di un oggetto temporaneo con conseguente chiamata a costruttore, operatore, distruttore.

Esempio:

Object obj;

++obj; // (1)
obj++; // (2)

(1) viene compilato in qualcosa di simile a:

obj.operator++(); // semplice chiamata a metodo

(2) viene compilato in:

Obj temp(obj); // costruttore di copia
obj.operator++();
temp.~Object(); // distruttore

Questo perche' state chiedendo al compilatore di conservare il valore di obj prima che venga incrementato e gentilmente lo copia in temp. Quell'oggetto temporaneo non puo' essere di solito eliminato dall'ottimizzatore perche' in generale il compilatore non puo' "guardare dentro" al costruttore e distruttore per sapere se sono operazioni semplici. In generale non lo sono.

Usate il preincremento, soprattutto se avete a che fare con STL

[downloader]

Non imbrogliate...
Non dovete compilà!!!

[cionci]

Formalmente niente...

i[a] == *(i + a)

Comunque è un po' bruttino...
Io, quando posso, uso sempre il preincremento...ormai l'ho preso di abitudine...

[downloader]

Originariamente inviato da cionci
Formalmente niente...

i[a] == *(i + a)

Comunque è un po' bruttino...

GIUSTO.

fek... mi deludi...

[downloader]

Originariamente inviato da cionci
Io, quando posso, uso sempre il preincremento...ormai l'ho preso di abitudine...

Se nn l'uso all'interno di espressioni dove il pre fa differenza con il post, uso il post... questione di abitudine...

[fek]

Originariamente inviato da fek
"i" non e' un'array e "a" non viene valutato come scalare, quindi i[a] e' sbagliata.

Ho scritto una scemenza. Questo e' codice valido.

"i" e' un'intero e viene automaticamente castato a puntatore, quindi puo' essere indirizzato.
"a" e' un puntatore e viene casato automaticamente a intero, quindi puo' essere usato come indice.

Dannato C e i suoi cast

[downloader]

Originariamente inviato da fek
Ho scritto una scemenza. Questo e' codice valido.

"i" e' un'intero e viene automaticamente castato a compilatore, quindi puo' essere indirizzato.
"a" e' un puntatore e viene casato automaticamente a intero, quindi puo' essere usato come indice.

Dannato C e i suoi cast

Ma cosa? Guarda che cionci ha dato la spiegazione giusta... i cast non c'entrano proprio in questo caso.

[fek]

Originariamente inviato da downloader
Se nn l'uso all'interno di espressioni dove il pre fa differenza con il post, uso il post... questione di abitudine...

Pero' cosi' non aiuti il compilatore a ottimizzare. Anche' se logicamente e' equivalente, usare il pre incremento a volte ti salva un caricamento nel registro anche con semplici interi!

[fek]

Originariamente inviato da downloader


Ma cosa? Guarda che cionci ha dato la spiegazione giusta... i cast non c'entrano proprio in questo caso.

Nope, il discorso li' e' sui cast. In realta' non si chiamano proprio cast ma "degradazione".
Cionci ha detto giusto, le due versioni sono perfettamente equivalenti in C, ma il "ragionamento" che fa il parser C++ quando interpreta quel codice e' quello che ti ho detto.

Infatti se provi a sostituire delle classi e fornisci i giusti operatori di conversione, lo vedi fare le chiamate.

[downloader]

Originariamente inviato da fek
Pero' cosi' non aiuti il compilatore a ottimizzare. Anche' se logicamente e' equivalente, usare il pre incremento a volte ti salva un caricamento nel registro anche con semplici interi!

Di che registro parli della CPU? Ma guarda che l'ottimizzatore gia lavora a modo suo e l'ottimizzazione (dipende anche dalle impostazioni chiaramente) non dovrebbe prescindere dal pre o post incremento. Ma poi i l'uso dei registri è di default... o no?

[cionci]

Originariamente inviato da fek
"i" e' un'intero e viene automaticamente castato a puntatore, quindi puo' essere indirizzato.
"a" e' un puntatore e viene casato automaticamente a intero, quindi puo' essere usato come indice.

Se fosse così e supponendo che a fosse allocata all'indirizzo 100 decimale...con un ciclo del genere andresti a scrivere agli indirizzi:

400
401
402
....

Invece di

100
104
108
....

Infatti il calcolo dell'indirizzo sarebbe i + sizeof(*i)*a...invece il compialtore traduce automaticamente i[a] come *(i + a) che con l'aritmentica dei puntatori significa andare a scrivere all'indirizzo a+sizeof(*a)*i...

[fek]

Originariamente inviato da downloader
Di che registro parli della CPU? Ma guarda che l'ottimizzatore gia lavora a modo suo e l'ottimizzazione (dipende anche dalle impostazioni chiaramente) non dovrebbe prescindere dal pre o post incremento. Ma poi i l'uso dei registri è di default... o no?

Si', registri della CPU
In alcune situazioni un po' intricate, quando l'ottimizzatore non riesce a star dietro a quello che scrivi, e' costretto a semplificare e si "dimentica" che le due espressioni magari possono essere equivalenti.

Se imposti le ottimizzazione al massimo e disassembly il codice prodotto, puoi vedere che riesci a mandare facilmente in crisi l'ottimizzatore che si salva il valore da incrementare anche se poi non gli serve piu'. E aiutiamolo un po' il compilatore!

[downloader]

Originariamente inviato da fek
Nope, il discorso li' e' sui cast. In realta' non si chiamano proprio cast ma "degradazione".
Cionci ha detto giusto, le due versioni sono perfettamente equivalenti in C, ma il "ragionamento" che fa il parser C++ quando interpreta quel codice e' quello che ti ho detto.

Infatti se provi a sostituire delle classi e fornisci i giusti operatori di conversione, lo vedi fare le chiamate.

Scusa... ma a me non suona bene... io so solo che la cosa avviene grazie all'operatore [] dove a[b] = *(a+b). Che c'entra il cast? Non l'ho capito cosa vuoi dire poi sulle classi...

Cionci che ne pensi?

Comunque vi saluto... a domani

[fek]

Originariamente inviato da cionci
Infatti il calcolo dell'indirizzo sarebbe i + sizeof(*i)*a...invece il compialtore traduce automaticamente i[a] come *(i + a) che con l'aritmentica dei puntatori significa andare a scrivere all'indirizzo a+sizeof(*a)*i...

Si', e' verissimo ma fai attenzione alla differenza fra C e C++. Il risultato e' uguale ma come i due parser arrivano a quel codice e' diverso.
Il C tira dritto e fa il ragionamento che fai tu.
Il C++ si domanda: "posso applicare l'operatore [] a i? Si', se lo converto (promuovo) a puntatore, posso usare a come parametro per l'operatore di default operator[](size_t i)? Si', se lo converto (degrado) ad un size_t".

Da qui in poi il comportamento di default dell'operator[] e' quello che dici tu e le due strade si riuniscono.

Comunque e' un bell'esempio perche' mostra come il C++ sia troppo zelante, retaggio della compatibilita' con il C, nel castare alle spalle del programmatore, cosa che a volte fa compilare codice come quello e magari porta a errori difficili da scoprire.

I puristi vorrebbero che i cast fossero sempre espliciti se non in pochi casi ben definiti.

[cionci]

Originariamente inviato da cionci
Infatti il calcolo dell'indirizzo sarebbe i + sizeof(*i)*a...invece il compialtore traduce automaticamente i[a] come *(i + a) che con l'aritmentica dei puntatori significa andare a scrivere all'indirizzo a+sizeof(*a)*i...

In effetti se si parla di C++ la cosa potrebbe diventare un po' più complicata...ora faccio qualche prova...

[Luc@s]

comincia a prendere una piega interessante