Utilisation de tycastations de style C ++ (tous les 4) ressemble exactement à un modèle de fonction dynamic_cast<Derived*>(p); // p is Base*
4 Réponses :
Je pense que la raison est la même chose pour vous ne pouvez pas surcharger le mot-clé de langage.
En fait, vous devez les voir comme une fonction de clé de langage et non de la fonction de modèle, même si la
J'étais à peu près sûr que quelqu'un aurait lancé la question suivante: "Alors pourquoi vous pouvez surcharger nouveau / Supprimer ?". Je pense que la personnalisation de l'allocation de mémoire / de la répartition est quelque chose dont vous avez besoin dans certains scénarios et que les avantages de vous permettre de les surcharger l'emporter sur les risques. Je ne peux voir aucun avantage pour subvertir le système de type C ++, je ne pense pas à penser un scénario où il serait utile. Êtes-vous?
Nouveau / Supprimer Sont également mot-clé de langue et PPL peut faire des catastrophes entre eux; La même chose est applicable pour la surcharge opérateur . Alors pourquoi pas Typecasts, qui ressemblent exactement à des fonctions déjà.
Shared_ptr
Oui, dynamic_cast peut être optimisé si un développeur sait que sa classe est héritée par une seule autre classe (avec fonction virtuelle). Il y a beaucoup d'utilité si possible pour d'autres cases
@iammilind Si vous avez besoin d'optimiser votre code, je ne me concentrerais pas sur le type de coulée. J'ai vraiment du mal à y penser comme un goulot d'étranglement ...
@Simone, parfois, votre classe pourrait être utilisée par d'autres. Vous ne pouvez pas leur demander de ne pas utiliser dynamic_cast ; Plutôt, vous pouvez simplement le surcharger. En outre, je viens de donner un exemple .. Il peut y avoir beaucoup d'utilité.
@iammilind: Il s'agit des fonctions "Opérateur nouvel" et "Opérateur d'opérateur" qui peut être surchargé, pas les mots-clés - il n'est donc pas tout à fait la même chose.
Je vois. Quoi qu'il en soit, je pense que ce serait déroutant, de dire le moins. Par exemple, si la distribution est implicite? Appliquez-vous la surcharge ou non? Désolé mais - allément je vois votre point - je suis d'accord avec le comité standard. Je pense que lorsque vous avez besoin de vous gâcher avec le type de coulée la plupart du temps, vous avez des défauts dans votre conception que l'on pourrait contourner une telle caractéristique, ce qui provoque la conception pourrité.
@Richard: Et ce serait la fonction (fictif) fonction opérateur dynamic_cast qui serait surchargé, pas le mot-clé. Donc?
@sbi: Le premier paramètre à l'opérateur Supprimer doit être un un Void * et la sémantique est que le paramètre doit être "pris en charge" - quoi que ce soit pour le programme. Le type d'opérande utilisé dans l'expression d'origine avec 'Supprimer' est parti depuis longtemps. (Situation similaire pour opérateur Nouveau où le premier opérande doit avoir le type Taille_t qui correspond à la quantité de mémoire requise). Je ne vois pas comment le même processus pourrait être mappé sur un opérateur de fiction (ou non) dynamic_cast .
Fait intéressant, certaines bibliothèques (comme Boost) utilisent cette similitude pour définir leurs propres opérateurs «casting», tels que
static_pointer_cast <> .@ ceris, ya j'ai entendu parler de certains moulages comme ça, mais ce mot clé n'est pas autorisé pour une raison quelconque !!
Mettez une règle dans votre projet que toutes les moulages auront lieu via certains modèles de transfert: "x_dynamic_cast", "x_static_cast", etc., puis recherchez n'importe quelle utilisation du réel dynamic_cast et remplacez-le. C'est l'une des caractéristiques fraîches des opérateurs de distribution «vity» en ce qu'ils sont très faciles à rechercher.
Puisqu'il y a des réponses qui couvrent à peu près la raison pour laquelle je voulais juste dire bien peut-être que cela n'est pas autorisé, mais vous pouvez remplacer dynamic_cast. Vous pouvez définir votre modèle "my_cast", puis utiliser le prétraiteur pour remplacer dynamic_cast ou reterpret_cast A..o Disons dans les bâtiments de débogage (c'est-à-dire de la même manière que vous pouvez utiliser le prétraiteur pour "Renommer" Nouveauté à Debug_New). Nous avons fait cela ajouté certains chèques de compilation dans les bâtiments de débogage liés au casting. Nous avions l'avantage que nous avions un fichier d'en-tête inclus sur tout ce que nous pouvions "#define dynamic_cast chk: my_cast 'en une seule place
L'avantage que je vois avec le préprocesseur APRACH (comparé au remplacement de la recherche et remplacer dynamic_cast avec x_my_dynamic_cast est qu'il ne force pas tout le monde dans votre équipe à écrire x_my_dynamic_cast et veille également à ce que des situations où quelqu'un oublie (ou ne sait pas encore - IE est nouveau dans l'équipe) que X_MY_DYNAMIC_CAST au lieu de dynamic_cast doit être utilisé automatiquement. Et tout le monde peut écrire le code car ils le feraient normalement ...