Cela me semble être un bug à ...
J'accepte que les propriétés automatiques, définies comme telles: p>
Total += 8;
10 Réponses :
Null + 8 = Null You'll need to set it with zero before.
Oui, je sais que c'est la solution, je pense qu'il est stupide. :)
Parce qu'il est contre-intuitif, au moins pour moi. Si c'était mon compilateur, je l'aurais fait l'hypothèse (en particulier avec quelque chose comme un automatique propriété) que si vous avez une valeur non initialisée et vous ajoutez quelque chose, il serait tout simplement ramasser la valeur ajoutée . Mais, peut-être il y a des cas où ce genre d'hypothèse poserait des problèmes, qui sait.
Vous ne PAS ont une valeur non initialisée. Vous avez une valeur initialisée à null.
null code> moyen valeur inconnue, unknown value + known value = still unknown value
Je comprends ce qu'est un null est, mais il me semble que ce serait une hypothèse sûre que nul + 8 serait égal à 8. Mais, je suppose que je suis tout simplement faux. :)
Vous avez tort en effet :) Si null a été égal à 0 ce serait le point d'avoir une valeur nulle ? Notez que si vous définissez votre propriété en tant que type non annulable (supprimer le signe) il sera donné la valeur par défaut pour le type décimal qui AFAIK est 0 et vous serez en mesure d'utiliser votre + = 8 code.
Haha - :) Ouais, je l'ai remarqué la valeur par défaut avec des accessoires automatiques avant. Je ne dis pas que nul ne devrait être égal à zéro, juste que si vous avez une valeur initialisées et vous l'ajoutez à une valeur nulle, il me semble logique que le champ serait tout simplement ramasser la valeur initialisés.
Avez-vous vraiment que cela fonctionne comme ça? Permettez-moi de vous donner un exemple concret de la vie pourquoi cela est faux: laisse supposer que vous avez un peu d'argent dans votre portefeuille (mais vous n'êtes pas sûr à quel point est que, peut être 20 $, peut être 2000 $, ceci est notre null ). Maintenant, quelqu'un vous donne 500 $. Si cela fonctionnerait comme vous l'avez votre argent total devrait être de 500 $ maintenant. Je doute que vous voulez que :)
Je vois où vous allez, mais je ne suis pas sûr que vos lignes par exemple avec ce que null est vraiment. Ce que je veux dire est, ce n'est pas nulle représente une « valeur inconnue », comme « X ». Si quelqu'un me dit que j'ai X dollars et j'ai ajouté 500 $, oui, je ne voudrais pas se retrouver avec 500 $. Mais je ne pense pas que nulle représente « X », elle représente (comme on dirait en VB), rien. Donc, ce n'est pas le cas où il y a un emplacement de mémoire inconnu que peut maintenir une valeur - nulle est très clairement rien. Donc, dans ce cas, si je n'ai rien et j'ai ajouté 500 $, je suis ok d'avoir 500 $. Nous sommes couper les cheveux bien sûr.
pour définir la valeur du total est juste
int? a = 10; int? b = null; a++; // Increment by 1, now a is 11. a = a * 10; // Multiply by 10, now a is 110. a = a + b; // Add b, now a is null.
Merci. Je nullables types un peu, et se sont heurtées à ce problème avec la propriété automatique initialisation un peu, mais jamais pris la peine de se demander pourquoi. Je suppose que cela est logique, même si je ne sais pas si je l'aurais fait de cette façon ...
Il y a une section bien sur les types nullables en C # en profondeur, entre autres détails intéressants de principalement C # 3, mais aussi un peu C # 1 et un peu plus sur C # 2. Un grand livre en effet.
L'idée de types nullables est que vous pouvez attribuer des valeurs nulles à des types de valeur :)
De MSDN :
Lorsque vous effectuez des comparaisons avec types nullables, si la valeur de l'un des les types nullables est nulle et la autre n'est pas, toutes les comparaisons évaluer false sauf pour! = (différent). Ce est important de ne pas supposer que parce qu'une comparaison particulière retourne à faux, le cas contraire renvoie true.
Ainsi, il fonctionne comme prévu.
Voici une seule ligne pour initialiser le premier appel et incrémenter après:
public void InitializeOrIncrement(decimal value)
{
// if Total is null then initialize, otherwise increment
Total = (Total == null) ? value : Total + value;
}
public decimal? Total { get; set; }
Total = (Total ?? 0) + 8;
Oui, je suppose que ce sens de marques. Tout semble funky. :)
total = (total ?? 0) + 8; peut être réécrite à Total = Total.GetValueOrDefault (0) + 8; dans la version .NET 4.5+
nul n'est pas la même chose que zéro. Zéro plus huit est huit ... mais nul plus huit? Toujours null. Tout comme l'infini, plus tout est encore l'infini - il est indéfini .
Vous trouverez que cela est universellement vrai nulle. Chaque base de données (au moins que j'ai jamais travaillé) vous donnera le même résultat.
décimal public? Total des {get; ensemble; }
Would quelque chose comme ce travail? Une sorte de initalization automatique si la valeur n'a pas encore été définie. P>
public decimal? Total
{
get { return this.totalValue;}
set
{
if(totalValue == null) { this.totalValue = 0;}
this.totalValue = value;
}
}
private decimal? totalValue;
... mais si vous n'êtes pas en utilisant les propriétés implémentées automatiquement alors pourquoi ne pas initialiser seulement votre champ de soutien dans le cadre de la déclaration de ce? décimal privé? totalValue = 0;
Ouais, avouons-le, la seule raison pour laquelle j'utilise les propriétés automatiques du tout est d'être paresseux à taper. (Objet non frappe - juste en tapant des doigts!) Si je devais le diviser, je voudrais juste défaut à 0.
Yooder, parce qu'il pourrait ne pas vouloir que la valeur soit 0, il peut souhaiter qu'il soit nul ... Robert, pas en fait si quelqu'un fixe Total à zéro, il sera réglé sur 0, puis remis à zéro dans ce cas, de la valeur "comme serait nulle. 0 est simplement utilisé comme initalizer paresseux.
Je sais qu'il est logique de faire
public decimal Total { get; set; }
Ouais, c'est en fait ce que je fini par changer mon code. Pour un total en cours d'exécution, il n'a vraiment pas de sens pour le total à jamais par nul vraiment, si vous pensez à ce sujet. Il est logique que les éléments qui sont ajoutés pour être potentiellement nulle, mais le total peut probablement toujours être> = 0. Discussion intéressante cependant.
Comme d'autres l'ont souligné, nul n'est pas égal à zéro. Bien qu'il puisse sembler plus commode pour un entier nul par défaut à zéro dans le long terme, il est susceptible de produire des résultats étranges que vous ne pouvez pas repérer jusqu'à ce qu'il soit trop tard.
Par exemple rapide, que l'un de vos flux de données échoue et renseigne votre jeu de résultats avec des valeurs nulles. Vos calculs traiteront les valeurs nulles comme des zéros et continuer à produire des résultats de . Comme les chiffres sont encore à venir, même si ils ont tort probablement, vous pourriez ne jamais remarqué que quelque chose ne critique pas.
« Ils n'ont pas été initialisé, donc bien sûr, ils sont nuls. » Ceci est le point crucial de votre confusion. Les propriétés sont automatiquement attribués initialement, dans ce cas, null. Vous raisonnez d'un mensonge: que la propriété est non affectée. La propriété est attribuée initialement. Il n'y a pas une telle chose comme une « propriété non affecté » en C #.
distinction intéressante. Il est également intéressant, vous pouvez trouver des milliers d'exemples de personnes se référant à des valeurs « initialisées à null » comme « non initialisée ». Alors peut-être une idée fausse de sa commune. Une chose que je suis curieux de savoir - si nous avons ce problème où nous ne voulons pas faire « null + 8 = 8 » ou « null && vrai == true », pourquoi est-ce qu'une exception ne soit pas levée lorsque ces types des choses sont faites? On dirait que cela pourrait peut-être empêcher certains difficiles à des erreurs de débogage.