ternary operator and casting

[Bob Hoeppner]

In the following code

//add to bool or double Dictionary
this.m_unit.Add((unittype == "b")? unitnum:(double)unitnum);

The bool dictionary uses an integer index, the double uses a double
index, which some may take issue with, but that's a different
discussion. The problem is that unitnum is always cast to a double, even
when unittype is "b". That seems like a bug to me.

If I change it to

this.m_unit.Add((unittype == "d")? (double)unitnum:unitnum);

it still always casts it to a double. I'm annoyed that the ternary
operator always casts unitnum to a double.

(parenthetical discussion)

The object is to later be able to set values, like so

//1234 is a bool
Grp.Unit[1234] = true;
//4321 is a double
Grp.Unit[4321d] = 1.0;
//there is also a uint index for conversion between bool and double
//set bool from double
Grp.Unit[1234u] = 1.0;
//set double from bool
double myvalue = Grp.Unit[1234u];

but, like I said, that's not the discussion I want to have. There is a
lot of code, and it minimizes it, especially when dealing with
bool-to-double conversions.

*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

On Jul 16, 4:22*pm, Bob Hoeppner <[e-mail]:

In the following code

//add to bool or double Dictionary
this.m_unit.Add((unittype == "b")? unitnum:(double)unitnum);

The bool dictionary uses an integer index, the double uses a double
index, which some may take issue with, but that's a different
discussion. The problem is that unitnum is always cast to a double, even
when unittype is "b". That seems like a bug to me.

No - it's a flaw in your understanding of the conditional operator.

The conditional operator is (as you know) an expression of the form
a ? b : c. That expression is of a single type, in the end. Both the
subexpressions "b" and "c" have to be convertible to the overall type
of the expression, which (IIRC) is always either the type of b or the
type of c.

In your case, you end up with b and c being unitnum (type=int) and
(double)unitnum (type=double). int is implicitly convertible to
double, but not vice versa - so the overall type of the expression is
double. That means you always get the Add(double) overload being
called, and there is indeed always a conversion.

Assuming the Add method is overloaded (once for int and once for
double) then you need to have two different method calls to get it to
work. Any one method call will only resolve to a single overload.

Then again, it's quite strange to see an overload like that, so it's
possible that my assumptions about the type of m_unit are incorrect.
If the explanation above hasn't helped you, could you provide a short
but complete program which demonstrates the problem?

Jon

[Peter Duniho]

On Wed, 16 Jul 2008 08:22:32 -0700, Bob Hoeppner <bo*****@hotmail.com
wrote:

In the following code

//add to bool or double Dictionary
this.m_unit.Add((unittype == "b")? unitnum:(double)unitnum);

The bool dictionary uses an integer index, the double uses a double
index, which some may take issue with, but that's a different
discussion. The problem is that unitnum is always cast to a double, even
when unittype is "b". That seems like a bug to me.

It's not a bug. The type of the expression has to be determined at
compile-time, so the compiler cannot take into account possible
differences in the two possible outcomes of the operator. It has to
resolve the entire expression into a single, compile-time type. It does
this by choosing the type that both possible outcomes can be converted
to. There's no implicit conversion from double to int, but there's an
implicit conversion from int to double, so double wins.

Assuming "unitnum" is an integer variable, then I'm not clear on why
you're casting in the first place. Where the expression needs to resolve
to a double, the implicit conversion should handle that for you.

Beyond that, I'm not entirely sure that the use of a double is "a
different discussion". To some extent, this is an issue for you because
you are trying to treat two different collections as the same, so there's
at least that. The other issue is that a dictionary is going to use
equality for matching keys, but floating point values are poor candidates
for equality comparisons.

In other words, you do in fact have a potential design issue that has led
to this dilemma, and fixing that design issue may in fact cause your
immediate question to become moot.

Pete

[Bob Hoeppner]

Yes, I see my understanding was flawed. It makes sense the one ternary
operator would have to return one datatype. This demonstrates that the
ternary operator is not an exact shorthand equivalent for an if/else
statement. Thanks.

*** Sent via Developersdex http://www.developersdex.com ***

[Bob Hoeppner]

Yes, I see my understanding was flawed. It makes sense the one ternary
operator would have to return one datatype. This demonstrates that the
ternary operator is not an exact shorthand equivalent for an if/else
statement. Thanks.

Yes, I'm treating two collections as similarly as possible. There are
many bools and fewer doubles. Also, there is a lot of assigning of bools
to doubles and doubles to bools, due to the nature of the two systems
I'm interfacing. I'm aware it's a quirky design decision, and it's not
one I made on my own. The upside is that there is less code and more
convenience; the downside is that it may be trickier for humans to read
the code, and there is a slight performance penalty for using doubles as
an index. If it proves to be insupportable we can refactor it. Thanks
again.

*** Sent via Developersdex http://www.developersdex.com ***

[Ignacio Machin ( .NET/ C# MVP )]

On Jul 16, 1:29*pm, Bob Hoeppner <[e-mail]:

Yes, I see my understanding was flawed. It makes sense the one ternary
operator would have to return one datatype. This demonstrates that the
ternary operator is not an exact shorthand equivalent for an if/else
statement. Thanks.

Yes, I'm treating two collections as similarly as possible. There are
many bools and fewer doubles. Also, there is a lot of assigning of bools
to doubles and doubles to bools, due to the nature of the two systems
I'm interfacing. I'm aware it's a quirky design decision, and it's not
one I made on my own. The upside is that there is less code and more
convenience; the downside is that it may be trickier for humans to read
the code, and there is a slight performance penalty for using doubles as
an index. If it proves to be insupportable we can refactor it. Thanks
again.

*** Sent via Developersdexhttp://www.developersdex.com***

I find a little weird that double to bool (and viceversa) asignation.
considering that bool as only two possible values.

could you explain a little more what are you doing?

[Michael A. Covington]

this.m_unit.Add((unittype == "b")? unitnum:(double)unitnum);

>
The bool dictionary uses an integer index, the double uses a double
index, which some may take issue with, but that's a different
discussion. The problem is that unitnum is always cast to a double, even
when unittype is "b". That seems like a bug to me.

I just looked in the C# Annotated Standard...

The semantics of the ternary operator requires the type of the expression to
be determined at compiled time. So (condensing several rules into one
sentence) it is whatever is compatible with both of the expressions after
the ? .

[Bob Hoeppner]

I've entered into that discussion on this thread

http://www.developersdex.com/csharp/...1111&r=6224121
Suffice it to say that the overloading of the indexers allows some more
concise code by people programming to the class, which is how those
coding to it prefer. We went over the various ways it could be
implemented. Some lines can get quite long. Here's a shorter one:

Grp.Unit[2770] = FUN(Grp.Unit[772] && !Grp.Unit[2771], ref
Grp.Unit[1800d], Grp.Unit[773d]); // Line 1290

which isn't much of an advantage over, say,

Grp.UnitB[2770] = FUN(Grp.UnitB[772] && !Grp.UnitB[2771], ref
Grp.UnitD[1800], Grp.UnitD[773]); // Line 1290

but when going between booleans and doubles, is, as described in my post
in the other thread.


*** Sent via Developersdex http://www.developersdex.com ***

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Bob Hoeppner wrote:

Yes, I see my understanding was flawed. It makes sense the one ternary
operator would have to return one datatype. This demonstrates that the
ternary operator is not an exact shorthand equivalent for an if/else
statement.

I think you in general should avoid ?: with different data typesto keep
the code easy to read.

Arne