View Full Version : [C] Dimensione array definita dinamicamente
Salve ragazzi!
Sto riprendendo il linguaggio C a distanza di oltre un anno, ed improvvisamente mi è crollata una certezza :eek:
Per quanto ne so, quando si definisce un array la sua dimensione deve essere nota in fase di compilazione, ed in particolare essa deve essere una costante. Ora, facendo un po' di prove, mi accorgo che compilando ed eseguendo un programma del genere:
#include <stdio.h>
int main(void)
{
int c;
int DIM;
printf("Inserisci dimensione array: ");
scanf("%d", &DIM);
int stringa[DIM];
for (c = 0; c < DIM; c++)
stringa[c] = c;
printf("\nFine\n");
return 0;
}
non solo non ottengo errori in compilazione (gcc dovrebbe come minimo sputarmi in faccia), ma non avviene nemmeno un segmentation fault in fase di esecuzione.
Qualcuno saprebbe spiegarmi come mai? :stordita:
Preciso che uso gcc versione 4.2.4 su Linux 2.6.24 64 bit
wizard1993
27-01-2009, 11:47
per il c99 si può fare, è il c++ che non lo supporta
Ho provato anche a compilare questo con g++, e non ricevo errori nemmeno a runtime...
#include <iostream>
using namespace std;
int main(void)
{
int d;
cout << "Inserisci dimensione array: ";
cin >> d;
int vettore[d];
for (int i = 0; i < d-1; i++)
vettore[i] = i;
cout << "Fatto!"<<endl;
return 0;
}
:confused:
EDIT: solo se compilo passando a gcc l'opzione -pedantic ricevo il warning sulla dimensione variabile dell'array, ma non un errore...
warning: ISO C90 forbids variable-size array ‘stringa’
wizard1993
27-01-2009, 14:21
Ho provato anche a compilare questo con g++, e non ricevo errori nemmeno a runtime...
#include <iostream>
using namespace std;
int main(void)
{
int d;
cout << "Inserisci dimensione array: ";
cin >> d;
int vettore[d];
for (int i = 0; i < d-1; i++)
vettore[i] = i;
cout << "Fatto!"<<endl;
return 0;
}
:confused:
EDIT: solo se compilo passando a gcc l'opzione -pedantic ricevo il warning sulla dimensione variabile dell'array, ma non un errore...
proprio perchè lo vieta il c90 ma non il c99 e visto che il gcc è un compilatore c99 quella stringa viene accettata, e la sua validità "importata" in c++
#include <stdio.h>
int main(void)
{
int c;
int DIM;
printf("Inserisci dimensione array: ");
scanf("%d", &DIM);
int stringa[DIM];
for (c = 0; c < DIM; c++)
stringa[c] = c;
printf("\nFine\n");
return 0;
}
anche io lavoro con il gcc, in ambiente Cygwin.
se vuoi inizializzare un array puoi ovviamente farlo durante il programma, ma la dimensione (la dimensione MASSIMA) deve essere definita in modo statico, magari con un #define
il tuo frammento di codice io lo farei cosi:
#include <stdio.h>
#include <stdlib.h>
#define MAXDIM 128
int main(void)
{
int c, dim;
int stringa[MAXDIM];
printf("Inserisci dimensione array: ");
scanf("%d", &dim);
for (c = 0; c < dim; c++)
stringa[c] = c;
printf("\nFine\n");
return EXIT_SUCCESS;
}
il tuo frammento di codice io lo farei cosi:
Anch'io lo farei così, e l'ho sempre fatto così! :p
Però la mia era una curiosità, scaturita dopo aver letto questa frase su un libro di Kernighan e Pike del 1999 (The practice of programming) a proposito delle differenze tra C e C++:
Anche C ha valori di tipo const, ma non possono essere usati come limite di un array, così l'istruzione enum rimane il metodo migliore in C.
Quindi ho provato a istanziare un array usando per la sua dimensione un intero costante al posto di una macro o un enum, verificando che non ottenevo alcun errore né in compilazione né a runtime; a quel punto ho provato ad istanziarlo usando addirittura una variabile, ed il non ricevere errori mi ha un po' disorientato.
Ora mi chiedo: il fatto che lo standard C99 permetta una cosa del genere, implica anche che sia corretto? Ovvero, posso istanziare array usando per dimensione una variabile senza preoccuparmi delle conseguenze a runtime o, pur essendo consentito dallo standard, la cosa rimane sbagliata? :stordita:
Grazie :)
Dipende tutto da chi deve guardare quel codice...se è un professore, mediamente poco informato sugli standard "nuovi", usa l'allocazione dinamica. Altrimenti puoi fare quello che vuoi...quello è C standard :D
In C++ ad esempio non lo farei.
wizard1993
27-01-2009, 19:57
mediamente poco informato sugli standard "nuovi"
hai detto bene, mediamente. i professori che conosco io sono sempre stati i primi ad aggiornarsi ai nuovi standard
hai detto bene, mediamente. i professori che conosco io sono sempre stati i primi ad aggiornarsi ai nuovi standard
Fra tutti quelli che ho avuto, un dettaglio del genere lo conoscerebbero in due o tre :D
Dipende tutto da chi deve guardare quel codice...se è un professore, mediamente poco informato sugli standard "nuovi", usa l'allocazione dinamica. Altrimenti puoi fare quello che vuoi...quello è C standard :D
In C++ ad esempio non lo farei.
Non lo deve guardare nessuno, però deve essere corretto :fagiano:
A questo punto credo che usare lo standard C90 può essere utile solo per compatibilità con compilatori più vecchi, no? :rolleyes:
wizard1993
27-01-2009, 21:08
Non lo deve guardare nessuno, però deve essere corretto :fagiano:
A questo punto credo che usare lo standard C90 può essere utile solo per compatibilità con compilatori più vecchi, no? :rolleyes:
visto che la borland si ostina a distribuire un compilatore che non supporta nemmeno le costanti nelle classi, figurati questi "dettagli"
A questo punto credo che usare lo standard C90 può essere utile solo per compatibilità con compilatori più vecchi, no? :rolleyes:
Sì, tipo Microsoft e Borland che non supportano il C99.
Sì, tipo Microsoft e Borland che non supportano il C99.
Beh, non dovrei aver bisogno di compilatori (o sistemi operativi, o applicazioni) Microsoft, almeno per i prossimi 150 anni :asd:
Qualcuno saprebbe spiegarmi come mai? :stordita: bah, banalissimo: l'allocazione di un vettore in memoria automatica avviene sottraendo una determinata quantitá allo stack pointer; la semantica che tu riporti (dichiarazione di un array con una variabile come dimensione anziché una costante) fa si' che il codice generato dal compilatore sottragga allo stack pointer il valore contenuto in una certa variabile anziché un valore costante. si ha segmentation fault solo quando si accede ad un array per la cui dichiarazione é stato sottratto un valore che ha fatto andare lo stack pointer oltre il limite dello stack.
Ah, ok! Grazie della spiegazione :)
bah, banalissimo: l'allocazione di un vettore in memoria automatica avviene sottraendo una determinata quantitá allo stack pointer; la semantica che tu riporti (dichiarazione di un array con una variabile come dimensione anziché una costante) fa si' che il codice generato dal compilatore sottragga allo stack pointer il valore contenuto in una certa variabile anziché un valore costante. si ha segmentation fault solo quando si accede ad un array per la cui dichiarazione é stato sottratto un valore che ha fatto andare lo stack pointer oltre il limite dello stack.
Secondo la tua spiegazione questo sarebbe un errore. In C95 è come dici, in C99 invece non è un errore, è perfettamente lecito.
Secondo la tua spiegazione questo sarebbe un errore. In C95 è come dici, in C99 invece non è un errore, è perfettamente lecito. a cosa ti riferisci, alla situazione che provoca il segmentation fault?
penso che ci siano solo due modi di allocare dati dinamicamente: nello stack e nell'heap; il primo ha un limite (ad esempio impostato dal linker su Windows, non so su Linux), il secondo invece non ha virtualmente limite poiché é limitato solo dalla disponibilitá di indirizzi virtuali e di risorse di sistema; peró mentre per allocare nel primo é sufficiente una sottrazione, per allocare nel secondo é necessaria una chiamata di sistema con eventuale switch in kernel mode, quindi é inefficiente.
se sta scritto da qualche parte che in C99 gli array la cui dimensione é espressa da una variabile devono essere allocati nell'heap allora é un motivo in piu per non usare il C99 :D
No, intendevo una cosa diversa, tu l'hai trattato come se fosse un errore, ma in realtà non lo è.
Che finisca lo stack può succedere, ma al pari dell'allocazione classica se io utilizzo un intero troppo grande ;)
Ecco l'implementazione di questo codice:
void f()
{
int n;
scanf("%d", &n);
int v[n];
while(n--);
}
f:
.LFB2:
pushq %rbp
.LCFI0:
movq %rsp, %rbp
.LCFI1:
subq $48, %rsp
.LCFI2:
movq %fs:40, %rax
movq %rax, -8(%rbp)
xorl %eax, %eax
movq %rsp, %rax
movq %rax, -40(%rbp)
leaq -12(%rbp), %rsi
movl $.LC0, %edi
movl $0, %eax
call scanf
movl -12(%rbp), %eax
cltq
salq $2, %rax
addq $15, %rax
addq $15, %rax
shrq $4, %rax
salq $4, %rax
subq %rax, %rsp
movq %rsp, -48(%rbp)
movq -48(%rbp), %rax
addq $15, %rax
shrq $4, %rax
salq $4, %rax
movq %rax, -48(%rbp)
movq -48(%rbp), %rax
movq %rax, -24(%rbp)
.L2:
movl -12(%rbp), %eax
testl %eax, %eax
setne %dl
subl $1, %eax
movl %eax, -12(%rbp)
testb %dl, %dl
jne .L2
movq -40(%rbp), %rsp
movq -8(%rbp), %rax
xorq %fs:40, %rax
je .L4
call __stack_chk_fail
.L4:
leave
ret
Sinceramente mi sembra un po' contorta come operazione :stordita: Non ho voglia di mettermi a leggerlo :D Comunque viene usato lo stack.
bah, banalissimo: l'allocazione di un vettore in memoria automatica avviene sottraendo una determinata quantitá allo stack pointer; la semantica che tu riporti (dichiarazione di un array con una variabile come dimensione anziché una costante) fa si' che il codice generato dal compilatore sottragga allo stack pointer il valore contenuto in una certa variabile anziché un valore costante. si ha segmentation fault solo quando si accede ad un array per la cui dichiarazione é stato sottratto un valore che ha fatto andare lo stack pointer oltre il limite dello stack.
Quoto. L'array viene allocato nello stack. Riguardo ai motivi del perche' il compilatore permatta questa zozzeria non saprei. Credo sia una morivazione filosofica piu' che tecnica: nel C ( e in parte nel c++ ) si cercano di mettere meno vincoli possibili al programmatore per non limitare la "potenza del linguaggio". Se questo crea, o meglio facilita, gli errori pazienza.
Comunque evita come la peste questo costrutto: segmentation fault e' il migliore degli errori che possano accadere. Mi ricordo un esempio simile in c++ in cui se si usciva dalla lunghezza dell'array, si andava a modificare il valore di altre variabili automatiche presenti nello stack, senza controllo dei tipi. Poi voglio vedere a debuggare codice del genere.
:muro:
Quante volte lo devo ripetere che il compilatore lo permette perché è C standard ? :mbe:
Questo codice DEVE funzionare perfettamente con un compilatore aderente allo standard C99 e DEVE dare errore con un compilatore aderente allo standard C95 o C89.
Quoto. L'array viene allocato nello stack. Riguardo ai motivi del perche' il compilatore permatta questa zozzeria non saprei. perché rientra nello standard. perché mai sarebbe una zozzeria? lo era solo quando era un'estensione GNU non facente parte dello standard.
Comunque evita come la peste questo costrutto: segmentation fault e' il migliore degli errori che possano accadere. a si...? e che altro puó succedere?
Mi ricordo un esempio simile in c++ in cui se si usciva dalla lunghezza dell'array, si andava a modificare il valore di altre variabili automatiche presenti nello stack, senza controllo dei tipi. Poi voglio vedere a debuggare codice del genere.
:muro: e perché mai questo dovrebbe succedere solo con gli array la cui dimensione é espressa da una variabile anziché da una costante?
La trovo una zozzeria perche' possibile fonte di problemi. Se vuoi un'array con dimensione determinata a run-time lo crei sullo heap. Segmentation fault almeno e' un segnale che qualcosa non va. Trovo molto peggio veder il codice girare, e poi trovarsi con errori inaspettati, magari in zone che logicamente non hanno niente a che vedere con la fonte del problema.
Comunque che sia prevista o meno dagli standard la trovo una pratica da deprecare.
Riguardo all'esempio la situazione era piu' o meno questa: si creava un'array nello stack con dimensione letta in input. In un caso particolare, pur accedendo ad un'area entro i limiti dell'array, si modificava il valore di altre variabili nello stack. Quando ho tempo do un'occhiata se trovo il codice.
La trovo una zozzeria perche' possibile fonte di problemi. Se vuoi un'array con dimensione determinata a run-time lo crei sullo heap. Segmentation fault almeno e' un segnale che qualcosa non va. Trovo molto peggio veder il codice girare, e poi trovarsi con errori inaspettati, magari in zone che logicamente non hanno niente a che vedere con la fonte del problema.
Comunque che sia prevista o meno dagli standard la trovo una pratica da deprecare.
Riguardo all'esempio la situazione era piu' o meno questa: si creava un'array nello stack con dimensione letta in input. In un caso particolare, pur accedendo ad un'area entro i limiti dell'array, si modificava il valore di altre variabili nello stack. Quando ho tempo do un'occhiata se trovo il codice.
Con i variable length array in caso di superamento delle dimensioni disponibili dello stack l'errore è lo stesso che si presenta nel caso tu abbia passato ad un vettore statico un intero troppo grande per le dimensioni dello stack.
Non si sovrascrivono altre variabili, questo mi sembra ovvio.
La trovo una zozzeria perche' possibile fonte di problemi. quali sono i potenziali problemi derivanti dalla dichiarazione di un array usando una variabile come dimensione che non si possono verificare quando invece usi una costante o un literal?
Se vuoi un'array con dimensione determinata a run-time lo crei sullo heap. perché?
Segmentation fault almeno e' un segnale che qualcosa non va. allocare un array in memoria automatica non provoca quasi mai un segmentation fault.
Trovo molto peggio veder il codice girare, e poi trovarsi con errori inaspettati, magari in zone che logicamente non hanno niente a che vedere con la fonte del problema. é giunto il momento di usare una piattaforma managed allora, come .NET. ah, volevi le performance? e allora deciditi, ma sappi che per definizione l'uomo sbaglia.
Comunque che sia prevista o meno dagli standard la trovo una pratica da deprecare. santo cielo, corriamo subito a deprecarla allora :rolleyes:
Riguardo all'esempio la situazione era piu' o meno questa: si creava un'array nello stack con dimensione letta in input. in C++ non si puó, e se l'hanno fatto allora questa era la vera porcata fuori standard. eh ma si sa, se il compilatore é GNU tutte le estensioni sono permesse, perché il software libero é bello.
Con i variable length array in caso di superamento delle dimensioni disponibili dello stack l'errore è lo stesso che si presenta nel caso tu abbia passato ad un vettore statico un intero troppo grande per le dimensioni dello stack.
Non si sovrascrivono altre variabili, questo mi sembra ovvio.
Eppure era proprio quello che succedeva. Sovrascrittura di altre variabili nello stack. L'esempio era stato creato dal professore di programmazione ( o meglio dalla sua assistente ) per controbattere agli studenti che si ostinavano ad utilizzare array statici con dimensione decisa a runtime. Non so se fosse un problema di complilatore oppure di un bug di progettazione, ma era quello che accadeva.
Eppure era proprio quello che succedeva. Sovrascrittura di altre variabili nello stack. L'esempio era stato creato dal professore di programmazione ( o meglio dalla sua assistente ) per controbattere agli studenti che si ostinavano ad utilizzare array statici con dimensione decisa a runtime. Non so se fosse un problema di complilatore oppure di un bug di progettazione, ma era quello che accadeva.
Con quale compilatore ? E che versione, se te la ricordi ?
Con quale compilatore ? E che versione, se te la ricordi ? regola d'oro del programmatore: non é mai un bug del compilatore, quindi se sospetti che sia un bug del compilatore continua a rileggerti il codice perché non é un bug del compilatore; no, neanche stavolta.
posto questo, finché non abbiamo quel codice, troppo ce ne passa prima di deprecare i variable length arrays: anzittutto bisogna vedere se Braga83 si ricorda bene il significa di quell'esempio, poi bisogna vedere se l'esempio effettivamente funzionava come ci si aspetta, cioé male (puó darsi che l'assistente lo abbia solamente fatto vedere a lezione e che Braga83 non abbia neanche provato a compilarlo). ed infine, ammettendo che sia venuto alla luce un effettivo problema dei variable length arrays (che ricordo non esistere in C++) bisogna vedere se il problema non sia dovuto semplicemente ad un'interpretazione errata dello standard da parte dell'assistente e degli studenti.
tra l'altro mi fa morire l'espressione "gli studenti si ostinavano ad usarli"; e perché, non si puó? :rolleyes:
Non so se fosse un problema di complilatore oppure di un bug di progettazione, male, molto male: perché c'é una bella differenza tra il non poter usare una feature del linguaggio con una sola versione di un solo compilatore e il non poterla usare mai. quindi prima di deprecare gli altri ( :asd: ) controlla meglio.
Con quale compilatore ? E che versione, se te la ricordi ?
Parliamo di circa 4/5 anni fa. Utilizzavamo g++. Mi pare la versione fosse arrivata alla 3.
Parliamo di circa 4/5 anni fa. Utilizzavamo g++. Mi pare la versione fosse arrivata alla 3.
Cerca il codice e verifichiamo ;)
Allora con il g++ 4.2.4 questo codice c++ non compila.
#include <iostream>
using namespace std;
int main()
{
int y = 4;
int z = 5;
int l;
cout<<"inserisci la dimensione dell'array"<<endl;
cin>>l;
int a[l];
}
L'errore che ottengo e'
Kubuntu:~/desktop $ g++ prova.cpp
prova.cpp: In function ‘int main()’:
prova.cpp:18: error: ISO C++ forbids variable-size array ‘a’
prova.cpp:9: warning: unused variable ‘y’
prova.cpp:10: warning: unused variable ‘z’
prova.cpp:18: warning: unused variable ‘a’
Ora provo ad installare i vecchi compilatori.
Certo che non compila, lo standard C++ non prevede i variable length array. Stiamo parlando solo ed esclusivamente di C.
D4rkAng3l
28-01-2009, 18:34
Dipende tutto da chi deve guardare quel codice...se è un professore, mediamente poco informato sugli standard "nuovi", usa l'allocazione dinamica. Altrimenti puoi fare quello che vuoi...quello è C standard :D
In C++ ad esempio non lo farei.
mmm ora è un po' che non smanaccio con C...ma fammi capire bene...con lo standard C99 posso trattare un vettore C come un elemento della classe Vector in Java o ho capito male?
Cioè...mettiamo che dichiaro un vettore V di interi senza dichiararne la dimensione e lo riempio con 5 elementi:
quindi V = [1,2,3,4,5]
poi faccio altre operazioni
poi gli dico di aggiungere altri 3 elemtni:
quindi V = [1,2,3,4,5,6,7,8]
funziona come se fosse una collezione dinamica o ho capito male qualcosa? :eek:
Hai capito male, semplicemente puoi definire la dimensione a runtime. Dopo non la puoi più cambiare però.
Certo che non compila, lo standard C++ non prevede i variable length array. Stiamo parlando solo ed esclusivamente di C.
Quale standard? Perché, come ho scritto in uno dei precedenti post (http://www.hwupgrade.it/forum/showpost.php?p=26035255&postcount=3), g++ un codice del genere me lo fa passare tranquillamente anche con l'opzione -ansi. Solo con l'opzione -pedantic ottengo l'errore in compilazione :wtf:
(per questo test ho usato g++ 4.0.1 su Darwin perché al momento non sto su Linux)
Probabilmente è stato corretto ;)
D4rkAng3l
28-01-2009, 19:04
Hai capito male, semplicemente puoi definire la dimensione a runtime. Dopo non la puoi più cambiare però.
ah allora è come la dichiarazione degli array in Java dove la dimensione può essere dichiarata a runtime ma una volta creato quella è e quella rimane?
Tnx
Andrea
Probabilmente è stato corretto ;)
No, anche g++ versione 4.3.2 (stavolta su Linux) mi fa passare tranquillamente quel codice finché non compilo con -pedantic, nel qual caso l'errore prodotto è ISO C++ forbids variable length array <nomevettore>
Nella pagina di manuale di gcc si legge che passare l'opzione -ansi a g++ equivale a passare -std=c++98, quindi per gcc lo standard C++98 consente di usare variabili come dimensione degli array... :fagiano:
DanieleC88
28-01-2009, 20:54
Non si sovrascrivono altre variabili, questo mi sembra ovvio.
Credo che intendesse che una variabile allocata sullo stack espone al rischio di stack smashing. :)
Se vuoi un'array con dimensione determinata a run-time lo crei sullo heap.
Però allocare sullo stack è più veloce, non è rischioso se usi accorgimenti mentre programmi. Allocare sull'heap va benissimo, ma devi fare attenzione ad evitare memory leak. :)
ciao ;)
Allora non si spiega perché non compili a Braga...
Nella pagina di manuale di gcc si legge che passare l'opzione -ansi a g++ equivale a passare -std=c++98, quindi per gcc lo standard C++98 consente di usare variabili come dimensione degli array... :fagiano:
No, non lo consente, infatti con -pedantic (trasforma warning in errori) ti dice che ISO C++ forbids variable length array <nomevettore>.
Comunque restiamo sul C, altrimenti non caviamo un ragno dal buco. Braga doveva farci sapere con quale compilatore un variable length array se usato all'interno dei suoi bound sovrascrive le altre variabili nello stack.
Comunque restiamo sul C, altrimenti non caviamo un ragno dal buco. Braga doveva farci sapere con quale compilatore un variable length array se usato all'interno dei suoi bound sovrascrive le altre variabili nello stack.
Ok :)
Nella pagina di manuale di gcc si legge che passare l'opzione -ansi a g++ equivale a passare -std=c++98, quindi per gcc lo standard C++98 consente di usare variabili come dimensione degli array... :fagiano: non credo, penso piuttosto che tu debba usare contemporaneamente -ansi e -pedantic perché altrimenti i variable length arrays li intende come estensione GNU. perché si sa, il software libero é bello e quindi tutte le estensioni sono permesse quando sono GNU :fagiano:
Allora con l'ultimo g++ di kubuntu il codice che ho postato non compila. Mentre istallando il 3.3 compila e sembra eseguire correttamente. Non ho impostato flag particolari. Riguardo al famoso esempio non ho avuto tempo di cercare. Comunque era scritto in c++ e non in C.
Molto strano che sotto Mac te lo lasci compilare. :confused:
Credo che intendesse che una variabile allocata sullo stack espone al rischio di stack smashing. :)
Esatto. Specie quando la variabile e' un puntatore.
perché si sa, il software libero é bello e quindi tutte le estensioni sono permesse quando sono GNU :fagiano:
Scusa, è già la seconda volta che lo ripeti, vogliamo parlare delle estensioni del compilatore Microsoft che è stato per decenni con lo scope delle variabili dichiarate nel for esteso al di fuori del for ??? :D
Esatto. Specie quando la variabile e' un puntatore.
Lo stack smashing è sempre possibile anche con i vettori dichiarati normalmente, basta andare fuori dai bound del vettore, ma non è un uso normale. Se si resta all'interno dei bound del vettore questo metodo è equivalente all'altro.
Allora con l'ultimo g++ di kubuntu il codice che ho postato non compila. Mentre istallando il 3.3 compila e sembra eseguire correttamente. Non ho impostato flag particolari. Riguardo al famoso esempio non ho avuto tempo di cercare. Comunque era scritto in c++ e non in C.
Molto strano che sotto Mac te lo lasci compilare. :confused:
No no, anche su Linux me lo lascia compilare senza alcun problema, indipendentemente dalla versione di gcc/g++ (comunque parlo sempre di versioni >= 4.0)
Scusa ma stiam parlando del codice che ho postato io o di quello tuo?
Scusa ma stiam parlando del codice che ho postato io o di quello tuo?
Tuo o suo cambia poco ;)
g++ -pedantic prova.cpp -o prova
prova.cpp: In function ‘int main()’:
prova.cpp:11: error: ISO C++ forbids variable length array ‘a’
g++ prova.cpp -o prova
compila senza errori.
Magari hai usato un ide che giustamente utilizza il flag -pedantic di default.
Riguardo al famoso esempio non ho avuto tempo di cercare. Comunque era scritto in c++ e non in C. risparmiati la fatica allora perché non ci riguarda.
Scusa, è già la seconda volta che lo ripeti, vogliamo parlare delle estensioni del compilatore Microsoft che è stato per decenni con lo scope delle variabili dichiarate nel for esteso al di fuori del for ??? :D avevo in mente piu che altro i soliti trolls che tuonano quando vedono __try/__except anziché try/catch :rolleyes:
e poi nessuno é perfetto: sará capitato anche al gcc di non essere compliant in qualche versione :p
Tuo o suo cambia poco ;)
g++ -pedantic prova.cpp -o prova
prova.cpp: In function ‘int main()’:
prova.cpp:11: error: ISO C++ forbids variable length array ‘a’
g++ prova.cpp -o prova
compila senza errori.
Magari hai usato un ide che giustamente utilizza il flag -pedantic di default.
No, nessun Ide. Ho fatto tutto da shell.
No, nessun Ide. Ho fatto tutto da shell.
:boh:
Avrai impostata qualche variabile d'ambiente tipo GCCFLAGS :boh:
avevo in mente piu che altro i soliti trolls che tuonano quando vedono __try/__except anziché try/catch :rolleyes:
e poi nessuno é perfetto: sará capitato anche al gcc di non essere compliant in qualche versione :p
Almeno in quel caso la compatibilità con lo standard veniva mantenuta ;)
Quella che ho riportato io rendeva proprio il codice incompatibile.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.