récupérer la taille d'un tableau

C'est le freestore qui doit s'ocuper de connaitre la taille je crois. Et vu que chaque implémentation de freestore va s'y prendre comme elle l'entend ... d'autant qu'elle peut être détournée par programmation.
Après, il est vrai qu'il y a aussi une info du nombre d'éléments à détruire (!= du nombre d'octets alloués). A tout les coups, c'est implementation specific. Mais je verai bien l'info stockée juste avant le début du buffer officiellement alloué. A l'occasion, si j'y pense, je jetterai un oeil à Imperfect C++, c'est tout à fait le genre détails qui peut avoir été exploré dans le bouquin.

Citation:

---

Envoyé par roulious

Est-ce que tu veux dire la chose suivante ?

Code:

---

1 2 3 4 5

int f(int array[]) { return sizeof(array); }

---

Dans ce cas, ça ne marche pas non plus, puisqu'un paramètre de type T[] est transformé en T*. Cf. Standard 8.3.5-3 et http://groups.google.com/group/comp....66d0252ded2390

---

Non, je veux dire la chose suivante:

Code:

---

1 2	char buf[80]; fgets(buf, sizeof(buf), stdin);

---

Ti-R : Tu peux utiliser le ARRAYSIZE() de visual sans problème en C++ : Elle est définie selon un template qui ne marche qu'avec les tableaux, et un programme C++ ne compile pas si on passe autre chose qu'un tableau à ARRAYSIZE().

Attention, ce code est extrait des headers microsoft:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#define ARRAYSIZE(A) RTL_NUMBER_OF_V2(A)   //Un pavé de commentaires, je mets juste la fin: // [...] // We never even call RtlpNumberOf, we just take the size of dereferencing its return type. // We do not even implement RtlpNumberOf, we just decare it. // // Attempts to pass pointers instead of arrays to this macro result in compile time errors. // That is the point. // extern "C++" // templates cannot be declared to have 'C' linkage template <typename T, size_t N> char (*RtlpNumberOf( UNALIGNED T (&)[N] ))[N];   #define RTL_NUMBER_OF_V2(A) (sizeof(*RtlpNumberOf(A)))

---

Médinoc, même si il y a ARRAYSIZE, qui doit sûrement servir, et être pratique dans certain cas (si on ne connaît pas le code par exemple), je pense juste que pour être plus portable, et plus souple, une bonne variable fait l'affaire. Au moins je suis sur de mon coup, et si je passe un coup de DevCpp par-dessus, en principe no problemo...

Tu veux dire une bonne constante, non?
ARRAYSIZE n'est supposé marcher que pour des données dont la taille est connue statiquement à la compilation (et peut-être pour des VLA)

Les 2 (constante et variable), je généralise, car c'est valable pour des tableaux dynamiques et tableaux statiques.

Citation:

---

Envoyé par Ti-R

Médinoc, même si il y a ARRAYSIZE, qui doit sûrement servir, et être pratique dans certain cas (si on ne connaît pas le code par exemple), je pense juste que pour être plus portable, et plus souple, une bonne variable fait l'affaire. Au moins je suis sur de mon coup, et si je passe un coup de DevCpp par-dessus, en principe no problemo...

---

On sait faire ça de manière non propriétaire et, je pense, portable. -> http://hermitte.free.fr/Info/C++/lib..._help.hpp.html -- pour la portabilité, begin() doit renvoyer ptr+0, SunWSPro tire la gueule sinon.
boost::begin et boost::end remplacent déjà avantageusement les définitions homonynes dans le lien donné. Je ne sais pas si il y a size() (fonction) et array_size() (macro) dans boost.

Perso, je préfère 100 fois avoir ces définitions plutôt que des constantes non maintenables. Cela permet d'écrire des trucs comme

Code:

---

1 2 3

enum E { a, b, c, END }; const char* ch[] = { "a", "b", "c" }; STATIC_ASSERT( END == arraysize(ch), Sizes_Mismatch_for_E_and_ch );

---