Bonjour à tous,
les auto_ptr se chargent de libérer la mémoire associée au pointeur qui leur a été confié, ce qui est tout à leur honneur. Mais qu'en est-il dans le cas suivant ?Code:
1
2 auto_ptr< int > ap( new int[ 5 ] );
Version imprimable
Bonjour à tous,
les auto_ptr se chargent de libérer la mémoire associée au pointeur qui leur a été confié, ce qui est tout à leur honneur. Mais qu'en est-il dans le cas suivant ?Code:
1
2 auto_ptr< int > ap( new int[ 5 ] );
Comportement indéfini, puisque cela va appeler delete sur un tableau. std::auto_ptr n'est adapté qu'aux objets, pour les tableaux c'est std::vector.
Code:std::vector<int> ap(5);
Pour l'auto_ptr, c'est un peu ce que je craignais. Bon, ce n'est pas bien grave, mais merci pour la confirmation. Je vais peut-être me bricoler un autoArrayPtr, pour la forme 8)
En ce qui concerne le vector, l'équivalence n'est tout de même pas parfaite puisque la libération de la mémoire allouée aux pointeurs n'est pas prise en charge, je crois.
Ce serait à peu près inutile. Au pire tu as toujours boost::shared_ptr, pour lequel tu peux spécifier la méthode de destruction. Mais ce ne sera pas adapté aux tableaux (pas de redimensionnement, ajout, ...).Citation:
Pour l'auto_ptr, c'est un peu ce que je craignais. Bon, ce n'est pas bien grave, mais merci pour la confirmation. Je vais peut-être me bricoler un autoArrayPtr, pour la forme
Bien sûr que si, c'est le principal intérêt.Citation:
En ce qui concerne le vector, l'équivalence n'est tout de même pas parfaite puisque la libération de la mémoire allouée aux pointeurs n'est pas prise en charge, je crois
Ha oui, pardon. J'étais resté sur mes histoires de pointeurs et j'avais zappé le int du vector. Une petite pause s'impose... :?Citation:
Bien sûr que si, c'est le principal intérêt.Citation:
En ce qui concerne le vector, l'équivalence n'est tout de même pas parfaite puisque la libération de la mémoire allouée aux pointeurs n'est pas prise en charge, je crois
Quant à boost, j'aimerais bien tester ne serait-ce que leurs classes pour les regex. Mais là où je suis, ils n'utilisent même pas la STL. Préfèrent les conteneurs de Micro$oft. Alors... :cry:
???????? Pardon ?
Tu utilises quel compilateur pour raconter des trucs comme ça ?
Boost n'utilise que le standard du C++, donc la STL. Je les vois mal utiliser l'implémentation de Microsoft de la STL pour GCC...
Je pense qu'il veut parler des conteneurs des MFC : CMap, CArray, CList, etc..
Je suppose également que le "ils" ne désignait pas les auteurs de boost, mais les collègues/supérieurs de Herode...
Voui. La phrase était mal tournée, autant pour moi... :sm:
Ou j'aurai dû mieux lire ;)
En plus, si ça se trouve, les CLists et autres sont basés sur les conteneur STLs de Microsoft, non ?
Aucune chance.
En effet. Les interfaces et la structure ne sont pas du tout les mêmes. Planquer la STL sous une couche aussi... épaisse, ça relèverait de la perversion 8)