Bonjour!

Je voudrais connaitre la taille d'un tableau d'int de ce style:

int tableau[] { 0,1,2,3,4, };

Pour info je passe le tableau en paramètre dans une fonction.

Comment faire en C++ (sans avoir à utiliser un std::vector)? Sur les forums je ne vois que des fonctions C. 

Et quel est la taille max d'un tableau d'int?

Merci d'avoir lu!

-
Edité par Fatihldekur 19 septembre 2017 à 21:28:42

Lu'!

Ne déclare pas un machin comme ça en C++. Utilise std::array. Mais sinon, il y a ça :

#include <iostream>

template<class T, std::size_t N>
constexpr std::size_t array_size(T(&)[N]){
    return N;
}

int main() {
  int tableau[] { 0,1,2,3,4, };
  std::cout << array_size(tableau) << std::endl;
  //attention valide seulement pour un tableau static
  std::cout << sizeof(tableau)/sizeof(tableau[0]) << std::endl;
  
  return 0;
}

(Si tu te tires une balle dans le pied avec ces machins tu ne diras que tu n'as pas été prévenu).

Fatihldekur a écrit:

Et quel est la taille max d'un tableau d'int?

Sur la pile : pas gros. Sous Windows, la pile c'est quelque chose comme 1Mo au maximum.

Salut,

Ksass`Peuk a écrit:

Sur la pile : pas gros. Sous Windows, la pile c'est quelque chose comme 1Mo au maximum.

Le seul truc, ne vas pas te dire que "1Mo, mais c'est bizance, ca fait à peu près 250 000 int (si tant est qu'ils soient codés sur 4 octests)"..

Car il faut bien penser que ce 1Mo doit déjà contenir un maximum d'informations :  toutes les variable locales de toutes les fonctions qui ont appelé une fonction dont on n'est pas encore sorti + tous les paramètres transmis à ces fonctions + l'adresse mémoire à laquelle retourner une fois que la fonction en cours (non terminée) a fini son job, + ... + ... + ... .

Au final, si tu essayes de mettre ne serait-ce que 100 000 entiers sur la pile (que ce soit sous la forme d'un tableau ou non),  tu risques déjà de la saturer particulièrement vite

Salut et merci pour vos réponses!

koala01 a écrit

Le seul truc, ne vas pas te dire que "1Mo, mais c'est bizance, ca fait à peu près 250 000 int (si tant est qu'ils soient codés sur 4 octests)"..

C'est ce que je me disait 

koala01 a écrit:

Au final, si tu essayes de mettre ne serait-ce que 100 000 entiers sur la pile (que ce soit sous la forme d'un tableau ou non),  tu risques déjà de la saturer particulièrement vite

C'est vraiment dommage, déjà 250000 c'était peu mais alors 100000.. En tous cas merci beaucoup, on avais un problème qu'on arrivais pas à trouver depuis 1 semaine, ça doit être car on essaye de mettre 4 millions de points dans un tableau d'int. Faudra que je change le code pour un std::vector, qui à ce que j'ai vu prendrais mes 4 millions d'int sans problème.

Oh, si tu veux savoir combien de int un std::vector peut contenir au maximum, un code proche de

#include <iostream>
#include <limits>
int main(){
    std::cout<<std::numeric_limits<size_t>::max()/2<<"\n";
    return 0;
}

devrait te donner une idée plus ou moins précise.  Sauf que tu atteindra sans doute d'autres limites, dues à ton système (ta quantité de ram, ta quantité de swap disponible) ou à ton système d'exploitation bien avant d'arriver à ce nombre

En 32 bits tu vas rentrer dans la zone dangereuse aux environs de 300 millions d'int (1.2 Go) au delà de 1.2 Go tu te rapproches grandement de ce que l'OS peut accorder comme ressource mémoire à un processus. En 64 bits ça va craquer beaucoup plus haut, de mémoire, ça va commencer à craindre aux environs de 14/15 Go (A condition bien sûr que la machine ait les reins assez solides pour supporter une telle charge). Mais quoi qu'il en soit pour pouvoir disposer de quantités aussi faramineuses de mémoire, tu dois impérativement avoir recours à de l'allocation dynamique, std::vector fait ça très bien

-
Edité par int21h 23 septembre 2017 à 19:08:47

J'ai réussi a utiliser un std::vector de std::numeric_limits<size_t>::max()/4sous linux 64 bits avec seulement 6Gb de mémoire...

Mais je ne vais pas te parler des performances ni de l'utilisation du swap

Ca dépend du modèle de processus et de l'OS, je sais a peu près ce qu'il en est en 32 bits pour avoir parfois côtoyé les limites. En 64 bits, j'ai lu des trucs où les auteurs disaient que jusqu'à 14/15 Go il n' avait pas trop de problèmes mais au delà ça devenait plus tendu. Il me semble aussi avoir lu qu'en 64 bits Windows Limitait la taille maximale des processus en fonction de la RAM disponible. En 64 bits les limites sont tellement lointaines que ma foi, je n'ai jamais eu ne serait ce que l'occasion de les approcher

En 32 bits j'ai planté GCC en essayant de compiler un bout de programme utilisant chaiscript en debug, tu vois la mémoire monter en flêche jusqu'aux alentours de 1.2 Go puis boum : out of memory.

chaiscript est un truc assez rigolo, c'est un interpréteur pour un langage qui ressemble un peu à javascript qui a la particularité d'être header-only.

-
Edité par int21h 23 septembre 2017 à 20:29:38

En fait, ce qu'il faut retenir, c'est que le simple fait qu'un ordinateur soit un système fini (quantité maximale de mémoire et d'espace de stockage) va forcément poser des limites à l'utilisation des collection dynamique (std::vector, et tous les autres); mais que ces limites sont malgré tout très largement supérieure à ce que l'on utilise classiquement pour la pile d'appels

Sur nos OS modernes, la pile est généreuse, tellement généreuse, qu'on n'en voit généralement jamais le bout. Dans ma spécialité, l'informatique embarquée, il n'en va pas de même, la pile peut être minuscule, j'ai travaillé sur des plateformes où elle faisait 256 octets maximum.

int21h a écrit:

Sur nos OS modernes, la pile est généreuse, tellement généreuse, qu'on n'en voit généralement jamais le bout.

Hummm... c'est pas forcément vrai non plus

Avec Gcc, il est possible de l'augmenter, effectivement, à peu près autant que l'on veut, mais tu as (toujours) des valeurs par défaut qui ne sont pas vraiment énormes

De mémoire, je crois que cela correspond à 4Mb sous linux, à moins encore sous windows

Salut.

La taille max d'un truc sur la pile dépends du système d'exploitation et peut être du compilateur. C'est difficile de te donner une réponse

Si tu fais tes tableaux en mode C avec le code suivant, tu peux avoir des problèmes avec les GROS tableaux (assez gros pour que tu n'aie pas la patience de les écrire à la main.

int A [] = {1,2,3,4,5};

Le plus simple, est de ne pas allouer sur la pile, en utilisant une structure qui gères a ta place l’allocation dynamique, par exemple std::vector.  C'est de toutes manière probablement ce que tu fais déjà, car je ne te vois pas remplir 250 000 entier à la main, pour déclarer le contenu de ton tableau. Tu va plutot lire ce dernier dans un fichier ou un autre truc.


De manière générale, on n'alloue pas de gros objets sur la pile. Quand on a un gros objet de type T a alouer, on fait un std::unique_ptr<T>. La pile contiendra le pointeur, et le pointeras vers les données sur le tas.

Les containers de la STL font tous (sauf peut être std::array pour lequel j'en sais rien), ça pour toi : ils contiennent un ou des pointeurs vers les données sur le tas.

-
Edité par ledemonboiteux 26 septembre 2017 à 17:20:57

Il me semble que le std::array<int, SIZE> alloue sur la pile , j'avais eu un problème il y a quelques temps avec pas mal de std::array d'entiers et ma pile avais explosé. Mon programme tournait bien sous Ubuntu (14 ou 16 je ne me rappelle plus) et Windows 10 , mais pas sous Windows XP.

Voici le lien de mon post : https://openclassrooms.com/forum/sujet/memoire-et-pile?page=1#message-91092745

Et effectivement, mes std::array étaient remplis en lisant des fichiers.