Re: [boost] boost and vendor's TR1 implementations

Subject: Re: [boost] boost and vendor's TR1 implementations
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-12 15:00:24

on Wed Nov 12 2008, Sergey Sadovnikov <flex_ferrum-AT-artberg.ru> wrote:

> Absolutely right, but...
> Let's see an example. Just get the one of the boost test cases
> (http://www.boost.org/doc/libs/1_37_0/libs/function/test/lambda_test.cpp)and try to compile with gcc 4.3.2:

I would never claim that all the Boost test cases follow a good
practice.

> -----------------------------------------------------------------------
> // Boost.Function library
>
> //  Copyright Douglas Gregor 2002-2003. Use, modification and
> //  distribution is subject to the Boost Software License, Version
> //  1.0. (See accompanying file LICENSE_1_0.txt or copy at
> //  http://www.boost.org/LICENSE_1_0.txt)
>
> // For more information, see http://www.boost.org
>
> #include <iostream>
> #include <cstdlib>
>
> #include <boost/test/minimal.hpp>
> #include <boost/lambda/lambda.hpp>
> #include <boost/lambda/bind.hpp>
> #include <boost/function.hpp>
>
> using namespace std;
> using namespace boost;
> using namespace boost::lambda;
>
> static unsigned
> func_impl(int arg1, bool arg2, double arg3)
> {
>   return abs (static_cast<int>((arg2 ? arg1 : 2 * arg1) * arg3));
> }
>
> int test_main(int, char*[])
> {
>   function <unsigned(bool, double)> f1 = bind(func_impl, 15, _1, _2);
>   function <unsigned(double)>       f2 = bind(f1, false, _1);
>   function <unsigned()>             f3 = bind(f2, 4.0);
>
>   f3();
>
>   return 0;
> }

This would also fail if you include <boost/bind.hpp>

> Compiler says:
> P:\projects\Tests\Sandbox\C++0x\gcc43>g++ -std=c++0x -IP:\projects\common\boost_1.36.0
> boost_test1.cpp
> boost_test1.cpp: In function 'int test_main(int, char**)':
> boost_test1.cpp:30: error: reference to 'function' is ambiguous

<snip>

> As you can see <tr1/functional> header isn't explicitly included but
> compilation was failed.

Yes.

> I mean that code which is conform to the some boost examples or other
> *same* guidelines which explicitly or implicitly expose both 'boost' and
> 'std' namespaces into global or local scope could become
> automatically uncompilable...

Yes, really, I understood the problem the first time you described it.
It's very bad, for people with code like that.  I argued once with Herb
that using directives are a bad idea in general, and he said, "if your
code breaks, you just add qualification and fix it."  So I can't account
for any programming guidelines he's given that sanction using
directives.  In the few cases where it's okay, you have tight control
over the future evolution of each namespace involved, so you know that
collisions won't happen.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com