statique/dynamique de la fonte des références/objets

J'ai été jouer avec un tas de casting opérateurs de tout à l'heure, qui, apparemment, je n'ai pas vraiment à l'époque. J'étais à la recherche de plus de mon code maintenant et j'ai vu ceci:

Base(Derived &p_derived) : m_state(static_cast<Base>(p_derived).m_state){}

Je pense que j'ai maintenant une meilleure compréhension de la coulée de pointeurs et références grâce à un très bonne réponse ici sur stackoverflow, mais maintenant il y a les objets concernés. Ce qui se passe exactement lorsque la référence est coulé à un objet? Ou si p_derived a été l'objet lui-même et non pas seulement une référence? Serait-il créer de nouveaux objets et si oui, comment seraient-elles être instanciée?

Je suis aussi surpris que cela pourrait être compilé à tous depuis la Base.h, où ce code est trouvé, Dérivé est seulement vers l'avant a déclaré le sens qu'il ne sait pas qu'elle dérive de la Base. J'ai essayé à un autre endroit pour faire une statique de la fonte à partir d'un Dérivé* de Base*, mais ce serait à juste titre, de ne pas compiler en raison des types incompatibles dans la mesure où cette unité de traduction est en cause.

InformationsquelleAutor user1130005 | 2012-01-17
  1. 6

    Lorsque vous utilisez une référence, vous êtes généralement en fait l'utilisation de l'objet qu'il désigne. C'est la magie de la transparence de référence de la syntaxe que vous n'avez pas avec les pointeurs; sans doute, c'est leur raison d'être.

    Ce scénario n'est pas une exception: vous prenez la p_derived arbitre et la construction d'une nouvelle Base de via de le trancher.

    static_cast<Base&>(p_derived) sera jeté la référence elle-même, si c'est ce que vous êtes après (et même si elle n'est pas :P).

    Je suis aussi surpris que cela pourrait être compilé à tous depuis la Base.h, où ce code est trouvé, Dérivé est seulement vers l'avant a déclaré le sens qu'il ne sait pas qu'elle dérive de la Base.

    Oui, cela me surprend aussi. Êtes-vous sûr? (Démo /Démo - pas sûr que vous utilisez)

    • Donc, vous dites que "static_cast<Base>(d)", si d est une référence ou l'objet, qui est essentiellement le même comme "Base b; b = d;" dans ce cas? Et non, c'est plus comme ceci: codepad.org/8bn2MxAl
    • C'est exactement ce que je dis. Qu'essayez-vous d'atteindre avec ce code? Pourquoi ne pas m_state(static_cast<Base*>(p_derived.m_state.get())) ou similaires?
    • Oui, je devrais certainement résoudre différemment. J'ai eu plusieurs classes dérivant de Base qui sert comme une sorte d'interface à un état partagé entre l'dérivant des classes, c'est pourquoi j'ai besoin de passer par un objet (peut-être de Base& serait mieux) pour obtenir son état qui est privé à la Base. Je suis en train de tourner du code Java à C++, Java et permet tous les types de fou dépendances. C'est pourquoi je me fais de ces problèmes. Je suis quand même curieux que la raison pour laquelle le static_cast a été autorisé à tous. Est-il possible en C++ de faire "A A; B b; a = b;" même si A et B n'a rien en commun?
    • Que si les types sont compatibles, d'une certaine façon. Comme je l'ai dit dans ma réponse, je ne crois pas vraiment que votre code compilé.
    • Oui, vous avez fait le tri de implique que. Désolé de ne pas répondre directement, mais ici il est: il n'en fait la compilation. codepad.org/WeXkKovO (C'est en fait un shared_ptr, mais codepad ne semblent pas comme ça)
    • Ah, mais même si il n'y a pas d'héritage, Base peut être construit à partir d'un Derived&... que très constructeur est celui qui le rend si! Je me demande si vous avez certains de récursivité infinie dans ce initialiser en conséquence.
    • Ah, bien sûr! Je vous remercie. Oui, je n'ai pas essayé de courir, mais il peut très bien prendre une mauvaise tournure rapidement si je ne. Merci pour l'entrée!

    InformationsquelleAutor Lightness Races with Monica