Am 02.07.2014 23:56, schrieb clipka:
> Am 02.07.2014 21:43, schrieb Le_Forgeron:
>> Le 02/07/2014 20:49, clipka nous fit lire :
>>> Am 02.07.2014 19:58, schrieb Le_Forgeron:
>>>> Le 02/07/2014 19:37, clipka nous fit lire :
>>>>> Am 02.07.2014 19:23, schrieb Le_Forgeron:
>>>>>
>>>>>>> Can you please give me the output with ">>" corrected to "> >"?
>>>>>>> Thanks a
>>>>>>> lot!
>>>>>>>
>>>>>> Here it is, attached.
>>>>>
>>>>> Thanks. Next incarnation of feature/colour_model is ready for testing.
>>>>>
>>>>
>>>> It's getting bigger (here the clang version, as gcc is above 5M)
>>>
>>> Future versions will be in experimental/colour_model from now on.
>>>
>>
>> Beware, gcc errors once un-bzip2-ed is 1 699 869 bytes long in
>> errorcolor.txt.
>>
>> clang errors in the other file.
>
> I don't really understand why both gcc and clang insist that mColour is
> undefined, when it's a protected member of the publicly inherited base
> class.
>
> Let's see what the latest change does.

I think I got it; the problem is dependent base class name lookup. 
f9d1c6ba should solve the mColour problem, let's see what else crops up.

(I've found by now that the "nasty" part of the "nasty template stuff", 
which I was afraid might not work at all, isn't really that nasty, and 
is actually an established pattern going by the name of "Curiously 
Recurring Template Pattern", aka CRTP.)

Post a reply to this message