Simply including boost/bind.hpp causes compilation error
Here is my environment.
% g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5483~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5483)
Boost 1.35.0
(also produced same issue with Boost 1.34.1)
Here is the code.
1 #include
AMDG Ken Smith wrote:
Here is the code.
1 #include
2 #include 3 #if defined(INCLUDE_BOOST_BIND) 4 # include 5 #endif 6 #include <iostream> 7 #include <iterator> 8 #include <algorithm> 30 31 int main() 32 { 33 using namespace std; 34 using namespace boost::lambda; 35 36 typedef std::istream_iterator<int> in; 37 std::for_each(in(std::cin), in(), std::cout << (_1 * 3) << " " ); 76 } Any ideas?
Boost.Bind declares the placeholders _1, _2, etc at global scope. Boost.Lambda declares the placeholders _1, _2, and _3 in namespace boost::lambda. The use of _1 in this context is ambiguous. Try qualifying it. namespace bll = boost::lambda; (bll::_1 * 3) In Christ, Steven Watanabe
On Sat, May 10, 2008 at 9:12 AM, Steven Watanabe
Ken Smith wrote:
Here is the code.
1 #include
2 #include 3 #if defined(INCLUDE_BOOST_BIND) 4 # include 5 #endif 6 #include <iostream> 7 #include <iterator> 8 #include <algorithm> 30 31 int main() 32 { 33 using namespace std; 34 using namespace boost::lambda; 35 36 typedef std::istream_iterator<int> in; 37 std::for_each(in(std::cin), in(), std::cout << (_1 * 3) << " " ); 76 } Any ideas?
Boost.Bind declares the placeholders _1, _2, etc at global scope. Boost.Lambda declares the placeholders _1, _2, and _3 in namespace boost::lambda. The use of _1 in this context is ambiguous. Try qualifying it. namespace bll = boost::lambda;
(bll::_1 * 3)
Thanks for this idea. I was also able to solve this problem by changing using namespace boost::lambda; to using boost::lambda::_1; Ken
Steven Watanabe
Boost.Bind declares the placeholders _1, _2, etc at global scope.
We discussed this years ago. AFAICR Dave Abrahams terminated the discussion with a statement that clearly considered _1 in global namespace as a design error. At least this is how I understood his statemment. So here again someone falls over this. Years go by and nasty little oddities remain unfixed and - worse - undocumented (similar to multi_array not modeling Assignable like any good C++ container in this world). I would like to revoke this discussion in order to get this fixed once for all times: How and when can we get rid of _1 and bretheren in global namespace? Having bll be a second class citizen has driven me crazy more than once, letting me put explicit namespace prefixes everywhere, no longer using Koenig lookup anywhere. Of course the vicinity of fusion/phoenix/xpressive/proto complicates the situation, but we can fix this. std::tr1::placeholders::_1 points into the right direction. I am thinking of something like boost::placeholders::_, ...::_1, etc. So maybe the answer to all this is <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_tr1/ subject_list.html#boost_tr1.subject_list.bind>, but please, please remove *anything* from global namespace for boost-1.36 and tag boost::has_evolved_to_tr1* libs as deprecated in favor to the standardized version. Markus
Looks like you might be using the wrong bind.
Instead of the following header:
#include
Here is my environment.
% g++ -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5483~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5483)
Boost 1.35.0 (also produced same issue with Boost 1.34.1)
Here is the code.
1 #include
2 #include 3 #if defined(INCLUDE_BOOST_BIND) 4 # include 5 #endif 6 #include <iostream> 7 #include <iterator> 8 #include <algorithm> 30 31 int main() 32 { 33 using namespace std; 34 using namespace boost::lambda; 35 36 typedef std::istream_iterator<int> in; 37 std::for_each(in(std::cin), in(), std::cout << (_1 * 3) << " " ); 76 } (The astute reader will note discontinuity in the line numbering. This is a playground for my exploration with boost. All elided lines are #if 0'ed.
Here is the compile command line and the compilation error, both edited for clarity. g++ -c -g -Wall -fexceptions -DINCLUDE_BOOST_BIND -I/path/to/boost-1.35.0/include main.cpp -o main.o main.cpp: In function 'int main()': main.cpp:37: error: '_1' was not declared in this scope
I have seen these related articles from the archives of this list but none of the suggestions eliminated the error. I added the inclusion of boost/lambda/construct.hpp per one of the suggestions there. Its inclusion or exclusion doesn't change the behavior.
http://thread.gmane.org/gmane.comp.lib.boost.user/35128 http://thread.gmane.org/gmane.comp.lib.boost.user/16630 http://thread.gmane.org/gmane.comp.lib.boost.user/16887
As you may imagine, the elided (and commented out) lines contain actual uses of boost/bind.hpp but it is a mystery to me that simple inclusion of a header file would cause otherwise working code to stop compiling.
This compile command (same as above but with -D removed):
g++ -c -g -Wall -fexceptions -I/path/to/boost-1.35.0/include main.cpp -o main.o
runs to completion and the subsequent link is successful.
Any ideas?
Thanks in advance, Ken _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- View this message in context: http://www.nabble.com/Simply-including-boost-bind.hpp-causes-compilation-err... Sent from the Boost - Users mailing list archive at Nabble.com.
participants (4)
-
atifm -
Ken Smith -
Markus Werle -
Steven Watanabe