Clang ambiguous call (int, float, double)

Question

I have to compile an API on Mac using Clang that uses a construct similar to this:

#define TRUE 1

void func(int a) {
    // ...
}

void func(double a) {
    // ...
}

void func(float a) {
    // ...
}

func(TRUE);

Clang complains that the call to func() is ambiguous while MSVC and GCC don't. Is there an option for Clang that it will choose the integer variant in this case?

Edit: This is the original output of the compilation

../../resource/_api/c4d_basedocument.cpp:263:52: error: conversion from 'int' to 'const GeData' is ambiguous
        this->SetParameter(DescLevel(DOCUMENT_USERCHANGE),TRUE,DESCFLAGS_SET_DONTCHECKMINMAX);
                                                          ^~~~
../../resource/_api/ge_sys_math.h:21:15: note: expanded from macro 'TRUE'
        #define TRUE    1
                        ^
../../resource/_api/c4d_gedata.h:97:3: note: candidate constructor
                GeData(double n)
                ^
../../resource/_api/c4d_gedata.h:110:3: note: candidate constructor
                GeData(LONG n)
                ^
../../resource/_api/c4d_gedata.h:116:3: note: candidate constructor
                GeData(SReal n)
                ^

LONG is an integral type, SReal a floating point type.

Are you sure, that this full test? I have a lot of compilers on my machine, and clang 3.2, and clang 3.3 doesn't produce any warrnings or errors during compilation of your test. — fghj, Jul 14 '13 at 00:22
A related question http://stackoverflow.com/questions/3909406/colorint-int-int-vs-colorfloat-float-float-ambiguous-call?rq=1 mentions issues due to the integer that gets passed being in fact an unsigned. Is the #define you show above actually that simple? — fvu, Jul 14 '13 at 01:05
`TRUE` is a macro that expands to `1`; `1` has type `int`. There is no ambiguity. I strongly doubt that this is the actual code that produced the problem. — Pete Becker, Jul 14 '13 at 11:16
Thanks for your comments. I might misunderstand some technical details and maybe the boiled down example does not map 1-to-1 to the original case. I have added the compiler output! — Niklas R, Jul 14 '13 at 12:23

score 0 · Accepted Answer · answered Jul 14 '13 at 12:35

I had time to investigate more time in looking into the original build project and see that I was missing a compiler option. Interesting thing is, that it only results in additional definitions set which seems to solve the "ambiguousity".

-include _api/ge_mac_flags.h

Which looks like

#ifndef __GE_MAC_FLAGS__
#define __GE_MAC_FLAGS__

#define __MAC
#define __DEBUGGING__                                                                               // avoid conflicts with DebugAssert() definition for the Mac

#if __LP64__
    #define __C4D_64BIT
#endif

#endif

Solves it!

Clang ambiguous call (int, float, double)

1 Answers1