Conflit avec "remove()"

Bonjour à tous !

Je travaille sous C++Builder 6 (10.161), et je rencontre un petit problème avec la fonction remove : en effet, il existe deux fonctions portant ce nom dans le namespace std.

La première,

Code:

---

int remove(const char *)

---

, dans cstdio (pour supprimer un fichier) ; la deuxième,

Code:

---

1 2 3

template <class ForwardIterator, class T> ForwardIterator remove(ForwardIterator first, ForwardIterator last, const T& value);

---

, dans algorithm (pour enlever des élèments d'un container, ou plutôt pour les déplacer en fin de container). Or, lorsque je souhaite utiliser la fonction template, j'obtiens une erreur du compilateur, indiquant qu'il ne sélectionne pas la bonne fonction. Est-ce normal d'avoir un tel conflit ?! 8O

Voici un code minimal qui ne compile pas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <algorithm> #include <cstdio> #include <vector>   int main() { std::vector<int> v;   v.push_back(3); v.push_back(2); v.push_back(5);   v.erase(std::remove(v.begin(), v.end(), 2), v.end());   return 0; }

---

Et l'erreur qu'il donne :

Citation:

---

[C++ Erreur] test_remove.cpp(13): E2034 Impossible de convertir 'int *' en 'const char *'
[C++ Erreur] test_remove.cpp(13): E2342 Mauvaise correspondance de type dans le paramètre '__path' ('const char *' désiré, 'int *' obtenu)
[C++ Erreur] test_remove.cpp(13): E2227 Paramètre supplémentaire dans l'appel à std::remove(const char *)
[C++ Erreur] test_remove.cpp(13): E2285 Impossible de trouver une correspondance pour '_STL::vector<int,_STL::allocator<int> >::erase(int,int *)'

---

Si quelqu'un a déjà rencontré cette erreur, ou sait à quoi elle est dûe...

Edit : J'ai essayé de compiler ce même code sous code::blocks, et il n'y a aucun problème...dois-je en déduire que c'est le compilateur borland qui fait des siennes ?

Citation:

---

Edit : J'ai essayé de compiler ce même code sous code::blocks, et il n'y a aucun problème...dois-je en déduire que c'est le compilateur borland qui fait des siennes ?

---

Possible, en tout cas ce bout de code semble tout à fait correct. Autre solution : inclure <stdio.h>, ainsi remove(const char*) ne sera pas dans le namespace std.

Citation:

---

Envoyé par Laurent Gomila

Autre solution : inclure <stdio.h>, ainsi remove(const char*) ne sera pas dans le namespace std.

---

Non, avec les formes xxx.h, les noms sont definis dans le namespace std et importes dans le namespace global.

J'ai essayé ta solution, mais ça n'a rien changé. Je suis aller voir dans stdio.h, et il utilise lui aussi le namespace std :

Code:

---

1 2 3 4

#ifdef __cplusplus namespace std { #endif /* __cplusplus */

---

Tout cela est tout de même bizarre :aie: !

Est-ce que remove est bien défini dans <algorithm>? Et comment? Fait attention aux macros et a la compilation conditionnelle.

Et bien, le fichier <algorithm> contient les inclusions conditionnelles suivantes :

Code:

---

1 2 3 4 5

#ifdef _USE_OLD_RW_STL # include <oldstl\algorith.h> #else # include <stlport\algorithm> #endif

---

ainsi qu'un export dans le namespace global (si je ne m'abuse), mais qui n'est à priori pas effectué :

Code:

---

1 2 3

#if !defined(__USING_STD_NAMES__) && defined(__cplusplus) using namespace std; #endif /* __USING_STD_NAMES__ */

---

Normalement, c'est le fichier <stlport\algorithm> qui est inclus, et il contient entre autres les lignes suivantes, avant d'inclure <stl/algo.h> :

Code:

---

1 2 3 4

# if ! defined (_STLP_USE_NAMESPACES) // remove() conflicts, <cstdio> should always go first # include <cstdio> # endif

---

Donc j'en déduis que normalement, le conflit ne devrait pas se présenter lorsque <cstdio> est inclus avant <algorithm>, mais ce n'est pas vraiment le cas...

Quant à remove, il est bien défini dans <_algo.h>, de la façon suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template <class _ForwardIter, class _Tp> _STLP_INLINE_LOOP _ForwardIter remove(_ForwardIter __first, _ForwardIter __last, const _Tp& __value) { _STLP_DEBUG_CHECK(__check_range(__first, __last)) __first = find(__first, __last, __value); if (__first == __last) return __first; else { _ForwardIter __next = __first; return remove_copy(++__next, __last, __first, __value); } }

---

J'ai trouvé une explication sur un autre forum :

Citation:

---

Found a bug report. Apparently this arrises because parts of RogueWare's implementation is used. STLPort actually uses the _STL namespace which is aliased as stlport and _STLP_STD. So it resolves stlport::remove just fine, but std::remove resolves to the only remove actually in the std namespace. _STL is in std as well by a using, but apparently that causes the remove actually in std to be selected.

---

Et effectivement, en utilisant stlport::remove, je n'ai plus de problèmes. Mais alors mon code n'est plus portable :cry: .

Edit : Voici la solution donné par borland namespace resolution is failing. Ils conseillent d'utiliser remove_if ou de revenir à la l'implémentation de Rogue Wave plutôt que la stlport...

Code:

---

1 2 3

namespace std { using namespace stlport; }

---

peut etre plus facilement inclu quelque part dans une gestion de chose specifiques a l'implementation.

Et bien en fait, la solution que tu donnes est déjà mise en place par borland : ils exportent effectivement le namespace stlport dans std. Mais apparemment, un bug du compilateur fait que la version de remove retenue est celle qui est "vraiment" présente dans std (autrement dit celle de cstdio), et pas celle qui est importée (voir le lien que j'ai donné dans mon post précédent).

OK, J'avais mal compris.

Pour information, la condition de compilation pour utiliser Rogue Wave et pas stlport est _USE_OLD_RW_STL (par contre attention, ce changement d'implémentation peut faire apparaître des erreurs que vous n'aviez pas avant :mur:).

Comme expliqué, il faut utiliser std::remove_if
donc le code devient...

Code:

---

v.erase(std::remove_if(v.begin(), v.end(), bind2nd(equal_to<int>(), 2)), v.end());

---