Comportement non standard
Les sections suivantes répertorient certains des endroits où l’implémentation Microsoft de C++ n’est pas conforme à la norme C++. Les numéros de section indiqués ci-dessous font référence aux numéros de section dans la norme C++11 (ISO/IEC 14882 :2011(E)).
La liste des limites du compilateur qui diffèrent de celles définies dans la norme C++ est donnée dans les limites du compilateur.
Types de retour covariant
Les classes de base virtuelle ne sont pas prises en charge en tant que types de retour covariants lorsque la fonction virtuelle a un nombre d’arguments variable. Cela n’est pas conforme à la section 10.3, paragraphe 7 de la spécification ISO C++11. L’exemple suivant ne compile pas ; elle génère l’erreur du compilateur C2688 :
// CovariantReturn.cpp
class A
{
virtual A* f(int c, ...); // remove ...
};
class B : virtual A
{
B* f(int c, ...); // C2688 remove ...
};
Liaison de noms non dépendants dans des modèles
Le compilateur Microsoft C++ ne prend actuellement pas en charge les noms non indépendants de liaison lors de l’analyse initiale d’un modèle. Cela n’est pas conforme à la section 14.6.3 de la spécification ISO C++11. Cela peut provoquer la déclaration de surcharges après le modèle à afficher (mais avant que le modèle soit instancié).
#include <iostream>
using namespace std;
namespace N {
void f(int) { cout << "f(int)" << endl;}
}
template <class T> void g(T) {
N::f('a'); // calls f(char), should call f(int)
}
namespace N {
void f(char) { cout << "f(char)" << endl;}
}
int main() {
g('c');
}
// Output: f(char)
Spécificateurs d'exceptions de fonctions
Les spécificateurs d'exceptions de fonction autres que throw()
sont analysés, mais pas utilisés. Cela n’est pas conforme à la section 15.4 de la spécification ISO C++11. Par exemple :
void f() throw(int); // parsed but not used
void g() throw(); // parsed and used
Pour plus d’informations sur les spécifications d’exception, consultez Spécifications d’exception.
char_traits::eof()
La norme C++ indique que char_traits ::eof ne doit pas correspondre à une valeur valide char_type
. Le compilateur Microsoft C++ applique cette contrainte pour le type char
, mais pas pour le type wchar_t
. Cela n’est pas conforme aux exigences du tableau 62 de la section 12.1.1 de la spécification ISO C++11. L’exemple ci-dessous illustre ce comportement.
#include <iostream>
int main()
{
using namespace std;
char_traits<char>::int_type int2 = char_traits<char>::eof();
cout << "The eof marker for char_traits<char> is: " << int2 << endl;
char_traits<wchar_t>::int_type int3 = char_traits<wchar_t>::eof();
cout << "The eof marker for char_traits<wchar_t> is: " << int3 << endl;
}
Emplacement de stockage des objets
La norme C++ (section 1.8, paragraphe 6) exige que les objets C++ complets aient des emplacements de stockage uniques. Toutefois, avec Microsoft C++, il existe des cas où les types sans membres de données partagent un emplacement de stockage avec d’autres types pour la durée de vie de l’objet.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour