Dans un extrait de code ci-dessous, bien que le pointeur ne soit pas initialisé, l'appel est toujours effectué avec succès
class temp {
public:
temp():a(9){}
int& func1()
{
return a;
}
bool func2(int arg)
{
if(arg%2==0)
return true;
return false;
}
int a;
};
int main(int argc, char **argv)
{
temp *ptr;
int a;
cin>>a;
if(ptr->func2(a))
{
cout<<"Good poniner"<<endl;
}
ptr->func1(); // Does not crash here
int crashere=ptr->func1();// But does crash here
return 0;
}
6 Réponses :
Le compilateur C ++ ne vous empêche pas d'utiliser des pointeurs non initialisés et que les résultats ne sont pas définis, il est normal que les compilateurs dans le monde réel de générer du code qui ignore le fait que le pointeur est inintitualisé.
C'est l'une des raisons pour lesquelles C ++ est à la fois rapide et (relativement) dangereux par rapport à d'autres langues.
La raison pour laquelle votre appel à Func2 réussit est qu'il ne touche pas son ce pointeur . La valeur du pointeur n'est jamais utilisée, il ne peut donc pas causer de problème. Dans Func1 Vous do utilisez le pointeur (pour accéder à une variable de membre), c'est pourquoi celui-ci se bloque.
Je soupçonne que PTR-> Func2 () est optimisé alors qu'il revient toujours vrai. Mais comme le dit Richie, l'utilisation du pointeur est une amende dans ce cas car vous ne touchez pas de données d'instance (a) et à ce titre, il n'y a rien à écraser.
Il ne peut pas être optimisé, car il y a plus de code en fonction de celui-ci (si la déclaration).
Il peut être optimisé . Un optimiseur peut supposer que tout chemin de code qui entraînerait un comportement non défini au moment de l'exécution est inaccessible. Ce chemin de code peut donc être supprimé, en arrière du comportement non défini à la dernière branche. En conséquence, un programme qui doit produire UB indépendant de l'entrée peut être optimisé pour INT Main () {}
sa ne fonctionne pas. C'est juste de la chance que votre application ne se plante pas là où vous m'attendez à crash. Ce n'est pas une fonctionnalité, mais un effet secondaire du compilateur qui permet à l'appel de fonction semble fonctionner.
Pas vrai. FUNC2 n'utilise pas son Ceci Pointeur, de sorte qu'il ne s'écrasera jamais.
Je ne sais pas pourquoi cela a été voté. On pourrait imaginer des écrivains de compilateurs diaboliques (ou peut-être utiles) qui feraient effectivement un crash (après tout, il peut être déterminé de manière statique que le pointeur est ininitialisé et que les compilateurs avertissent de cela). Donc, ce "jamais" de Richiehindle est incorrect (peut-être les compilateurs ne sont pas encore à ce niveau). Je ne voudrais tout simplement pas appeler ça "chance" que les programmes ne s'effondrent pas tout de suite si le code est faux.
Ma pensée était que même si Temp-> Func2 () disparaîtra à Func2 (TEMP), ce n'est toujours pas correct. Remarque intéressante, si vous exécutez l'affecteur dans Windows XP avec ce code, il s'écrasera sur TEMP-> FUNC2 ().
Il s'agit d'un comportement entièrement dépendant de compilateur et non défini en fonction de la norme. Vous ne devriez pas compter sur cela.
appelez à car le compilateur est chargé de renvoyer la référence à l'élément de classe. Pour ce faire, il ajoute simplement le décalage du membre à la valeur non valide de ce pointeur em> et qui produit un autre pointeur non valide (référence, qui est presque identique). P> Func2 () code> réussit car la méthode exacte à appeler est connue à l'heure de la compilation (l'appel n'est pas virtuel) et la méthode elle-même ce pointeur em>. Tellement invalide ce em> va bien. P> int crashere=ptr->func1();// Crashes here
C ++ a la notion de comportement indéfini. L'utilisation d'un pointeur ininitialisé est un exemple courant de ce comportement non défini. Pour des raisons de performance, les lieux standard C ++
Vous pouvez appeler les méthodes à l'aide de pointeurs non initialisés. Cela fonctionnera soit PTR-> FUNC1 (); ou int Cracke = PTR-> FUNC1 (); //
Il peut être intéressant de noter que VC6 prédit la norme C ++. Voir ceci pour plus de raisons pour ne pas utiliser VC6 ... JasonBadams.net / 20090119 / Pourquoi-VOUS-NE-NE-NE - UTILISER-VC6