Incompatible operand types when using ternary conditional operator

Question

This code:

  bool contains = std::find(indexes.begin(), indexes.end(), i) != indexes.end();
  CardAbility* cardAbility = contains ? new CardAbilityBurn(i) : new CardAbilityEmpty;

gives me the following error:

Incompatible operand types CardAbilityBurn and CardAbilityEmpty

However if I write the code like this:

 if (contains)
 {
    cardAbility = new CardAbilityBurn(i);
 }
 else
 {
    cardAbility = new CardAbilityEmpty;
 }

then the compiler doesn't mind. Why so? I want to use ternary conditional operator because it is just one line. What's wrong there?

I need to note (I think you might need this information) that CardAbilityEmpty and CardAbilityBurn both derive from CardAbility so they are so to say brothers.

Thanks

Essentially same issue as http://stackoverflow.com/questions/24706480. Simplest fix is to explicitly convert one of them to `CardAbility*`. — T.C., Apr 24 '15 at 08:16
Which compiler do you use? On VS2008 it works with derived classes. — Valentin H, Apr 24 '15 at 08:21
possible duplicate of [Why does std::istringstream appear to resolve differently to std::ifstream in the ternary (?:) operator?](http://stackoverflow.com/questions/24706480/why-does-stdistringstream-appear-to-resolve-differently-to-stdifstream-in-th) — Rick Smith, May 21 '15 at 21:00

Quentin · Accepted Answer · 2015-08-03T13:01:50.167

C++'s type system determines expressions' types from the inside out^[1]. That means that the conditional expression's type is determined before the assignment to CardAbility* is made, and the compiler has to choose with only CardAbilityBurn* and CardAbilityEmpty*.

As C++ features multiple inheritance and some more possible conversion paths, since none of the types is a superclass of the other the compilation stops there.

To compile successfully, you need to provide the missing part : cast one or both operands to the base class type, so the conditional expression as a whole can take that type.

auto* cardAbility = contains
    ? static_cast<CardAbility*>(new CardAbilityBurn(i))
    : static_cast<CardAbility*>(new CardAbilityEmpty  );

(Note the use of auto, since you already provided the destination type in the right-side expression.)

It is however a bit convoluted, so in the end the if-else structure is better-suited in this case.

[1] There is one exception : overloaded function names have no definitive type until you convert them (implicitly or explicitly) to one of their versions.

score 2 · Answer 2 · answered Apr 24 '15 at 08:34

There are several cases described for Microsoft compilers, how to handle operand types.

If both operands are of the same type, the result is of that type.

If both operands are of arithmetic or enumeration types, the usual arithmetic conversions (covered in Arithmetic Conversions) are performed to convert them to a common type.

If both operands are of pointer types or if one is a pointer type and the other is a constant expression that evaluates to 0, pointer conversions are performed to convert them to a common type.

If both operands are of reference types, reference conversions are performed to convert them to a common type.

If both operands are of type void, the common type is type void.

If both operands are of the same user-defined type, the common type is that type.

If the operands have different types and at least one of the operands has user-defined type then the language rules are used to determine the common type. (See warning below.)

And then there is a caution:

If the types of the second and third operands are not identical, then complex type conversion rules, as specified in the C++ Standard, are invoked. These conversions may lead to unexpected behavior including construction and destruction of temporary objects. For this reason, we strongly advise you to either (1) avoid using user-defined types as operands with the conditional operator or (2) if you do use user-defined types, then explicitly cast each operand to a common type.

Probably, this is the reason, Apple deactivated this implicit conversion in LLVM.

So, if/else seems to be more appropriate in your case.

He isn't using operands of some user defined type. He is using operands that are pointers. There will be no conversion of objects. There would be at most a conversion of pointers to a different type, which the compiler then refuses to do. It doesn't convert two object pointers to a pointer to a common superclass. — gnasher729, Apr 24 '15 at 08:39
The third use case in MS compilers is applied - conversion on pointers, which may not bi implemented in LLVM. Nothing is said about conversion of objects. — Valentin H, Apr 24 '15 at 10:49

Incompatible operand types when using ternary conditional operator

2 Answers2

Linked