Permettimi di chiarire meglio questo:
La sua struttura ha una dimensione fissa, cosi' come la sua "matrice di strutture", in quanto gli elementi (che inserisce) vengono allocati "altrove".
La classe vector contiene solo un puntatore agli elementi, quindi il sizeof di "A" o di "m" e' sempre costante, indipendentemente dagli elementi che inserisce.
Oltretutto non accede agli elementi (nel ciclo for) ma solo ad una variabile membro (attraverso size()), quindi (in questo caso) anche l'ottimizzazione dell'allocazione non dovrebbe importare (forse manda solo "in confusione" l'ottimizzatore, leggasi dopo): in pratica sarebbe come utilizzare una struttura del genere:
Che poi il codice sia poco leggibile e che sia da riscrivere in ottica produttiva, sono assolutamente d'accordo. 😉
@M1n021 oltretutto i compilatori moderni riescono ad ottimizzare meglio il codice attraverso gli indici di array/matrici/etc: hanno piu' difficolta' ad "interpretare" l'aritmetica dei puntatori, o meglio, non riescono a "manipolarlo" in maniera arbitrale piu' di tanto.
(ricordo che non era cosi'... quando le CPU erano molto piu' "semplici")
Quindi questo manda all'aria (in un certo senso) anche la mia ipotesi che fosse l'allocazione (e relativa ottimizzazione) degli elementi della classe vector che potessero aver confuso l'ottimizzatore.
Ed anche chi scrive il codice, non dovrebbe, in un ciclo del genere, preoccuparsi di dichiarare "volatile" la variabile "i" (di controllo ciclo) e nemmeno la matrice) .
Aggiungo...
pero' in questo caso, se utilizzi gli indici, funziona correttamente (quello di prima, anche con gli indici, non funzionava comunque)
La sua struttura ha una dimensione fissa, cosi' come la sua "matrice di strutture", in quanto gli elementi (che inserisce) vengono allocati "altrove".
La classe vector contiene solo un puntatore agli elementi, quindi il sizeof di "A" o di "m" e' sempre costante, indipendentemente dagli elementi che inserisce.
Oltretutto non accede agli elementi (nel ciclo for) ma solo ad una variabile membro (attraverso size()), quindi (in questo caso) anche l'ottimizzazione dell'allocazione non dovrebbe importare (
C++:
struct A
{
bool flag;
int size;
};Che poi il codice sia poco leggibile e che sia da riscrivere in ottica produttiva, sono assolutamente d'accordo. 😉
@M1n021 oltretutto i compilatori moderni riescono ad ottimizzare meglio il codice attraverso gli indici di array/matrici/etc: hanno piu' difficolta' ad "interpretare" l'aritmetica dei puntatori, o meglio, non riescono a "manipolarlo" in maniera arbitrale piu' di tanto.
(ricordo che non era cosi'... quando le CPU erano molto piu' "semplici")
Secondo me e' un bug... 😉
Non l'avevo visto... o meglio rispondevo a quello che avevo letto ieri sera (ma vista l'ora tarda, temevo fossi io quello in errore)
Quindi questo manda all'aria (in un certo senso) anche la mia ipotesi che fosse l'allocazione (e relativa ottimizzazione) degli elementi della classe vector che potessero aver confuso l'ottimizzatore.
Ed invece, come scrivevo prima, l'ottimizzazione di m, non dovrebbe importare nulla: il ciclo for dovrebbe terminare comunque, anche senza conoscere cosa fa m... essendoci l'operatore logico &&.
Ed anche chi scrive il codice, non dovrebbe, in un ciclo del genere, preoccuparsi di dichiarare "volatile" la variabile "i" (di controllo ciclo) e nemmeno la matrice) .
Aggiungo...
pero' in questo caso, se utilizzi gli indici, funziona correttamente (quello di prima, anche con gli indici, non funzionava comunque)
C++:
int main()
{
int m[3][3] = {{1, 2, 3},
{4, 5, 6},
{7, 8, 9}};
for(unsigned int i = 0; i < 3 * 3 && m[i/3][i%3]; ++i)
{
cout << i << endl;
}
}
// e funziona anche se utilizzassi questo for
for(unsigned int i = 0; i < 3 * 3 && (*m)[i%3]; ++i)
Ultima modifica:
