Re: [Boost-users] Visual C++ 2005 help installing Boost
I am having exactly the same problem as a previous user. Could you please show me how you fixed your boost build? I'm getting the following errors ...failed updating 120 targets ...skipped 80 targets... ...updated 847 targets... I don't know how to open the vsvars32.bat file in order to change the paths that Mr Kozicki suggested. Any help would be greatly appreciated. I have installed the latest SDK. Also, how do i get rid of the warnings? I know i need to define _SCL_SECURE_NO_DEPRECATE globally, but how do i do that exactly? Finally, how do i know i have a correct build install? How do i test it? Thank you Please send your response to hgeorgako@hotmail.com harry g.
Harry Georgakopoulos
I don't know how to open the vsvars32.bat file in order to change the paths that Mr Kozicki suggested.
just open C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat in notepad.
Any help would be greatly appreciated. I have installed the latest SDK. Also, how do i get rid of the warnings? I know i need to define _SCL_SECURE_NO_DEPRECATE globally, but how do i do that exactly?
in your project settings select Configuration Properties > C/++ > Preprocessor and append _SCL_SECURE_NO_DEPRECATE in Preprocessor Definitions box
Finally, how do i know i have a correct build install? How do i test it?
cd boost/status bjam B.
"Harry Georgakopoulos"
...failed updating 120 targets ...skipped 80 targets... ...updated 847 targets...
I had a problem compiling Boost non-header components with VC8 (actually, getting bjam to run the cl.exe) and I got them resolved only by specifying -sMSVC_ROOT and -sVISUALC AND undefining the MSVCDIR (I think...). Then again I have a side-by-side with both 7.1 and 8 and my VS2005 installation is spread over two hard drives.... I knew I was asking for trouble :) I suspect you have the same problem though -- either cl.exe is not run from the right place or include paths are out of whack. You might want to look closely at the commands bjam tries to execute. ...Max...
I am having a problem with Boost.Bind (1.33.1). Consider the following simplified code:
struct Bob {
void func() { }
};
void bob_test() {
typedef std::map
Alan M. Carroll wrote:
I am having a problem with Boost.Bind (1.33.1). Consider the following simplified code:
struct Bob { void func() { } }; void bob_test() { typedef std::map
BobMap; BobMap bob_map; std::for_each(bob_map.begin(), bob_map.end(), bind(&Bob::func, bind(&BobMap::value_type::second, _1))); } This fails to compile under DevStudio 8. The problem is the outer bound functor expects (Bob* const) but is passed (Bob const*).
This seems a straight forward use -- call the "func" method on every Bob instance in the map. I can get this to compile if I change the inner bind to "bind
(...)". Shouldn't the default return type of the binding of (R T::*) be (R&)? I looked through the bind and mem_fn documentation and didn't see any mention of that. The .* operator applied to a non-const T and a (R T::*) returns (R&), so it is implied that mem_fn of a data member does as well.
Unfortunately boost::bind is a bit simplistic and always has a fixed return
type. Since when the member pointer is bound there is no way to determine
whether it will be applied to a const or a non-const T, the default is the
conservative R const& that can be used with both (but may cause failures
upstream if the outer bind expects a R&.) I assumed that writing bind
Also, why does the error message refer to pointers and not references? Is that an artifact of compiler argument matching failure?
It's an implementation artifact of mem_fn. The proper overload taking T& doesn't match (the argument is const) and another unrelated overload (used for derived types and smart pointers) is selected.
At 06:31 PM 1/16/2007, Peter Dimov wrote:
I assumed that writing bind
won't be that big of a deal in the relatively rare cases where it's needed.
It sure beats not using bind(). I would recommend that the documentation be changed to reflect this, rather than claim compatibility with the .* operator as it does now. E.g. [...] where R is the return type of X::f (for member functions). For data members, the return value is by default (R const&) because the bind() generated functor must have this fixed upon creation, before it is known whether the argument will be const or not. If you need an lvalue, use the return type template argument of bind() to force the return type to be a non-const reference.
participants (5)
-
Alan M. Carroll
-
Bronek Kozicki
-
Harry Georgakopoulos
-
Max Motovilov
-
Peter Dimov