Pourquoi devez-vous passer l'adresse du pointeur au lieu du pointeur lui-même lorsque vous utilisez la bibliothèque Viper dans Go?

Explication détaillée de la fonction Unmarshalkey de la bibliothèque de vipères de langue Go et du transfert d'adresse de pointeur

Cet article explique pourquoi la fonction UnmarshalKey doit passer l'adresse du pointeur au lieu du pointeur lui-même lors de l'utilisation de la bibliothèque Viper dans Go. Nous analyserons ce problème en combinaison avec des exemples de code et le code source de la bibliothèque Viper.

La cause profonde du problème réside dans le mécanisme de réflexion à l'intérieur de la fonction UnmarshalKey . Cette fonction nécessite un pointeur adressable pour déshabiller les données du fichier de configuration dans la structure cible. Bien que le pointeur soit un type de pointeur, il ne s'agit pas d'une adresse de mémoire adressable et ne peut pas être modifié.

Exemples de code et analyse des problèmes:

Les exemples de code fournis dans l'article montrent clairement ce problème. Bien que global.serversetting soit de type *setting.serversettings (pointeur), il pointe vers une adresse mémoire allouée. Ce que la fonction UnmarshalKey a besoin, c'est de l'adresse de ce pointeur afin de modifier la valeur dans la zone de mémoire à laquelle il pointe. Passer global.serversetting directement équivaut à passer la valeur du pointeur (c'est-à-dire à l'adresse mémoire), plutôt qu'à l'adresse elle-même. Cela rend UnmarshalKey incapable de modifier le contenu de la structure indiquée par serversetting .

Analyse du code source de la bibliothèque de Viper:

Le fragment de fonction newdecoder de la bibliothèque Viper:

 func newdecoder (config * DecoderConfig) (* Decoder, Error) {
    val: = reflev.valueof (config.result)
    si val.kind ()! = reflev.ptr {
        return nil, errors.new ("le résultat doit être un pointeur")
    }

    val = val.elem ()
    si! Val.canaddr () {
        return nil, errors.new ("Le résultat doit être adressable (un pointeur)")
    }
    // ...
}

Ce code explique pourquoi des pointeurs adressables sont nécessaires:

1. val.Kind() != reflect.Ptr : Vérifiez si le paramètre passé est un type de pointeur.
2. val = val.Elem() : obtient la valeur pointée par le pointeur.
3. !val.CanAddr() : C'est le point clé. CanAddr() vérifie si la valeur est adressable. Si vous passez le pointeur directement, val.Elem() obtient la structure elle-même et la structure elle-même n'est pas adressable car ce n'est pas un pointeur. Seule l'adresse du pointeur est adressable, car l'adresse elle-même représente un emplacement de mémoire et peut être modifiée.

Code et résultats de vérification:

Le code de vérification fourni dans l'article:

 package principal

importer (
    "FMT"
    "refléter"
)

var a * db

Tapez db struct {
}

func main () {
    Val: = refléte.Valueof (a)
    val = val.elem ()
    fmt.println (val.canaddr ()) // false

    val = réflect.valueof (& a)
    val = val.elem ()
    fmt.println (val.canaddr ()) // true
}

Ce code vérifie que les résultats renvoyés par CanAddr() de reflect.ValueOf(a) (pointeur lui-même) et reflect.ValueOf(&a) (adresse du pointeur). Seule l'adresse du pointeur peut être traitée.

en conclusion:

Afin d'utiliser correctement la fonction UnmarshalKey de la bibliothèque Viper, l'adresse du pointeur vers la structure cible ( &global.serversetting ) doit être transmise, plutôt que le pointeur lui-même ( global.serversetting ). Cela garantit que la bibliothèque Viper peut ne pas groupement les données du fichier de configuration dans la structure cible. Ce n'est pas un problème unique à la bibliothèque Viper, mais à la réflexion du mécanisme de réflexion du langage GO et de la sémantique de pointeur. Comprendre le pointeur de langue GO et le mécanisme de réflexion est crucial pour résoudre de tels problèmes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!