voici MAIN.C:
[root@localhost test]# ./test 3 before:(nil), after:(nil), sizeof val:24 int_array:0x7ffeadc69470, int_array[0]:0x7ffeadc69470, int_array[1]:0x7ffeadc69498, int_array[2]:0x7ffeadc694c0, int_array[3]:0x7ffeadc694e8 val:0x7ffeadc69440, val[0]:0x7ffeadc69470, val[1]:0x7ffeadc694e8, val[2]:0x3, val[3]:0x4005ba before:(nil), after:(nil) [root@localhost test]# ./test 6 before:(nil), after:(nil), sizeof val:48 int_array:0x7ffcd30f1f50, int_array[0]:0x7ffcd30f1f50, int_array[1]:0x7ffcd30f1f78, int_array[2]:0x7ffcd30f1fa0, int_array[3]:0x7ffcd30f1fc8 val:0x7ffcd30f1f00, val[0]:0x7ffcd30f1f50, val[1]:0x7ffcd30f1fc8, val[2]:0x7ffcd30f2220, val[3]:(nil) before:(nil), after:(nil)
3 Réponses :
est la déclaration de graphique 2D de taille variable incorrecte? P> blockQuote>
en C ++, la taille de toutes les variables de réseau doit être une constante de temps de compilation.
Taille code> n'est pas une constante de temps de compilation, et donc
int * val [taille]; code> est mal formé en C ++. P>
pour VLAS, oui, le résultat de C 2011 en ligne Projet em> sup> p>
emphase ajoutée. P>
Cela a du sens, puisque la taille d'une VLA n'est pas établie tant que le temps d'exécution. p>
Je ne sais pas ce que vous essayez d'accomplir avec taille de code> est calculé à l'exécution: p>
6.5.3.4 le
taille de code> et
_ALignof code> opérateurs strong>
...
2 le taille de strong> code> donne la taille (en octets) de son opérande, qui peut être un
expression ou le nom de parenthèse d'un type. La taille est déterminée à partir du type de
l'opérande. Le résultat est un entier. si le type de l'opérande est un tableau de longueur variable
type, l'opérande est évalué; em> sinon, l'opérande n'est pas évalué et le résultat est un
Entier constant. BlockQuote>
avant code> et
après code> - si vous essayez de voir quelles adresses
val code > Prends, ce n'est pas le moyen de le faire. Tout d'abord, vous voudriez imprimer les valeurs de
et avant code> et
et après code>, mais même il n'y a aucune garantie que les objets sont aménagés dans la mémoire dans le même ordre qu'ils ont été déclarés. Il n'est pas non plus garanti que les VLAS sont attribuées à partir de la même région de mémoire que les autres variables code> code> (elles sont généralement, mais ce n'est pas nécessaire). p>
Merci John and Blaze, et oui, c'est Voici plus à apprendre, trouvé à Wikipedia: Vals code> (longueur de la variable), qui est pris en charge par GNU C compilateur (GCC) comme extension depuis C99. Donc, beaucoup de choses dépendent du compilateur. p>
Allocation
P>
"Ce n'est pas l'heure de la compilation, mais le temps d'exécution quand Tailleof () est déterminé?" I> Normalement, il est à la compilation, mais pour les VLAS, il doit les déterminer au moment de l'exécution. Notez que les VLAS ne font pas partie de C ++ et cela ne fonctionne que sur les compilateurs qui les tolèrent néanmoins.
Comme il s'agit de code entièrement C (y compris l'extension du nom de fichier), il doit être étiqueté C et non C ++.
"La déclaration de graphique 2D de taille variable est-elle incorrecte?" ---> Il n'y a pas de tableau 2D de taille variable dans le code.