[Lumiera] time::Control Errors

Michael R Fisher mfisher31 at gmail.com
Sat Oct 22 20:34:33 CEST 2011


Got it.  Well at least I have a somewhat better understanding of what 
namespaces are for.  ok I'll wait to hear back.  Thanks dudes!

On 10/22/2011 01:24 PM, Ichthyostega wrote:
> Am 22.10.2011 11:39, schrieb Michael R Fisher:
>> Please bear with me on the C++ newbie crap. I swear I'll get over it.
> No need to apologize. We're all swearing because of compiler error messages.
> (Incidentally, Clang/LLVM has the reputation of generating way better messages;
>   maybe we'll consider to switch eventually, at least for day-to-day work.)
>
>> Not sure what ambiguous is all about.
> What you need to learn is "parsing" those horrible messages.
> Actually they are quite precise. Just the problem is paving your
> way through all this clutter and over-information.
>
> I'll show you what I mean with 'parsing':
>
>
>> In file (included from ...)
> ...
>> src/lib/time/control-policy.hpp:337:65:
>> error: call of overloaded 'ref(Duration&)' is ambiguous
>>   note: candidates are:
>>         std::tr1::reference_wrapper<T>  std::tr1::ref(T&)
>>         boost::reference_wrapper<T>        boost::ref(T&)
>> [with T = lib::time::Duration] in both cases
>
> So, isn't that a telling??  :-P
>
>
> Am 22.10.2011 17:18, schrieb Hendrik Boom:
>> You have two definitions of ref hanging around, from two different
>> packages.  Actually, looking at the message, they see to be from two
>> different templates, both defined in include files from the library.
> correct. That's what the compiler wants to say you ;-)
> The poor guy is bewildered about what 'ref()' function to call...
>
>
> Well... now the actual problem is that it wasn't you. You never used
> a call to a function called 'ref(..)'. Probably you never wanted to
> know such a thing even exists.
>
> It was some library writer (in this case, it was me) using that function.
> But because templates are quite "open" and evaluated in the current usage
> context, such internal library details often "leak", forcing the user
> to find out like a detective why something doesn't work as intended.
>
> If we now look again at the headers mentioned in the error message,
> in the lines naming the two alternatives, we see the two headers
> actually defining a 'ref()' function both
>
>> /usr/include/c++/4.5/tr1/functional:488:5:
>> /usr/include/boost/ref.hpp:64:63:
> Thus, as Hendrik pointed out precisely, it is some feature from Boost
> colliding with the similar feature meanwhile accepted into the standard.
> Btw, that is the rationale why I'm trying to push such cleanup-actions
> ahead, like the similar thing with the smart_ptr defined from both.
>
>
>> Do I need to put a using
>> namespace xxx; somwhere?
> Oh noez, please don't. It might look like an easy remedy, but actually
> that can cause a lot of further problems. Maybe it *is* already the root
> cause of our actual problem that someone (in this case, Joel) did write a
> "using namespace boost" in several of the fundamental GUI headers.
>
> This statement makes *everything* in namespace boost available without
> the 'boost::'' prefix. It is a way better practice just to include
> individual functions or classes, e.g.
>
> using std::tr1::ref
>
> Even better practice is to write that "using..." statement *into* an
> already opened namespace, and not at top level. This all serves the
> goal to avoid collisions.
>
> If you look into control-policy.hpp, you see that actually I put
> an 'using std::tr1::ref' into the local implementation namespace
> (namespace mutation). So the problem seems to be that another include
> covers that up.
>
> Of course, if all else fails, in this case (since the library function
> is from the same project) we could remedy the situation by explicitly
> qualifying those 'ref' functions. But I would rather try hard to avoid
> that, it would render the already complicated code harder to read.
>
>
> Thus, in this case I'd rather go in the opposite direction. Trying to
> find out why boost::ref got pulled in at all. Since, in this case,
> we know precisely that we don't need it, and the version from the
> new standard (std::tr1) is preferable.
>
> Here, some background knowledge is helpful, that's why I'll try to
> spot the problem right now. (I know already that the 'ref() function
> stems from the<boost/function>  library or the<std/function>)
>
> I'll report back when I've found out more
>
>
> Cheers
> Hermann
>
>
>



More information about the Lumiera mailing list