Version imprimable
@3DArchi, tu l'appelles depuis VC++ ? En passant par les hotkeys usuelles ?
libstdc++ de GNU: COWCitation:
Envoyé par Klaim
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
Depuis l'invité DOS si tes chemins d'accès sont dans le PATH.Citation:
Envoyé par Luc Hermitte
OK, c'est bien ça. Cela ne se fait pas depuis VC++, mais depuis DOS, voire vim, comme d'habitude...
Voyons messieux, il y a longtemps que ce n'est plus DOS derrière, c'est juste une invite de comande :aie:
Les papys, ils parlent encore en DOS et en anciens francs :mouarf:
@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)
Dans Visual C++, dans le menu Outils, il y a Invite de commandes.Citation:
Envoyé par Luc Hermitte
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.Citation:
Envoyé par oodini
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.
Pourquoi selon toi la norme ne devrait-elle pas parler d'implémentation ?Citation:
Envoyé par pyros
C'est tabou, dans une norme ? C'est sale ? :-)
libcxx => SSO.Citation:
Envoyé par Luc Hermitte
libstdc++ en 0x : SSO (le CoW étant interdit ...)
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 :Citation:
Envoyé par pyros
Emphasis is mine, comme dirais les habitants de la Grosse Pomme.Citation:
Envoyé par n3242, 23.3.6.1§1
L'implémentation, c'est la mise en oeuvre d'une définition dans les limites offertes par le système cible.Citation:
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.
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.Citation:
Envoyé par oodini
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).
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.Citation:
Envoyé par 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.Citation:
Envoyé par Emmanuel Deloget
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.Citation:
Envoyé par oodini
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).
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.Citation:
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).
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.Citation:
Envoyé par loufoque
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.
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.
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.
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é.Citation:
Envoyé par loufoque
La fonction d'allocation est définie par :
Avec le texte :Code:pointer allocate(size_type, allocator<void>::const_pointer hint = 0);
Citation:
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.
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.Citation:
Envoyé par loufoque
Après, tu es libre de faire partir la discussion ou tu veux - elle est déjà suffisamment éloignée du port d'origine :)