Discussion :

[oodini]

Bonjour,

J'aimerais créer un vecteur, qui ne sera rempli qu'à un seul moment, juste après sa création, avec un nombre d'élément connu à l'avance.

Je veux que son occupation mémoire soit minimale et prévisible.

Quand j'utilise reserve() avec des valeurs différentes (mais proches), un sizeof() me donne une taille identique. Le travail fait par l'allocateur standard semble donc ne pas me convenir.

J'ai du mal à trouver de la bonne littérature sur le sujet. Auriez-vous une site à me recommander, ou des pistes à me donner ?

Merci.

[Klaim]

sizeof() te donne la taille du vector lui meme, pas des objets qu'il gere... (si ce point n'est pas clair, dis le qu'on te dirige vers un diagram pour que ce soit plus clair, j'en ai pas sous la main).

utilise monvector.size() pour le nombre d'objets crees "vivants", et monvector.capacity() pour savoir le nombre d'objets alloues en memoire en tout (donc size() <= capacity() ).

Quand tu fais reserve(), tu change capacity() seulement si ton reserve alloue plus que la capacitee de depart.

Une fois fais ton reserve, comme tu le pensais, ca marchera pour peu que tu n'ajoutes pas plus d'elements que reserves.

[koala01]

Salut,

Une petite précision encore (bien que tu l'auras surement compris ):

Tant size() que capacity() renverront le nombre d'éléments correspondant, et non la taille que cela représente en mémoire.

En outre, si tu lances sizeof sur un std::vector<n'importe quel type>, la valeur que tu obtiens, c'est la taille nécessaire à la représentation d'un std::vector en mémoire, et cette taille sera effectivement toujours identique, parce que les données sont représentée sous la forme d'un pointeur vers le type indiqué (et tout le monde sait bien maintenant que la taille d'un pointeur est clairement et définitivement définie, quel que soit le type pointé )

[gbdivers]

Bonjour

Petite précision sur Allocator : son rôle est de gérer l'allocation mémoire de chaque élément, pas de gérer la politique de redimensionnement des conteneurs.
Le redimenssionnement est implémentation dépendant (bien qu'il me semble que resize va allouer que le nécessaire)

Si tu veux un tableau de taille fixé à l'exécution, tu peux regarder l'implémentation de dynarray ? (C++14)

[oodini]

Bonjour à tous.

Désolé pour l'évocation de sizeof(). Je pensais "taille", et ma pensée a emprunté des raccourcis ô combien contestables (pas dans l'expression de ma question : au moment où je l'ai posée, j'avais effectivement en tête que le sizeof donnait la taille complète ; je devais être fatigué...).

À vrai dire, j'ai posé cette question car je travaille sur les vecteurs de Boost::Interprocess, et j'essaye de satisfaire les exigences mentionnées quant à la taille. J'en avais conclu qu'il fallait que j'attaque les allocateurs, et j'ai posé une question sur les allocateurs standard, car il faudrait d'abord que je comprenne ceux-là avant de m'attaquer à ceux de Boost::Interprocess. Et l'intervention de gbdivers me laisse penser que je partais sur une mauvaise poste. Je pensais que c'était l'allocateur qui gérait le redimensionnement.

Cela dit, si vous avez des didacticiels sur les allocateurs, je suis preneur. Cela manque dans ma culture.

[camboui]

Cela dit, si vous avez des didacticiels sur les allocateurs, je suis preneur. Cela manque dans ma culture.

+1
Curieux aussi de voir des allocateurs atypiques, comme par exemple un allocateur qui fragmente un std::vector en segments de taille réduite, qui fait usage explicite de la mémoire de masse (disque dur, ssd), etc.

[therwald]

qui fragmente un std::vector en segments de taille réduite, qui fait usage explicite de la mémoire de masse (disque dur, ssd), etc.

N'est il pas conçu pour NE PAS faire ça?

Just like arrays, vectors use contiguous storage locations for their elements, which means that their elements can also be accessed using offsets on regular pointers to its elements, and just as efficiently as in arrays. But unlike arrays, their size can change dynamically, with their storage being handled automatically by the container.

[camboui]

La "mémoire" est conceptuellement contigüe pour std::vector<>, oui.

Mais std::vector<> utilise std::allocator<> et non pas new[] ni alloc() ni malloc() ni calloc(). Un allocator n'est pas tenu à une quelconque obligation d'implémentation, juste une obligation d'interface publique.

D'ailleurs, alloc()/new[] ne garantit pas un bloc mémoire physique contigüe de la part de l'OS, le commit n'est pas nécessairement immédiat et complet. Il garantit simplement des adresses contigües dans un bloc de mémoire virtuelle.

Ou alors j'ai rien compris et std::allocator n'est qu'un gros chatouillage pour ne pas utiliser directement new[].
Et je sens que je vais me faire remonter les bretelles

[JolyLoic]

Hop hop hop, par ici les bretelles !

Quand on demande à un allocateur d'allouer de la mémoire (par allocate), on lui demande de le faire pour n objets, et il retourne un seul pointeur. Comment pourrait-il faire pour ne pas allouer de la mémoire contigüe dans ce cas ?

L'objectif des allocateurs (le débat de savoir si cet objectif compense leur coût n'est pas totalement clos), c'est généralement de permettre deux choses différentes :
- Allouer de la mémoire plus vite, grâce à une connaissance spécifique du cas d'utilisation en cours : Par exemple allouer sur la pile (si la taille est faible, et la durée de vie limitée), allouer sans lock pour le multithread (si le programme n'a qu'un thread), allouer dans un pool spécialisé (si on a plein d'objets de la même taille)...
- Allouer de la mémoire autrement (fonctions spécifiques à l'OS pour accéder à de la mémoire partagée, pour allouer dans des zones particulières).

[Klaim]

Dites moi si j'ai tort mais il me semble que l'allocateur par défaut dans la bibliothèque standard il fait "seulement" new et delete et pas plus (d'ailleurs il est stateless). C'est l’implémentation de new et delete qui sont "optimises" pour les cas généraux par l’implémentation fournie par les compilateurs...

Les allocateurs qui font des trucs plus spécifiques (pool etc.) pour l'instant il n'y en a pas dans la bibliothèque standard mais il me semble qu'il y a des propositions pour en ajouter pas mal d’intéressants.

[JolyLoic]

C'est bien le cas pour l'allocateur standard.
Pour ce qui est de fournir d'autres allocateurs, je pense que ce n'est pas encore pour demain, la proposition à Bristol ayant été reçue un peu froidement par les promoteurs même des allocateurs (principalement bloomberg). Le plan pour la suite est que John Lakos (principal promoteur des allocateurs) travaille avec l'auteur de cette proposition pour revenir sur le sujet à une prochaine réunion.

[Klaim]

Est-ce que tu te souviens de ce qui les avait refroidis? L'implementation ou le choix des strategies d'allocations? Parceque yen a pas mal qui collent a ce que j'ai vu jusqu'ici dans pas mal de boite. (meme chose pour la proposition concernant les assertions et le controle des erreurs).

[JolyLoic]

De mémoire, le fait que la formulation n'était pas prête pour être intégrée, des doutes quant aux allocateurs choisis, la difficulté de spécifier ce genre de choses, le manque de guidelines pour savoir quel allocateur utiliser quand des doutes sur les noms des différents allocateurs.

Globalement, rien de bien bloquant mais une somme de petites choses qui ont fait dire "plus tard".

[camboui]

Mais donc ils existent.
Vous pouvez nous montrer concrêtement où se trouve le code de ces allocators ?
Merci.

[Klaim]

Mais donc ils existent.
Vous pouvez nous montrer concrêtement où se trouve le code de ces allocators ?
Merci.

Ils existent mais ne sont pas du tout officiels...
Et je n'arrive pas a retrouver le document en question mais il me semble qu'ils en parlaient sur la mailing list isocpp. Pas sur qu'il y ait le code complet, certainement juste l'interface.

Si tu cherches des allocateurs pool il y en a dans boost mais je sais pas si ils sont bon, il y a eu beaucoup de problemes avec boost pool.

[JolyLoic]

Peut-être que tu trouveras plus d'exemples sur : https://github.com/bloomberg/bsl/wik...llocator-Model

C'est le site où bloomberg (le grand promoteur des allocateurs) publie des choses.

Sinon, le papier discuté à Bristol était le http://www.open-std.org/jtc1/sc22/wg...013/n3575.html