Je convertissez beaucoup de code de vb.net à c # et voici un autre problème à laquelle je pense que je pense recadré pendant la conversion.
if (sRow.Cells[1].Value == true)
Worked = "X";
else if (sRow.Cells[2].Value == true)
Vacation = "X";
else if (sRow.Cells[3].Value == true)
Sick = "X";
else if (sRow.Cells[4].Value == true)
Holiday = "X";
4 Réponses :
Erreur 7 Opérateur '==' ne peut pas être appliqué aux opérandes de type 'objet' et 'bool'
Cette erreur vous dit que:
opérateur '==' ne peut pas être appliqué aux opérandes de type 'objet' et 'bool'
valeur est de typeobjet , donc si vous souhaitez les comparer de cette manière, vous devrez la jeter.Alors, assurez-vous que le type sous-jacent S est en réalité un booléen, puis ... vider la comparaison explicite avec TRUE ou FAUX. C'est discutable et stylistique, mais sérieusement redondant et inutile. Seriez-vous jamais diriez-vous "si vrai est égal à vrai alors ..."? Non, probablement (espérons-le) non.
Le pédantisme est égaré; Vous pouvez réellement comparer avec quelque chose de significatif, comme "vrai" ou "oui" (si la cellule contient en fait une chaîne), ou 1 ou 0 s'il s'agit d'un nombre. Voir aussi programmeurs.stackexchange.com/q/12807
@RoberTHAREVEY: Ce n'est pas un pédantisme du tout; En comparant quelque chose qui est déjà un booléen à un booléen littéral afin de produire une expression booléenne est redondant, dans tous les sens du mot. Je ne vois pas comment votre déclaration suivante est de quelque façon pertinente lorsque nous parlons de booléens (que nous sommes): "Vous pouvez réellement comparer avec quelque chose de significatif, comme" vrai "ou" oui "(si la cellule fait, en fait, contient une chaîne), 1 ou 0 s'il s'agit d'un nombre. "
@RoberTharvey: J'ai vu le lien, bien que je ne suis pas sûr de ce que vous vouliez prouver de la sorte.
L'utilisation de == true est discutée dans les détails d'ajustement.
@RoberTharevey: Droite, je ne suis toujours pas sûr de ce que vous vouliez prouver par cela. Il est en fait redondant.
Eh bien, vous n'êtes clairement pas le seul à être dérangé par celui-ci. Ça n'a pas vraiment d'importance; C'est une préférence personnelle et est probablement optimisée par le compilateur de toute façon. Si cela se produit beaucoup, cela signifie qu'il y a un problème de dénomination.
@RoberTharvey: Bien sûr, et j'ai dit autant. Ce n'est évidemment pas une préoccupation de performance, je ne suis tout simplement pas un fan d'écriture de code redondant en général.
@RoberTharvey déjà un booléen? Pas dans le cas de NULL ou de DBNULL.
Êtes-vous sûr que ces valeurs sont de type Si oui, il suffit de lancer explicitement: p> bool code>? if ((bool)sRow.Cells[1].Value)
{
Worked = "X";
}
else if ((bool)sRow.Cells[2].Value)
{
Vacation = "X";
}
else if (sRow.Cells[3].Value)
{
Sick = "X";
}
else if ((bool)sRow.Cells[4].Value)
{
Holiday = "X";
}
Pourquoi avoir besoin de jeter Bool comme Bool?
@Andrew C # est strict avec la vérification du type de temps de compilation. si (objet) ne compilera pas, il doit être de type bool .
Merci, il suffit de ressembler si objet.property est booléen, ( srow.cells [1] .value dans ce cas), aucune erreur ne devrait se produire ou ne pas être moulée. Il est probablement d'une manière ou d'une autre un objet même s'il a été attribué booléen vrai ou faux.
@ADEWREW - C'est un chèque de temps de compilation, pas un chèque d'exécution. Nous savons que ce sera un booléen lorsque la demande est exécutée, mais le compilateur ne le sait pas à la compilation.
Je ne suis pas un fan de Ceci est une alternative fonctionnelle: p> si (x == true) code> généralement, mais en utilisant si (((((BOOL) srow.cells [1 ]value) code> ou si (convert.toboolcan (srow.cells [1 ]value)) code> semble assez opaque en termes de charge cognitive. object x = DBNull.Value;
if (true.Equals(x)); // False
if (Convert.ToBoolean(x)); // InvalidCastException: Object cannot be cast from DBNull to other types.
if ((bool)x); // InvalidCastException: Specified cast is not valid.