Pourquoi puis-je voir les gens implémenter des propriétés comme celle-ci? de
Quel est le point de vérifier si la valeur est égale à la valeur actuelle?
public double? Price
{
get
{
return _price;
}
set
{
if (_price == value)
return;
_price = value;
}
}
4 Réponses :
tel que, vous n'avez pas à réaffecter la même valeur. Sa juste exécution plus rapide pour la comparaison de valeurs. AFAIK
La comparaison est plus rapide que l'assentiment. Dites si c'est une grande source de données et sa mémoire doit être créée à nouveau et encore (TYPE REF) ou si ce n'est pas instancié pour la première fois, une exception est lancée.
Si cela est vrai, cela implique-t-il que nous devons éviter d'utiliser la propriété automobile?
Je ne vois aucune preuve dans cette revendication. Voir le test J'ai ajouté pour une démonstration.
Désolé gars, mon erreur. Merci d'avoir emporté mes points de sueur gagnés;)
Dans ce cas, il serait discutable; Cependant, dans le cas où il existe un effet secondaire associé (typiquement un événement), il évite d'événements triviaux. Par exemple: maintenant, si nous le faisons: Nous n'obtenons pas 4 événements; Nous obtenons au plus 1 (peut-être 0 s'il est déjà 16). Dans des exemples plus complexes, il pourrait y avoir une validation, des actions de pré-modification et post-changement. Tous ces éléments peuvent être évités si vous savez que ce n'est pas réellement un changement.
ouais, je pensais que c'est inutile si son affectation directe
Un test rapide avec une affectation pure à l'aide de chronomètre pour chronométrage montre que le chèque le rend effectivement deux fois plus lent, mais toujours une quantité extrêmement petite de temps. Même avec 1 million d'itérations, le temps pris est de 0,05 secondes.
Le seul endroit que je fais est comme le suggère Marc. Je veux déclencher un événement (ou effectuer un autre traitement supplémentaire) si la valeur change mais pas si elle reste la même
Marc, je suis désolé d'avoir eu tort de la performance de la comparaison de l'assentiment de la VS. Mais encore une fois, vous ne répondez pas directement à la OP QS. Je veux dire, oui c'est vrai sur ce qui a déclaré sur les événements soulevant si des valeurs sont différentes. Mais en prenant le code de base de l'OP, comment vous expliqueriez pourquoi cela se fait?
@zenwalker imo, il est fait de habitude , ou en raison de la recherche de code généré (c'est-à-dire dans un fichier .designer.cs) et de voir le modèle mais manque le contexte. Comme présenté, il n'ajoute aucune valeur que ce soit (mais ajoute des frais généraux). Si essentiellement, ma réponse à cette question est simplement les 7 premiers mots de ma réponse: "Dans ce cas, ce serait discutable.".
Pourquoi est-ce préférable à si (_price! = Valeur) {_price = valeur; Onpricechanged ()} ? Pourquoi tester juste pour revenir?
@Keithtyler En fin de compte, peu importe - c'est une question stylistique; Choisissez celui que vous voulez; Ils font la même chose
Ce n'est pas une réponse, plus: C'est une réponse fondée sur des preuves à la réclamation (dans une autre réponse) qu'il est plus rapide de vérifier que d'attribuer. En bref: non, ce n'est pas le cas. Aucune différence whatsoever . Je reçois (pour non nullable (avec de petites variations sur les courses successives - mais essentiellement, ils prennent tous exactement la même heure dans n'importe quelle arronçage sensible - Lorsque vous faites quelque chose de 500 millions de fois, nous pouvons ignorer la différence de 1 ms) en fait, si nous passons à ou donc c'est pas une assistante de performance! avec des tests int ): int? i get: double? (comme dans la question):
bizarre. J'ai comparé basicprop & checkedprop et cela a donné une plus longue période pour chèquesProp. Juste hors de curiosité, utilisez-vous un système 64 bits?
@markoo Oui, Win-7, X64, I7 CPU. BTW, j'ai ajouté des horaires pour quelques types de données différents, aussi
Aaah, c'était ça. La nullable, que j'ai testée en premier. Intéressant.
@Markoo Ouais, "Opérateurs levés" ont un peu plus de frais généraux; Il est plus remarquable dans ce cas simplement parce que int et double ont des implémentations directes de l'égalité d'IL; Dans des cas tels que DateTime ou décimal il serait moins perceptible.
Bon à savoir. En tant que note supplémentaire: votre chèque pour! = Est aussi beaucoup plus rapide que de vérifier == puis de revenir.
@markoo c'est impair - il n'y a aucune raison pour laquelle il devrait être; Il est toujours soit broré_s ou brfalse_s
Supposons que nous ne traitons aucun changement de changement. Je ne pense pas que la comparaison est plus rapide que l'abandon. Cela dépend du type de données. Disons que vous avez une chaîne, la comparaison est beaucoup plus longue dans le pire des cas qu'une simple affectation où le membre change simplement référence à la référence de la nouvelle chaîne. Je suppose donc que c'est mieux dans ce cas d'attribuer tout de suite. Dans le cas de types de données simples, il n'a pas d'impact réel.
[citation requise]
lol - r # dit "Vérification redondante avant assignation"
Mon Resharper ne se plaint pas ...
Ah, je l'ai écrit comme
si (champ! = valeur) champ = valeur; - cela n'affecte pas les horaires, note - mais en effet, r # ne le regarde pas avec le < code> si (champ == valeur) retourne; champ = valeur; approche