Re: [boost] boost::iterator_range header surgery

From: Maxim Yanchenko (maximyanchenko_at_[hidden])
Date: 2008-07-13 23:39:13

David Abrahams <dave <at> boostpro.com> writes:

> Isn't this a bit of an invitation to ODR violations?
> 
>       // TU1
>       #include "MaximIO.hpp"
>       #include "boost/range/iterator_range.hpp"
>       #include "LibraryThatPrints.hpp"
> 
>       print(some_iterator_range);
> 
>       // TU2
>       #include "boost/range/iterator_range_io.hpp"
>       #include "boost/range/iterator_range.hpp"
>       #include "LibraryThatPrints.hpp"
> 
>       print(some_iterator_range);
> 
> If the print template calls different IO functions in these two
> translation units, that's an ODR violation.

Hi David, that's a good question, and it also addresses boost.tuple and other
libraries with detachable io (and detachable anything).

In my case, there is no direct ODR violation, as there is actually no print
function, but an operator<< living in a separate namespace instead.
So when you include "MaximIO.hpp" and use "using MaximIO::operator<<" all your
calls to operator<< will be resolved to MaximIO::operator<<, and everything else
will be found with help of ADL. But if you include
"boost/range/iterator_range_io.hpp" at the same time, you'll get the ambiguity
error (that's what I faced).

But you are right, if anybody defines a function print without specifying
explicitly which io engine to use inside it (pretty common for a general print
function), it's easy to get ODR violation here.

> Just wondering if there isn't a deeper modularity issue lurking here to
> be solved.

Of course, when you start using template and inline functions, there is wide
area for ODR violation (due to dependency of headers inclusion), for example,
ODR can be violated somewhere deep inside my operator<< and the functions it
calls.

I don't see any 100% safe way to ensure ODR correctness and preserve high
modularity, at least now.
I see more or less awkward ways like #ifdefs for inclusion control, or passing
explicit functors everywhere where we need anything custom instead of defining
ODR-fragile entities. Traits are also not very safe here unless they are trivial
and very carefully written.

Thanks,
Maxim

P.S. Please write private e-mails to gmail.com