Constructeur par défaut et undefined behavior

Bonjour,

Ma question va paraitre bête à certains, mais ça me travaille dur...

1) Scott Meyers explique dans ses bouquins qu'il ne faut jamais accéder à une donnée non initialisée car cela conduit à un undefined behavior. On sait tous ce que ça veut dire : la plupart du temps, on lit des données semi-aléatoires mais on pourrait un jour se retrouver avec un dragon qui sort de notre PC et nous dévore. 2) Quand on ne définit pas de constructeur, le compilateur en génère un. D'après ce que j'ai lu, il initialise tous les champs qui ont un constructeur par défaut, mais quid des types de base ? Il n'y a pas de constructeurs et j'ai cru comprendre qu'ils n'étaient donc pas initialisés. 3) En connectant ces 2 informations, dois-je en conclure que je risque un UB en lisant des champs d'un objet créé avec un tel constructeur par défaut ? Ça me paraitrait insensé mais je ne vois pas l'erreur dans mon raisonnement.

Merci pour vos lumières :ccool:

Je crois que je viens d'avoir la réponse en passant cppcheck sur du code...

Citation:

---

Résumé: The class 'TemperatureWidget' does not have a constructor.
Message: The class 'TemperatureWidget' does not have a constructor although it has private member variables. Member variables of builtin types are left uninitialized when the class is instantiated. That may cause bugs or undefined behavior.

---

Citation:

---

Envoyé par Bktero

Quand on ne définit pas de constructeur, le compilateur en génère un. D'après ce que j'ai lu, il initialise tous les champs qui ont un constructeur par défaut, mais quid des types de base ? Il n'y a pas de constructeurs et j'ai cru comprendre qu'ils n'étaient donc pas initialisés. 3) En connectant ces 2 informations, dois-je en conclure que je risque un UB en lisant des champs d'un objet créé avec un tel constructeur par défaut ?

---

Oui, et ça n'est pas du tout insensé, si toute variable devrait avoir une valeur par défaut on ne se poserait pas la question. On peut ne pas initialiser les variables scalaires, ce qui permet à constructeur dit "trivial" (=rien à initialiser) une optimisation importante. Par exemple que ce passe-t-il si on crée un tableau de 10000 Complexes?
Il existe cependant un moyen indirect de forcer cette initialisation (pour un objet n'ayant aucun constructeur défini et tous ses membres de même niveau de protection)

Code:

---

1 2	int x{}; // x est initialisé à 0 MaClasse y{}; // La classe est initialisée par liste d'initialisation vide => tous les scalaires sont mis à 0.

---

En plus du fait que les types Plain Old Data ne soient pas initialisés par défaut, il faut ajouter le fait que le seul fait de lire une variable non-initialisée peut causer un UB: Une valeur peut être une trap representation qui cause une erreur dès que le processeur la charge dans un registre. Il me semble d'ailleurs que c'est le cas pour les signaling NaNs.
Plus d'infos:
Uninitialized floating point variables can be deadly
Uninitialized garbage on ia64 can be deadly

Mon dieu c'est horrible !

Je comprends la problématique de performance, mais alors un code comme ceci sont des UB et PC pourrait un jour exploser ?

Code:

---

1 2 3 4 5 6 7 8 9

#include <array>   using namespace std;   int main() { array<int, 12> my_array; return my_array[5]; // UB (en supposant que le tableau servant en interne n'a pas été initialisé) }

---

PS : @Médinoc j'ai vraiment l'impression que tu connais le blog de Raymond Chen par cœur... Ce n'est pas toi Raymond Chen quand même ?! :mouarf: Super articles en tout cas !

D'un autre coté, cela te choquerait-il que le code suivant soit un UB?

Code:

---

1 2 3 4 5

int main() { int my_array[12]; return my_array[5]; // UB }

---

Choqué je sais pas... En tout cas, je n'avais pas vu les choses comme ça. En fait, jusqu'à il y a peu, je savais même pas que ceci était un UB :

Code:

---

1 2 3 4 5 6

int main() { int a; int b = a; return b; }

---

En tout cas en C, je pensais que c'était tout à fait valable, simplement que ta variable contenait du garbage (pas d'initialisation automatique). Je présume que si C++ dit que c'est un UB, alors C doit faire pareil. Ca ébranle certains certitudes et ça me ferait presque douter de mes connaissances. Peut-être que c'est simple le signe qu'on continue à apprendre même sur des sujets qu'on pensait maitriser.

La norme précise que le contenu d'une variable non initialisée est indéterminé mais utiliser une telle variable n'entraîne pas automatiquement un comportement indéterminé. Cela dépend de choses (trap representations notamment, mais aussi stratégies d'optimisation) parfois difficiles à cerner dans un contexte donné, et c'est probablement différent en C et en C++.

En pratique il est difficile de s'assurer que le comportement résultant de l'utilisation d'une variable non initialisée est déterminé quelque soit l'implémentation du langage et surtout quelque soit l'architecture, raison pour laquelle il est préférable de ne jamais recourir à de telles acrobaties.

J'ai fait quelque chose que je n'avais pas fait depuis très longtemps et dont j'étais friand dans le passé : j'ai ouvert la norme C99 (n1256) et j'ai cherché 8-)

A la page 126, dans une section 6.7.8 très judicieusement nommée Initialization, on peut lire :

Citation:

---

10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:
—if it has pointer type, it is initialized to a null pointer;
—if it has arithmetic type, it is initialized to (positive or unsigned) zero;
—if it is an aggregate, every member is initialized (recursively) according to these rules;
—if it is a union, the first named member is initialized (recursively) according to these rules.

---

Puis, à la page 492, dans la section qui liste les UB (section que j'ai découverte la semaine dernière, j'étais jamais allé si loin !), on pourra lire (oui, j'ai lu tous les UB jusqu'à trouver celui-là) :

Citation:

---

The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8).

---

CQFD.

C'est bon d'être précis, même si pour le coup, on parle du C99.

Je me suis un peu laissé berné par Valgrind
En effet, ce dernier est capable d'indiquer quand une valeur indeterminée est utilisée dans un branchement, sans râler avant lors des copies.
(et avec --track-origins=yes, il est capable d'en traquer l'origine)

Citation:

---

Envoyé par Bktero

Puis, à la page 492, dans la section qui liste les UB (section que j'ai découverte la semaine dernière, j'étais jamais allé si loin !), on pourra lire (oui, j'ai lu tous les UB jusqu'à trouver celui-là) :

Citation:

---

The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8).

---

CQFD.

---

Note d'appendice depuis invalidée par C11, si je ne m'abuse. Je n'ai pas le temps d'aller chercher la norme mais il me semble que c'est mentionné dans le lien que j'ai inclus ci-avant.

Je viens de retrouver la même note dans la norme C11 (n1548), à la page 554. Je vais jeter un oeil pour C++ (première fois que j'ouvre la norme C++ !).