[Lumiera] time::Control Errors

Ichthyostega prg at ichthyostega.de
Sat Oct 22 20:24:57 CEST 2011


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