MSVC 7.1 : erreur C1001, ligne 2701

J'ai une belle erreur de compilation sous MSVC 2003/7.1
J'ai trouvé une explication, mais je ne trouve pas comment réparer mon code.
Voici l'explication : http://www.thescripts.com/forum/thread264827.html

Donc maintenant, la déclaration de la fonction template :

Code:

---

1 2

template<template <class, unsigned int, unsigned int> class MatrixType, class DataType, unsigned int Height, unsigned int Width, unsigned otherHeight, unsigned otherWidth> const typename MatrixType<bool, (Height == 0 ? otherHeight : Height), (Width == 0 ? otherWidth : Width)>::ComparisonResult operator==(const MatrixType<DataType, Height, Width>& lhs, const MatrixType<DataType, otherHeight, otherWidth>& rhs)

---

Je pensais avoir mis les bons arguments à la fonction, mais peut-être pas...
Ce code compile sans pb avec GCC4.1, et ce n'est que ce soir que j'ai essayé de remettre à jour la version Windows...
Je pense que c'est là car l'erreur de compilation est à une ligne qui utilise cette fonction, et c'est la seule opération - un if -, mais même avec l'aide, je n'arrive pas à savoir comment virer cette erreur.
Je ne suis pas trop chaud pour remettre l'opérateur dans une classe, acr il faudrait que je l'implémente dans pas mal de classes qui ont la même gueule que celle-ci.

Bon, apparemment, c'est typique du 7.1 parce que le 8 ne bronche pas... En même temps, maintenant, le 8 n'est même plus capable de résoudre des boost::bind que le 7.1 résolvait :aie: :aie: :aie: :aie: :aie:
N'emp^che que ça ne m'explique pas le problème du 7.1 avec mon code !

Tu ne dis pas d'où vient ton problème exactement.
-du template template parametre?
-de la déclaration de ta fonction?

Tu veux bien écrire un programme minimum et je te le testerai sur mon compilateur (ICL: Intel C++ for Windows).
Ca peut valoir le coup de compiler avec VC 2005 Express, j'ai l'impression très nette que microsoft a rattrappé une bonne partie de son retard en ce qui concerne la conformité au standard.

Au cas ou ton problème vient du "template template", je sais que GCC outrepasse le standard (en bien d'après moi). J'ai eu à ce sujet des problèmes avec ICL, qui ne voulait pas anticiper la norme.

Effectivement, je n'ai pas été assez clair ;)
En fait le compilo rend l'âme au moment de l'instanciation de la fonction. Dans quand j'ai eu mon

Code:

---

if(lhs == rhs)

---

le compilo a cessé de fonctionner :|

L'erreur ne vient que du compilateur MSVC7.1, les autres passent sans problème avec ce code, c'est apparemment presque connu comme erreur, mais je n'ai pas eu de solution. Quant à essayer un programme minimaliste, je vais essayer, mais je ne promets rien. MAis vraimenr rien :aie: vu les centaines de lignes de code de la bibliothèque - t'en sais quelque chose avec ta bibliothèque matricielle :D -

Merci pour ta réponse :)

A 1ère vue c'est peut-être dû à ton paramètre template calculé (j'ai encore jamains utilisé cet opérateur dans un template). Je vois pas pourquoi le reste ne marcherait pas, même sur VC7.1

Citation:

---

Height == 0 ? otherHeight:Height

---

J'ai déjà utilisé la technique consistant à utiliser des "classes meta", du genre

Code:

---

1 2 3 4 5 6

template<int cond,class A, class B> struct IF {}; template<class A,class B> struct IF<0, A, B> { typedef B RET; }; template<class A,class B> struct IF<1, A, B> { typedef A RET; }; template<int m,int n> struct LOWER { enum { RET=(m<n)?1:0 }; }; template<int m,int n> struct GREATER { enum { RET=(m>n)?1:0 }; };

---

Tu pourrais essayer de faire une classe pour l'opérateur "?:" et de l'utiliser comme suit:

Code:

---

1 2 3 4

template<int cond,int a,int b> struct QUESTION_MARK { enum { RET=(cond)?a:b }; };   MatrixType<QUESTION_MARK<...>::RET>

---

Effectivement, pour ces calculs un peu répétitifs de choix du paramètre, je pourrai utiliser un enum. Je vais vérifier si ça vient de ça, mais je ne crois pas :| J'ai vu d'autres opérations plus farfelues que celle-ci :|
C'est vraiment une spécificité MSVC7.1 cette erreur.

Citation:

---

C'est vraiment une spécificité MSVC7.1 cette erreur.

---

Malheureusement pas la seule

En même temps, il m'a mis des warnings là où GCC passait sans broncher, et à tord...
Bon, je teste.

T'avais raison... Il n'aime pas mes <?:>... Va falloir tout remplacer et prendre un enum...

Citation:

---

En même temps, il m'a mis des warnings là où GCC passait sans broncher, et à tord...

---

Lesquels, j'ai toujours trouvé les warnings de VC ou d'autres compilos pertinants.
VC8 Express m'a renvoyé 4-5 nouveaux types de warnings que j'avais encore jamais vu, ils sont un peu tirés par les cheveux, mais ils y en a plusieurs centaines: et donc j'ai mis un petit pragma pour l'instant.
Y'en a même un qui teste la compitibilité future pour une machine 64 bits. (problème pour la conversion de size_t en int avec la STL de microsoft car size_t est déclaré visiblement avec une extension microsoft)

Citation:

---

T'avais raison... Il n'aime pas mes <?:>... Va falloir tout remplacer et prendre un enum...

---

Il y a que les déclarations de fonctions à changer et pas les appels, ce qui devrait déjà sérieusement limiter le volume des changements.

Une macro du genre peut sérieusement simplifier la lecture:

Code:

---

1 2	#define IF_IS_EQUAL(l,r,ret1,ret2) QUESTION_MARK<IS_EQUAL<l,r>::RET,ret1,ret2>::RET

---

Punaise, faut que je fasse à gaffe à ce que j'écris, ça porte à confusion ;) C'est GCC qui ne bronchait pas alors qu'il y avait un bug :) Depuis, je suis en train d'ajouter des assertions statiques en attendant l'effacement de type automatique pour virer ces bugs que GCC ne trouve pas.
VC8 m'a sorti des warnings parce que std::copy était déprécié pour eux, pas assez sécuritaire, de même pour transform :D

Citation:

---

Une macro du genre peut sérieusement simplifier la lecture:

---

Tout à fait, merci :)

Citation:

---

VC8 m'a sorti des warnings parce que std::copy était déprécié pour eux, pas assez sécuritaire, de même pour transform

---

Je l'ai eu aussi celui là. Sais tu pourquoi VC8 a un problème avec 'copy'? En plus c'est sa propre STL.
Je sais pas quoi en faire (à part l'annuler avec un pragma).

http://aspn.activestate.com/ASPN/Mai.../boost/2731073
Et comme je n'ai pour l'instant que des pointeurs comme itérateurs pour ma lib, je l'ai dans le baba :)

Ma lib utilise ses propres itérateurs, mais je sais toujours pas comment les "sécuriser" et faire en sorte que VC8 les reconnaisse comme tel.
Si tu sais ça m'intéresse, je voudrais éviter d'analyser la STL de microsoft.

Dans le lien que tu m'a donné, la colère du mec est très marrante.

PS: j'avais pas vu le lien sur une autre réponse, je vais voir ça...
PS2: j'ai juste appris qu'il faut marquer l'iterator avec un "traits", je vais voir si je le trouve dans le code...

C'est pas n'importe quel mec, c'est Herb Stutter, un des plus grands manitous du C++, actuellement chez Microsoft. Il a fait de très bons livres sur le C++ - bientôt les critiques sur http://c.developpez.com/livres ;) -

En fait, il faut aller voir sur gotw pour la réponse claire à ce problème. Mais avant, j'ai des compilations conditionnelles à remettre en place depuis que je les ai enlevées suite aux erreurs qu'on a trouvées :) - pas encore eu le temps de les remettre, le code de vérification + les algorithmes qui dépendent de cette bibliothèque prend un temps monstre à compiler, et comme j'ai en plus enlevé les vecteurs :| -

J'ajoute juste ici l'article de Microsoft qui en parle directement - les 2 mails de Stutter et de son collègue sont aussi très intéressants, et si eux disent qu'ils essaient d'améliorer la sécurité des applis, c'est sans doute vrai en fait de compte :aie: - http://msdn.microsoft.com/msdnmag/is...C/default.aspx

Citation:

---

C'est pas n'importe quel mec, c'est Herb Stutter, un des plus grands manitous du C++, actuellement chez Microsoft

---

Je connaissais pas.
Dans le monde C++, je connais juste un peu Stroustrop de réputation. J'aime bien son bouquin.

En fait je parlais du mec Jonathan, je me suis quand même bien marré en lisant son message.
Microsoft n'aurait pas dû nommé son warning "deprecated", ça porte vraiment à confusion. Les warnings deprecated de GCC 3.0 sont depuis devenus des erreurs.

C'est quoi gotw?

Avec VC8, il m'a fallu rajouter des "operator<" pour tous mes iterateurs, car en mode débug il teste l'ordre.
Je sais pas si y'a moyen de tester si les itérateurs pointent le même contenaire, peut-être avec une assertion dans ce même "operator<".

VC8 rajoute ceci dans les déclarations d'algorithmes de la STL, tels que copy, transform, equal...

Code:

---

__declspec(deprecated(_Text))

---

La macro _SCL_SECURE_NO_DEPRECATE permet d'annuler cet effet.
C'est vraiment gentil de la part de microsoft de penser à la sécurité, mais je vois toujours pas comment sécuriser mes itérateurs. Je vais voir du coté de l'impléméntation de l'itérateur d'un vecteur...

GOTW = Guru Of The Week
C'est le site de Stutter, en fait. Avant, il répondait à des questions génériques, ça a donné la collection des Exceptional C++.

Normalement, si 2 itérateurs ne sont pas du même conteneurs, l'operateur < devrait retourner faux.

En fait, ils ne rajoutent pas toujours cette indications, que lorsque l'itérateur de destination n'est pas un itérateur vérifié. D'ailleurs, avec un back_inserter par exemple, on ne devrait pas avoir de warning.

Citation:

---

Normalement, si 2 itérateurs ne sont pas du même conteneurs, l'operateur < devrait retourner faux.

---

En fait dans l'implémentation de microsoft, le test d'apartenance au même contenaire est réalisé par une assertion. C'est aussi ce que j'aurais fait pour eviter des tests superflus en mode release.

A première vue, ces vérifications des itérateurs sont des extensions faites par Microsoft, mais ne semblent pas compatibles avec la STL standard.
j'ai trouvé cette déclaration dans l'itérateur des vecteurs.

Code:

---

1 2 3

#if _SECURE_SCL typedef _Range_checked_iterator_tag _Checked_iterator_category; #endif

---

Je vois pas comment je pourrais rajouter cette extension à mes propres itérateurs, et continuer à utiliser d'autres implémentations STL (STLport, GCC)

A priori Microsoft aurait mieux fait de faire une sorte d'iterator_traits avec des spécialisations. Les différents algorithmes l'auraient alors questionné.

Code:

---

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

template<class It> struct checked_iterator_traits { typedef not_checked_iterator_tag _Checked_iterator_category; };   template<class V,class Alloc> struct checked_iterator_traits<_Vector_const_iterator<T, Alloc> > { typedef checked_iterator_tag _Checked_iterator_category; };

---

S'ils ont fait ça comme ça, c'est sûr que c'est :|
Dommage...