2017-09-29 5 views
1

Je me demande si ce comportement non défini évoque exemple:L'évaluation de la fonction de membre statique pendant la construction avant l'initialisation de base est-elle un comportement indéfini?

struct Base 
    { 
    Base(int); 
    }; 
struct Derived 
    :Base 
    { 
    static int a_static_function(); 

    Derived() 
    :Base(a_static_function())//is it undefined behavior? 
    {} 
    }; 

EDIT: Je demande qu'en raison de ce paragraphe dans la norme C++ [class.base.init]:

fonctions membres (y compris les fonctions membres virtuelles, 13.3) peut être appelée pour un objet en construction. De même, un objet en construction peut être l'opérande de l'opérateur typeid (8.2.8) ou d'un cast dynamique_- (8.2.7). Toutefois, si ces opérations sont effectuées dans un cteur-initialiseur (ou dans une fonction appelée directement ou indirectement d'un cteur-initialiseur) avant que tous les mem-initialisations pour les classes de base ont terminé, le programme a un comportement non défini.

Il ne semble pas être spécifique aux fonctions membres non statiques.

+3

Pourquoi pensez-vous que ce serait? –

+0

@VittorioRomeo En effet, cela est à cause d'une phrase dans la norme ... je l'ajoute – Oliv

+1

l'OMI, il est juste un oubli dans la norme et l'intention était de parler de fonctions membres non statiques ici –

Répondre

2

Non, ce n'est pas UB. Une fonction membre statique est semblable à une fonction ordinaire (non membre), sauf qu'elle a accès à des éléments private (par exemple, des données statiques privées et d'autres fonctions membres statiques).

Ma compréhension de votre citation de la norme est qu'elle s'applique aux fonctions membres non statiques.

+0

Ne peut-il pas accéder à la fonction et au champ _any_ 'static' class, pas seulement ceux déclarés comme' private'? –

+0

Il a également accès à toutes les données non statiques, il a juste besoin d'une instance de la classe pour les obtenir. – NathanOliver

+0

Mais le standard semble indiquer que c'est UB ... ??? – Oliv