-3
votes

Comment réinterpret_cast entre deux types?

Je voudrais refaire refluer le type d'une variable donnée, mais malheureusement réinterpret_cast n'aide pas ici. Cette ligne:

reinterpret_cast<T>(std::string())


12 commentaires

Que voulez-vous accomplir ici et pourquoi pensez-vous que reterpret_cast vous aidera à accomplir cet objectif?


Oui, il y a une approche propre différente. Faire une routine qui prend un std :: chaîne et constructions-et-retourne a std :: vecteur .


"Certains codes autour de cette ligne veilleront à ce qu'il ne soit effectué que lorsqu'il est approprié" Il n'est jamais approprié et certainement pas avec les exemples que vous nous avez donnés.


@Milleniumbug Je dois faire une instance de modèle compile-able.no conversion prévue, rien n'est censé arriver en mémoire. J'ai besoin de désactiver la vérification du type une fois


On dirait que ce que vous vraiment besoin est un peu activer_if monstruosité à l'aide d'un trait "is-convertible" de quelque sorte. Ce serait vraiment mieux si vous vous demandiez de votre vrai problème plutôt que de cette solution non valide


Qu'est-ce qui vous fait croire que reterpret_cast (std :: string ()) est "complètement bien"?


Astuce: Ce n'est pas . Il y a des idées fausses sur les conversions ici, je pense!


@Molbdnilo, eh bien c'était exactement ma question (note 2). Pourquoi ne ferais-t-il pas bien? reintepret_cast <> selon la norme ne modifie pas les valeurs en mémoire


Reterpret_cast n'est pas couvert par aucun des Caste autorisé . std :: string n'est pas un type de référence, ni un type intégré, énumération, pointeur ou pointeur-à-membre


@ LightnessRacesinorbit, il y a déjà un couple d'activation_ifs dans la base de code et votre suggestion fonctionnerait, mais je peux vous assurer que cela ne le rendra pas transparent.


Je pense que vous devez poser une nouvelle question; votre réel un.


@Jonndove "pour t == std :: String Ceci est complètement bien" n'est pas une question, c'est une déclaration de fait (et ce n'est pas vrai). Et aucune conversion, que ce soit implicite ou explicite, de modifier toutes les valeurs; Ils en créent de nouveaux.


3 Réponses :


5
votes

Vous ne pouvez pas, cela n'a aucun sens de le faire et le compilateur vous a dit ça.

reterpret_cast ne peut pas pirater un type dans un type entièrement non liée.

Même s'il l'a fait, par exemple avec le piratage du pointeur que vous exposez dans votre bullet final, les règles de la langue vous interdisent d'utiliser un objet qui a subi un tel casting.

Ne le faites tout simplement pas, car vous ne pouvez pas.

Si vous essayez de construire un vecteur de doubles à partir d'une chaîne (?), faites exactement cela, écrivez le code approprié pour produire des doubles à partir de votre chaîne, de la manière intervenue par vos besoins professionnels.

Le système de type est là pour vous aider. Laissez-le.


2 commentaires

Malheureusement, cela ne m'aident pas. J'ai ajouté encore plus de contexte ci-dessus.


Je ne peux pas vous aider plus loin.



0
votes

Vous voulez construire un conteneur à partir d'un littéral à chaîne.

Utilisez une surcharge de constructeur différente, par ex. xxx

compatible avec xxx xxx

Voir Live


0 commentaires

2
votes

pour t == stdd :: String Ceci est complètement bien, mais malheureusement, le compilateur tentera également d'instancier (mais à l'exécution n'utilisera jamais) cela pour T == std :: vecteur . Et ceci est C ++ 11, donc il n'y a pas de statique_if. P>

en C ++ 17, comme vous l'avez dit, vous pouvez utiliser si consexpr code>: p> xxx pré>

avant C ++ 17, vous pourriez Utilisez des surcharges potentiellement avec la répartition des balises, Sfinae. P>

void foo_specific(const std::string& s)
{
    // Specific code for string
}

void foo_specific(const std::vector<T>& v)
{
    // Specific code for vector
}

template <typename T, std::enable_if_t<std::is_integral<T>::value>, int> = 0>
void foo_specific(const T& n)
{
    // Specific code for integral
}

// ...

template <typename T>
void foo(const T& value)
{
    bar(value);

    foo_specific(value);

    // ...
}


0 commentaires