Discussion :

[Luc Hermitte]

@3DArchi, tu l'appelles depuis VC++ ? En passant par les hotkeys usuelles ?

[taille des chaines qui varie]
Il me semble avoir lu quelque part que ce n'est plus vrai, mais ça mériterai vérification.

libstdc++ de GNU: COW
STLport: string concatainator (par expression template) -> interface non conforme au standard (même si c'est probablement l'implémentation la plus intelligente); probablement du COW derrière, j'avoue avoir oublié.
dinkumware: small-string optimization

[3DArchi]

@3DArchi, tu l'appelles depuis VC++ ? En passant par les hotkeys usuelles ?

Depuis l'invité DOS si tes chemins d'accès sont dans le PATH.

[Luc Hermitte]

OK, c'est bien ça. Cela ne se fait pas depuis VC++, mais depuis DOS, voire vim, comme d'habitude...

[Klaim]

Voyons messieux, il y a longtemps que ce n'est plus DOS derrière, c'est juste une invite de comande

[3DArchi]

Les papys, ils parlent encore en DOS et en anciens francs

@Luc : à la limite, rien ne t'empêche de rajouter dans "Tools" un appel vers cl pour ne pas avoir à faire de projet (ou un bat s'il y a d'autres flags à positionner)

[oodini]

OK, c'est bien ça. Cela ne se fait pas depuis VC++, mais depuis DOS, voire vim, comme d'habitude...

Dans Visual C++, dans le menu Outils, il y a Invite de commandes.

[pyros]

Quand tu dois interagir avec une bibliothèque C, c'est loin d'être un détail.

Justement, ce que je voulait dire au début (mais je me suis un peu perdu en route), c'est que le principe de l'encapsulation "parfaite", la grosse boite noir où l’intérieur est totalement masqué, ne peut pas toujours marcher.
Malgré que les vecor soit une manière de s'affranchir de tout ce qui est gestion mémoire, pointeurs, etc... arrive un moment où on doit bien faire avec et où il faut un petit hublot à la boite noir (en l'imposant dans la norme si nécessaire). Malgré une interface haut niveau qui nous simplifie le travail, savoir ce qu'il se passe à plus bas niveau est parfois indispensable.

Après, il y a peut être un problème de vocabulaire quant au terme "implémentation". On peu considérer que, si c'est dans la norme, alors ce n'est pas de l'implémentation (car justement, on ne peut pas l'implémenter comme on le souhaite). Mais on peut aussi considérer (comme moi) que l'implémentation concerne tout ce qui n'est pas purement "théorique", tout ce qui relève de considération bassement matérialiste comme le fait que nos machines n'ont pas une mémoire infinie.

[oodini]

Après, il y a peut être un problème de vocabulaire quant au terme "implémentation". On peu considérer que, si c'est dans la norme, alors ce n'est pas de l'implémentation (car justement, on ne peut pas l'implémenter comme on le souhaite).

Pourquoi selon toi la norme ne devrait-elle pas parler d'implémentation ?
C'est tabou, dans une norme ? C'est sale ? :-)

[Goten]

@3DArchi, tu l'appelles depuis VC++ ? En passant par les hotkeys usuelles ?


libstdc++ de GNU: COW
STLport: string concatainator (par expression template) -> interface non conforme au standard (même si c'est probablement l'implémentation la plus intelligente); probablement du COW derrière, j'avoue avoir oublié.
dinkumware: small-string optimization

libcxx => SSO.

libstdc++ en 0x : SSO (le CoW étant interdit ...)

[Emmanuel Deloget]

Mais savoir que les éléments d'un vector sont stockés contigüe en mémoire est un détail d'implémentation.

Non (enfin, c'est un mauvais exemple). La contiguité des éléments d'un conteneur de type vector<T> est garantie par la norme C++. Si cette garantie était implicite dans le standard de 98, elle est maintenant explicite :

A vector is a sequence container that supports random access iterators. In addition, it supports (amortized) constant time insert and erase operations at the end; insert and erase in the middle take linear time. Storage management is handled automatically, though hints can be given to improve efficiency. The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().

Emphasis is mine, comme dirais les habitants de la Grosse Pomme.

Mais on peut aussi considérer (comme moi) que l'implémentation concerne tout ce qui n'est pas purement "théorique", tout ce qui relève de considération bassement matérialiste comme le fait que nos machines n'ont pas une mémoire infinie.

L'implémentation, c'est la mise en oeuvre d'une définition dans les limites offertes par le système cible.

Pourquoi selon toi la norme ne devrait-elle pas parler d'implémentation ?
C'est tabou, dans une norme ? C'est sale ? :-)

Non, ce n'est pas sale, c'est juste hors cadre : la norme (C++) définit un contrat (interfaces, complexité des algorithmes, entrées et sortie des fonctions, ABI, etc) ; l'implémentation doit respecter ce contrat, mais en dehors de ça, elle est libre.

Du coup, elle ne parle pas d'implémentation - parce que ça n'est pas son rôle, pas parce que c'est sale. D'autres normes définissent non seulement une interface mais aussi l'implémentation liée à cette interface - généralement sous la forme d'algorithmes.

La raison pour laquelle parler d'implémentation est hors scope du standard C++ est simple : en standardisant une manière d'implémenter, on s'interdit toute évolution future de cette implémentation tant que le standard ne change pas. Hors, une optimisation particulière peut rendre obsolète une implémentation très rapidement (tant de choses ont été découverte dans le C++ après la standardisation de celui-ci).

[3DArchi]

La raison pour laquelle parler d'implémentation est hors scope du standard C++ est simple : en standardisant une manière d'implémenter, on s'interdit toute évolution future de cette implémentation tant que le standard ne change pas.

et on s'interdit une hétérogénéité d'implémentation liée à des spécificités des plateformes cibles voir même on les rend impossibles.

[oodini]

Non, ce n'est pas sale, c'est juste hors cadre : la norme (C++) définit un contrat (interfaces, complexité des algorithmes, entrées et sortie des fonctions, ABI, etc) ; l'implémentation doit respecter ce contrat, mais en dehors de ça, elle est libre.

Du coup, elle ne parle pas d'implémentation - parce que ça n'est pas son rôle, pas parce que c'est sale. D'autres normes définissent non seulement une interface mais aussi l'implémentation liée à cette interface - généralement sous la forme d'algorithmes.

Ben, d'après ce que tu cites plus haut, elle parle également d'implémentation, même si ça égratigne la philosophie initiale.

[Emmanuel Deloget]

Ben, d'après ce que tu cites plus haut, elle parle également d'implémentation, même si ça égratigne la philosophie initiale.

Non, le fait de préciser que les éléments d'un vecteur sont contigus fait parti du contrat. La norme ne précise pas le moyen que doit utiliser le vendeur de compilateur pour arriver à ce résultat, juste que la relation &v[n] == &v[0] + n doit être vraie (dans les limites des conditions posées). Nous n'imaginons à l'heure actuelle qu'un moyen unique d'arriver à cette solution - celle d'allouer un bloc de mémoire contigu. Mais nous manquons un peu d'imagination.

Personnellement, j'imagine sans peine un système proposant un accès à une MMU virtuelle permettant de concaténer dans un superbloc de mémoire virtuelle des blocs de mémoire alloués au préalable et non contigus. Ca permettrait d'implémenter l'élargissement d'un std::vector<> sans faire une seule copie (j'alloue un bloc supplémentaire, et je dis à ma MMU virtuelle que ce bloc est contigu à mon superbloc).

(ce qui est étonnant, c'est que je suis en train d'écrire un article qui parle de notre manière de raisonner par inférence, et que tu as utiliser cette manière de raisonner à l'instant : ce n'est pas parce qu'on précise que les éléments d'un vecteur sont contigus qu'il n'existe qu'une seule manière d'arriver à ce résultat, même si on n'arrive pas nécessairement à imaginer une autre manière de le faire).

[loufoque]

Personnellement, j'imagine sans peine un système proposant un accès à une MMU virtuelle permettant de concaténer dans un superbloc de mémoire virtuelle des blocs de mémoire alloués au préalable et non contigus. Ca permettrait d'implémenter l'élargissement d'un std::vector<> sans faire une seule copie (j'alloue un bloc supplémentaire, et je dis à ma MMU virtuelle que ce bloc est contigu à mon superbloc).

Cette implémentation n'est a priori pas réalisable car std::vector doit utiliser l'allocateur fourni, qui ne permet pas de mapper des pages mémoire.

[Emmanuel Deloget]

Cette implémentation n'est a priori pas réalisable car std::vector doit utiliser l'allocateur fourni, qui ne permet pas de mapper des pages mémoire.

C'est de toute façon le rôle de l'allocateur de jouer avec la mémoire. Une implémentation particulière de l'allocateur par défaut peut, si besoin, effectuer l'opération que j'ai décrit en utilisant le paramètre hint - il est là pour ça.

Je ne vais pas prendre ce soir le temps de relire toutes les parties nécessaires du standard, mais à mon humble avis, celui-ci offre des possibilités pour implémenter un système de gestion de la mémoire qui est plus intéressant (pour l'embarqué, notamment) que les implémentation génériques qu'on utilise à l'heure actuelle.

[Joel F]

la maniere dont tu presentais la chose semblait donner cette responsabilité a vector.

Rien ne t'empeche de faire std::vector<T, mmu_allcoator<T> > effectivement.

[loufoque]

Ce n'est pas possible. Allocator aurait besoin de supporter l'agrandissement en-place pour que ce le soit.

Tout ce que permet l'allocateur, c'est d'allouer un objet et de donner le pointeur vers celui-ci ou de libérer des objets précédemment alloués. Il n'y a aucun moyen pour l'allocateur de savoir qu'il peut mapper un segment de mémoire libre à la fin d'un bloc pour l'étendre.

Ce que fait vector, quand il agrandit, c'est allouer un bloc plus gros et recopier (ou déplacer en C++0x). À aucun moment il y a la moindre opportunité de faire quelque chose d'intelligent. Il n'y a pas de fonction "alloue à cette adresse" dans l'allocateur, et une telle abstraction n'aurait d'ailleurs pas de sens car elle nécessiterait forcément une MMU.

Des extensions pour rajouter l'agrandissement en-place dans les allocateurs ont été suggérées, cependant.

[Emmanuel Deloget]

Ce n'est pas possible. Allocator aurait besoin de supporter l'agrandissement en-place pour que ce le soit.

Tout ce que permet l'allocateur, c'est d'allouer un objet et de donner le pointeur vers celui-ci ou de libérer des objets précédemment alloués. Il n'y a aucun moyen pour l'allocateur de savoir qu'il peut mapper un segment de mémoire libre à la fin d'un bloc pour l'étendre.

Si, en utilisant le paramètre hint de la fonction qui effectue l'allocation. Ce paramètre, tel que le spécifie la norme, peut être utilisé pour passer un pointeur - par exemple l'adresse virtuelle du segment de mémoire déjà alloué.

La fonction d'allocation est définie par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pointer allocate(size_type, allocator<void>::const_pointer hint = 0);

Avec le texte :

hint either 0 or previously obtained from member allocate and not yet passed to member deallocate. The value hint may be used by an implementation to help improve performance.

Remark: the storage is obtained by calling ::operator new(std::size_t), but it is unspecified when or how often this function is called. The use of hint is unspecified, but intended as an aid to locality if an implementation so desire.

[loufoque]

Imaginons que tu décides de donner comme sémantique à ton allocateur de faire l'allocation à l'adresse passée dans hint (ce qui n'est absolument pas pour ça que le hint existe, il existe pour accélérer la recherche d'un élément libre dans un arbre éventuel qui servirait à gérer le tas mémoire).

Il n'empêche que vector ne peut toujours pas utiliser ça pour faire de l'extension en-place.

[Emmanuel Deloget]

Imaginons que tu décides de donner comme sémantique à ton allocateur de faire l'allocation à l'adresse passée dans hint (ce qui n'est absolument pas pour ça que le hint existe, il existe pour accélérer la recherche d'un élément libre dans un arbre éventuel qui servirait à gérer le tas mémoire).

Il n'empêche que vector ne peut toujours pas utiliser ça pour faire de l'extension en-place.

Je comprends ton point de vue. Ceci dit, je ne parle pas de faire de l'extension in-place dans le vecteur de manière générale, je parle d'une architecture matérielle spécifique où un telle option pourrait être implémentée, sans pour autant contredire le standard. C'était une manière de rappeler que le standard ne force aucune implémentation, même lorsqu'il semble qu'il le fasse.

Après, tu es libre de faire partir la discussion ou tu veux - elle est déjà suffisamment éloignée du port d'origine