Integer and float overloads causing compile errors


Please excuse my ignorance, but I’m having the dickens of a time constructing a transparent Colour:

  t->setColour( Label::outlineColourId, Colour( 255, 255, 255, 0.5 ) );


d:\source.cpp(38) : error C2668: 'juce::Colour::Colour' : ambiguous call to overloaded function
        d:\juce_tip\src\gui\graphics\colour\juce_colour.h(114): could be 'juce::Colour::Colour(float,float,float,float) throw()'
        d:\juce_tip\src\gui\graphics\colour\juce_colour.h(104): or       'juce::Colour::Colour(float,float,float,juce::uint8) throw()'
        d:\juce_tip\src\gui\graphics\colour\juce_colour.h(87): or       'juce::Colour::Colour(juce::uint8,juce::uint8,juce::uint8,float) throw()'
        d:\juce_tip\src\gui\graphics\colour\juce_colour.h(71): or       'juce::Colour::Colour(juce::uint8,juce::uint8,juce::uint8,juce::uint8) throw()'
        while trying to match the argument list '(int, int, int, double)'

This also happens if I specify the transparency using an integral type:

  t->setColour( Label::outlineColourId, Colour( 255, 255, 255, 128 ) );

So…if I am just doing something dumb please let me know!


The easiest fix is to just be explicit with the parameter types. Bung (uint8) before ints and use an f suffix for floats (e.g. 0.5f).


What good are those constructors then? I’ve been using Colour::fromRGBA() as a workaround.


er… I don’t understand the question. What good are they? They’re perfectly good. They’re used by the function you’re choosing to use instead (which I presume exists to help with this kind of ambiguity). It’s not like they need to be hidden or anything, they’re fine.


just use 0.5f as the last parameter, you don’t need to use (uint8)255 for the others . 0.5 is interpreted as a double, using 0.5f explicity sets it as a float.


fwiw, that’s what I wrote initially, but the second bit about 4 int-looking params not being picked up as the 4 int constructor seemed a little odd


The compiler is moaning about this for your own good.

When you see “Colour (255, 255, 255, 255)” in someone else’s code, then sure, it’s obvious to you as a human that it’s talking about integers. But what if you saw “Colour (1, 1, 1, 1)” ? How could you be sure that the programmer wasn’t actually trying to create a solid white colour? By forcing you to either add an explicit typename, or to use a named method like fromRGBA(), it prevents you making stupid typos, and also makes the code clearly show what your intention was.