Est const_cast sûr?

Je ne trouve pas beaucoup d'informations sur const_cast. La seule info que j'ai pu trouver (sur Stack Overflow) est:

La const_cast<>() est utilisé pour ajouter, supprimer const(ness) (ou volatile-ness) d'une variable.

Ce qui me rend nerveux. Pourrait à l'aide d'un const_cast provoquer un comportement inattendu? Si oui, quoi?

Sinon, quand est-il acceptable d'utiliser const_cast?

  • La réponse sommet surplombe quelque chose qui pourrait être terriblement évident, mais il est utile de préciser: Il ne devient dangereux si vous tentez de modifier une origine const objet par l'intermédiaire d'un de-const-ed de référence/pointeur. Si, au lieu de cela, vous êtes simplement const_casting de travailler autour d'un mal (ou, dans mon cas, paresseusement) spec'd API que seule la proposition a été accepté un non-const de référence, mais ne seront utilisées que dans const méthodes... pas de problème que ce soit.
  • De manière plus précise la version de la question (et la réponse) qui couvre ce qui est: Est-il permis d'éloigner le const sur un const objet défini, tant qu'il n'est pas réellement modifié?
InformationsquelleAutor Mag Roader | 2008-12-10
  1. 86

    const_cast est sûr que si vous êtes à la coulée d'une variable a été à l'origine de la non-const. Par exemple, si vous avez une fonction qui prend un paramètre d'un const char *, et que vous passez dans une modifiables char *, il est sûr de const_cast que le paramètre de retour à un char * et de le modifier. Toutefois, si la variable d'origine était en fait const, puis à l'aide const_cast entraînera un comportement indéfini.

    void func(const char *param, size_t sz, bool modify)
{
    if(modify)
        strncpy(const_cast<char *>(param), sz, "new string");
    printf("param: %s\n", param);
}

...

char buffer[16];
const char *unmodifiable = "string constant";
func(buffer, sizeof(buffer), true);  //OK
func(unmodifiable, strlen(unmodifiable), false); //OK
func(unmodifiable, strlen(unmodifiable), true);  //UNDEFINED BEHAVIOR
    • Ce n'est pas vrai. C++ standard. §7.1.​5.1/4 says Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior Toute tentative! Il n'existe pas de mots à propos de la variable d'origine.
    • La variable d'origine est ce qui est souligné ou visé. Vous pouvez prendre un const référence à un non-const objet, et, par conséquent, un moulage d'une écriture de référence est bien défini que le comportement visé à l'objet n'est pas réellement const.
    • peut prendre const référence à un non-const objet. C'est tout. Après que vous avez quelques const objet plutôt que les non-const un. En outre, il existe des cas où il est permis de créer un const copie de vous initial non-const objet. Par exemple pour le cas de l'argument de la fonction.
    • Stanard dit toute tentative! Il n'y a pas d'information à propos de la définition initiale.
    • Malistov: Non. Un "objet" se réfère à l'actuelle région de stockage occupé en mémoire (§1.7). La prise de const référence à un non-const objet ne fait pas l'objet const. Seulement dans le cas d'un const référence paramètre (pas const pointeur de paramètre) est le compilateur autorisés à en silence en faire une copie (§5.2.2/5); ce n'est pas le cas ici.
    • Sont des littéraux les seules données qui est à l'origine déclarée const?
    • J'ai tendance à être d'accord avec Alexey Malistov parce que j'ai réussi à invoquer UB via un const référence à un non-const objet. J'ai passé une référence à un membre de l'objet à une fonction qui a été utilisée const_cast pour modifier la valeur. Le compilateur a décidé de passer une référence à une temporaire sur la pile au lieu de cela, et donc le changement n'a jamais été faite à l'origine.
    • votre sens de l'observation n'est pas en contradiction avec ce que AdamRosenfield dit.
    • En fait il ne. "const_cast est sûr que si vous êtes à la coulée d'une variable a été à l'origine non const" <-- c'est ce Que j'ai fait et c'est ce que l'optimisation s'est cassé. En d'autres termes, const_casting loin const ne fonctionne pas correctement, même si la variable d'origine n'a PAS été const. Il pourrait être argumenté que c'est un optimiseur de bug, mais un bug ou pas, il a causé un problème. La norme semble également à l'appui de l'affirmation selon laquelle cela ne devrait pas être fait.
    • voir cette phrase: Only in the case of a const reference parameter (not a const pointer parameter) is the compiler allowed to silently make a copy (§5.2.2/5) de son commentaire.
    • "Cependant, si la variable d'origine a été, en fait, const, puis à l'aide const_cast va entraîner un comportement non défini" Cette affirmation est fausse.
    • C'est pas UB utiliser const_cast pour supprimer const de quelque chose qui a été initialement déclaré const. Mais il est UB à essayer d'écrire à cet objet. Aussi longtemps que vous venez de lire vous sont fines et la const_cast en lui-même ne cause pas de UB. C'est une idée horrible, mais ce n'est pas intrinsèquement UB.

    InformationsquelleAutor Adam Rosenfield
  2. 34

    Je pense à deux situations où const_cast est utile et sans danger (il y a peut être d'autres cas valides).

    C'est quand vous avez un const exemple, de référence ou pointeur, et que vous souhaitez passer un pointeur ou une référence à une API qui n'est pas const-correct, mais que vous êtes CERTAIN de ne pas modifier l'objet. Vous pouvez const_cast le pointeur et le transmettre à l'API, en espérant qu'il ne sera pas vraiment changer quoi que ce soit. Par exemple:

    void log(char* text);   //Won't change text -- just const-incorrect

void my_func(const std::string& message)
{
    log(const_cast<char*>(&message.c_str()));
}

    L'autre est si vous utilisez un vieux compilateur de ne pas mettre en oeuvre une "mutables", et vous souhaitez créer une classe qui est logiquement const mais pas au niveau du bit const. Vous pouvez const_cast " il " au sein d'un const méthode et de modifier les membres de votre classe.

    class MyClass
{
    char cached_data[10000]; //should be mutable
    bool cache_dirty;        //should also be mutable

  public:

    char getData(int index) const
    {
        if (cache_dirty)
        {
          MyClass* thisptr = const_cast<MyClass*>(this);
          update_cache(thisptr->cached_data);
        }
        return cached_data[index];
    }
};
    • Ce...ne semble pas être de répondre à cette question. Il m'a demandé si const_cast peut provoquer un comportement non défini, non pas ce que les applications utiles sont
    • À partir de la question: "Sinon, quand est-il acceptable d'utiliser const_cast?"
    • Comme dans "quand est-il pas indéfini"; il ne regarde pas pour des exemples de cas où c'est utile
    InformationsquelleAutor Fred Larson
  3. 22

    J'ai du mal à croire que c'est la seulement informations que vous pourriez trouver sur const_cast. Citant le deuxième Google a frappé:

    Si vous avez dédaigné la constness d'un
    objet qui a été explicitement
    déclarée const, et de tenter de
    modifier, les résultats ne sont pas définis.

    Toutefois, si vous avez jeté loin de la
    constness d'un objet qui n'a pas
    été explicitement déclaré const, vous
    pouvez la modifier en toute sécurité.

    • Grrrreaat réponse, combiner cela avec cette réponse et vous obtenez l'ensemble de l'image.
    • hmm. concernant la deuxième déclaration dans votre réponse, puis-je vous demander comment est-il un "const"ness pour un objet qui n'a pas été explicitement déclaré const en premier lieu?.
    • Il y a beaucoup de façons de rendre un non-const objet const, @Iam. Par exemple, passer de l'objet comme const paramètre de référence. Ou l'affecter à un pointeur-à-const. Ou utiliser const_cast. Ou appeler un const méthode.
    InformationsquelleAutor Rob Kennedy
  4. 10

    Ce que dit Adam. Un autre exemple où const_cast peut être utile:

    struct sample {
    T& getT() { 
        return const_cast<T&>(static_cast<const sample*>(this)->getT()); 
    }

    const T& getT() const { 
       /* possibly much code here */
       return t; 
    }

    T t;
};

    Nous avons d'abord ajouter const pour le type this points, puis nous appelons la const version de getT, et puis on enlève const du type de retour, ce qui est valable depuis t doit être non-const (dans le cas contraire, la non-const version de getT ne pouvait pas avoir été appelé). Cela peut être très utile si vous avez un grand corps de la fonction et que vous voulez éviter de code redondant.

    • Je préfère utiliser statique de voter pour l'ajout de constness: static_cast<const échantillon*>(this). Quand je suis en train de lire const_cast cela signifie que le code est en train de faire quelque chose de potentiellement dangereux, donc j'essaie d'éviter de l'utiliser lorsque cela est possible.
    • à droite, la première peut être static_cast, ou même être implicit_cast (boost). je vais le fixer à l'aide statique de la fonte. merci
    • - Je aller et venir sur si const_cast ou static_cast est mieux. const_cast ne peut faire ce que vous voulez: changer le cv-qualificatifs. static_cast peut "silencieusement" effectuer d'autres opérations que vous n'avez pas l'intention. Cependant, la première distribution est entièrement sécuritaire, et static_cast a tendance à être plus sûr que const_cast. Je pense que c'est une situation où la const_cast communique votre intention mieux, mais le static_cast communique la sécurité de vos actions mieux.
    InformationsquelleAutor Johannes Schaub - litb
  5. 9

    La réponse courte est non, il n'est pas sûr.

    La réponse longue est que si vous en savez assez pour l'utiliser, alors il doit être sûr.

    Lorsque vous êtes à la coulée, ce que vous êtes essentiellement en disant, "je sais quelque chose que le compilateur ne sait pas." Dans le cas de const_cast, ce que vous dites se, "Même si cette méthode prend en non-const de référence ou un pointeur, je sais que cela ne va pas changer le paramètre-je le laisser passer."

    Donc, si vous ne savez vraiment ce que vous réclamez à savoir à l'aide de la fonte, puis c'est bien de l'utiliser.

    InformationsquelleAutor JohnMcG
  6. 5

    Vous êtes détruire toute chance au fil de sécurité, si vous commencer à modifier les choses, que le compilateur de la pensée ont été const.

    • Quoi? Si vous avez immuable (const) des objets, vous pouvez trivialement de les partager entre les threads. L'instant où un morceau de votre code, jette const-ness, vous perdez la totalité de votre fil de sécurité! Pourquoi suis-je en bas-modded pour cela? soupir
    • Const est certainement un outil utile dans la fabrication de code thread-safe, mais il ne donne pas de garanties (sauf dans le cas des constantes de compilation). Deux exemples: un const objet peut avoir mutable membres et d'avoir un const pointeur vers un objet ne dit rien sur le fait que l'objet lui-même pourrait être en train de changer.
    • Je pense que c'est une bonne réponse, car je ne pense pas que le compilateur optimiseur de sentiments de confiance et de sécurité dans l'utilisation du mot const. const est la confiance. const_cast est briser cette confiance 🙁
    • Concernant mutable et le fil de sécurité: channel9.msdn.com/posts/...
    InformationsquelleAutor Matt Cruikshank
  7. -1
    #include <iostream>
using namespace std;

void f(int* p) {
  cout << *p << endl;
}

int main(void) {
  const int a = 10;
  const int* b = &a;

  //Function f() expects int*, not const int*
  //  f(b);
  int* c = const_cast<int*>(b);
  f(c);

  //Lvalue is const
  // *b = 20;

  //Undefined behavior
  // *c = 30;

  int a1 = 40;
  const int* b1 = &a1;
  int* c1 = const_cast<int*>(b1);

  //Integer a1, the object referred to by c1, has
  //not been declared const
  *c1 = 50;

  return 0;
}

    source: http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fkeyword_const_cast.htm

    • Si le compilateur de place dans la mémoire en lecture seule, une erreur d'accéder à cette mémoire et le système d'exploitation doit remplir la demande.
    • En conséquence, il est sûr pour être utilisé uniquement à des constantes, qui ont été créés au cours du programme, parce que ces constantes sont toujours placés dans la mémoire autorisée pour l'enregistrement (lecture-écriture).
    InformationsquelleAutor Mr.Angel