Integer and float overloads causing compile errors


#1

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 ) );

produces

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!


#2

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).


#3

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


#4

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.


#5

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.


#6

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


#7

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.