VC10 config - some regressions in several libraries
Just a note that the recent changes to the VC10 config has produced several regressions in a number of libraries - I think these are all related to the use the rvalue references and move semantics. At present I can't say whether these are caused by bugs in VC10 rendering it's rvalue refs unusable (in which case we need a better test case in Boost.Config), or whether our library code isn't mature/portable enough yet given that this is a new and relatively untried feature. Can library authors making use of this feature investigate so we can decide what should be done here? Thanks! John.
Looking at the test results, a bunch of the tests that are failing on VC10 are also failing on GCC 4.5 in C++0x mode. Seems to be related to this: http://article.gmane.org/gmane.comp.lib.boost.devel/203080
Looking at the test results, a bunch of the tests that are failing on VC10 are also failing on GCC 4.5 in C++0x mode.
Seems to be related to this: http://article.gmane.org/gmane.comp.lib.boost.devel/203080
OK seems to be a problem with our code then :-( Hopefully this will be an incentive for folks to fix things up. Thanks, John.
On 26/04/2010 12:20, John Maddock wrote:
Looking at the test results, a bunch of the tests that are failing on VC10 are also failing on GCC 4.5 in C++0x mode.
Seems to be related to this: http://article.gmane.org/gmane.comp.lib.boost.devel/203080
OK seems to be a problem with our code then :-(
Hopefully this will be an incentive for folks to fix things up.
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types. Best, Ion
Ion Gaztañaga wrote:
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types.
Best,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have find the same answer in http://stackoverflow.com/questions/2681959/problem-with-moveable-only-types-... . It seems you need to add \Za to get complete move semantic. Best, Vicente -- View this message in context: http://old.nabble.com/VC10-config---some-regressions-in-several-libraries-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types.
It seems some explicit casts are required, for example in boost/interprocess/detail/move.hpp: template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return t; } Should be either: template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return std::move(t); } or template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return static_cast<typename remove_reference<T>::type&&>(t); } Likewise for the "forward" function. However that still leaves errors deep within the Boost.Preprocessor code: 1> adaptive_node_pool_test.cpp 1>m:\data\boost\trunk\boost\preprocessor\iteration\detail\local.hpp(37): error C2664: 'boost::interprocess::forward' : cannot convert parameter 1 from 'boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType> ' to 'boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType> *&&' 1> with 1> [ 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, 1> IndexType=boost::interprocess::iset_index 1> ] 1> You cannot bind an lvalue to an rvalue reference 1> m:\data\boost\trunk\libs\interprocess\test\node_pool_test.hpp(146) : see reference to function template instantiation 'T *boost::interprocess::detail::named_proxy<SegmentManager,T,is_iterator>::operator ()<boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>*>(P0 &&) const' being compiled 1> with 1> [ 1> T=node_pool_t, 1> SegmentManager=boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>,boost::interprocess::iset_index>, 1> is_iterator=false, 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, 1> IndexType=boost::interprocess::iset_index, 1> P0=boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>,boost::interprocess::iset_index> * 1> ] 1> m:\data\boost\trunk\libs\interprocess\test\adaptive_node_pool_test.cpp(24) : see reference to function template instantiation 'bool boost::interprocess::test::test_all_node_pool<node_pool_t>(void)' being compiled Which appear to have the same cause, but I'm unable to figure out what needs changing. Seems likely that gcc in C++0x mode has the same issues - creating an rvalue ref needs an explicit cast. HTH, John.
On 26/04/2010 18:05, John Maddock wrote:
Which appear to have the same cause, but I'm unable to figure out what needs changing.
Seems likely that gcc in C++0x mode has the same issues - creating an rvalue ref needs an explicit cast.
Ok, I'll need some time to discover what's happening, install those compilers and test the library. I'm afraid GCC 4.5 & MSVC-10.0 should work in emulation mode for the moment or mark them as unsupported. I'm trying to solve all these issues for the upcoming Boost.Move candidate review, so I expect to fix this ASAP. Best, Ion
This is "rvalue references v2", supported by VC10 RTM and GCC 4.5. rrv2 prohibits rvalue references from binding to lvalues, and additionally permits casting lvalues to rvalues without creating temporaries; see http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2009/n2844.html#changes . Writing code that works under rvalue references v1 and v2 simultaneously is generally easy. In particular, the move semantics and perfect forwarding idioms are unaffected. However, extreme caution must be used when reimplementing std::move() and std::forward(). Having struggled with this (during VC10's development, as we switched from v1 to v2, our Standard Library implementation had to cope with both), I recommend having separate implementations for v1 and v2 with a compiler version check. Because rrv1 created temporaries when casting lvalues to rvalues, I don't believe it's possible to write a move() that works under both v1 and v2, but I could be wrong. Stephan T. Lavavej Visual C++ Libraries Developer -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, April 26, 2010 9:06 AM To: boost@lists.boost.org Subject: Re: [boost] VC10 config - some regressions in several libraries
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types.
It seems some explicit casts are required, for example in boost/interprocess/detail/move.hpp: template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return t; } Should be either: template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return std::move(t); } or template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return static_cast<typename remove_reference<T>::type&&>(t); } Likewise for the "forward" function. However that still leaves errors deep within the Boost.Preprocessor code: 1> adaptive_node_pool_test.cpp 1>m:\data\boost\trunk\boost\preprocessor\iteration\detail\local.hpp(37): error C2664: 'boost::interprocess::forward' : cannot convert parameter 1 from 'boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType> ' to 'boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType> *&&' 1> with 1> [ 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, 1> IndexType=boost::interprocess::iset_index 1> ] 1> You cannot bind an lvalue to an rvalue reference 1> m:\data\boost\trunk\libs\interprocess\test\node_pool_test.hpp(146) : see reference to function template instantiation 'T *boost::interprocess::detail::named_proxy<SegmentManager,T,is_iterator>::operator ()<boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>*>(P0 &&) const' being compiled 1> with 1> [ 1> T=node_pool_t, 1> SegmentManager=boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>,boost::interprocess::iset_index>, 1> is_iterator=false, 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, 1> IndexType=boost::interprocess::iset_index, 1> P0=boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>,boost::interprocess::iset_index> * 1> ] 1> m:\data\boost\trunk\libs\interprocess\test\adaptive_node_pool_test.cpp(24) : see reference to function template instantiation 'bool boost::interprocess::test::test_all_node_pool<node_pool_t>(void)' being compiled Which appear to have the same cause, but I'm unable to figure out what needs changing. Seems likely that gcc in C++0x mode has the same issues - creating an rvalue ref needs an explicit cast. HTH, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 26/04/2010 21:19, Stephan T. Lavavej wrote:
Because rrv1 created temporaries when casting lvalues to rvalues
Yes, I think I should have two move implementations, because for GCC 4.3 casting to rvalue reference also creates a temporary, just like with Beta MSVC-10 (rrv1). For both latest GCC and MSVC I think std::forward implementation #5 from N2951 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html) should work correctly. Thanks again, Ion
Ion Gaztañaga wrote:
On 26/04/2010 21:19, Stephan T. Lavavej wrote:
Because rrv1 created temporaries when casting lvalues to rvalues
Yes, I think I should have two move implementations, because for GCC 4.3 casting to rvalue reference also creates a temporary, just like with Beta MSVC-10 (rrv1).
For both latest GCC and MSVC I think std::forward implementation #5 from N2951 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html) should work correctly.
Thanks again,
Ion
Except that VC10 does not implement function template default arguments, so you will have to tweak it somewhat. :-( Bo Persson
On 26/04/2010 21:19, Stephan T. Lavavej wrote:
Writing code that works under rvalue references v1 and v2 simultaneously is generally easy. In particular, the move semantics and perfect forwarding idioms are unaffected. However, extreme caution must be used when reimplementing std::move() and std::forward().
I general I found both approaches similar but I can't port the following to v2. For "emplace" functions, is more efficient in terms of code size, to catch all references and pack them in a polymorphic class and so that the same binary code could be used for value all non value-constructing code. I imagine there are similar use cases for std::function or bind, where we want to catch all input parameters by reference and use them later. This was possible with v1 just storing some "T &&member_x" members in a class using forward (at least in gcc 4.3). However, I can't achieve this with VC 10 (I haven't tested gcc 4.5), because the compiler complains (it's surely right) about warning C4413. Here's the code (a simplified "emplace" function): //store_and_forward_func takes a Target type, catches all references, //packs them in store_and_forward class, and calls a deferred call //using the stored arguments: class int_holder { int _i; public: int_holder(const int &i) { _i = i; } int_holder(int &&i) { _i = i; i = 0;} void func(){} }; template<class Target, class Arg> struct store_and_forward { Arg &&ref; //Stores a reference for further forwarding store_and_forward(Arg &&r) //warning C4413: reference member is initialized to a temporary //that doesn't persist after the constructor exits : ref(static_cast<Arg&&>(r)) { //No warning with the same cast! //Correct binding Arg&& a = static_cast<Arg&&>(r); } void call() { Target a(static_cast<Arg&&>(ref)); a.func(); } }; template<class Target, class Arg> void store_and_forward_func(Arg &&r) { struct store_and_forward<int_holder, Arg> fwd(static_cast<Arg&&>(r)); fwd.call(); } int main () { //This should lead to a compilation error const int & cref = 1; //Ok store_and_forward_func<int_holder>(cref); //Bad forwarding, member reference is not bound //to the temporary int(6) store_and_forward_func<int_holder>(int(6)); return 0; } A very similar code was possible with v1, but I can't get it work for v2. Best, Ion
Ion Gaztañaga wrote:
On 26/04/2010 21:19, Stephan T. Lavavej wrote:
Writing code that works under rvalue references v1 and v2 simultaneously is generally easy. In particular, the move semantics and perfect forwarding idioms are unaffected. However, extreme caution must be used when reimplementing std::move() and std::forward().
I general I found both approaches similar but I can't port the following to v2. For "emplace" functions, is more efficient in terms of code size, to catch all references and pack them in a polymorphic class and so that the same binary code could be used for value all non value-constructing code. I imagine there are similar use cases for std::function or bind, where we want to catch all input parameters by reference and use them later.
This was possible with v1 just storing some "T &&member_x" members in a class using forward (at least in gcc 4.3). However, I can't achieve this with VC 10 (I haven't tested gcc 4.5), because the compiler complains (it's surely right) about warning C4413. Here's the code (a simplified "emplace" function):
//store_and_forward_func takes a Target type, catches all references, //packs them in store_and_forward class, and calls a deferred call //using the stored arguments:
class int_holder { int _i; public: int_holder(const int &i) { _i = i; }
int_holder(int &&i) { _i = i; i = 0;}
void func(){} };
template<class Target, class Arg> struct store_and_forward { Arg &&ref; //Stores a reference for further forwarding store_and_forward(Arg &&r) //warning C4413: reference member is initialized to a temporary //that doesn't persist after the constructor exits : ref(static_cast<Arg&&>(r)) { //No warning with the same cast! //Correct binding Arg&& a = static_cast<Arg&&>(r); }
void call() { Target a(static_cast<Arg&&>(ref)); a.func(); } };
template<class Target, class Arg> void store_and_forward_func(Arg &&r) { struct store_and_forward<int_holder, Arg> fwd(static_cast<Arg&&>(r)); fwd.call(); }
int main () { //This should lead to a compilation error const int & cref = 1; //Ok store_and_forward_func<int_holder>(cref); //Bad forwarding, member reference is not bound //to the temporary int(6) store_and_forward_func<int_holder>(int(6)); return 0; }
A very similar code was possible with v1, but I can't get it work for v2.
Best,
Ion
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above? Somewhat unrelated to the above confusion, would a possible workaround be to store the references just as lvalue references (and using the type information to forward them as rvalue references)? I.e., does ... Arg& ref; // lvalue reference whether Arg is an object or rvalue reference or lvalue reference type store_and_forward(Arg&& r) // Arg&& is an rvalue reference if Arg is an object or rvalue reference type, lvalue reference if Arg is an lvalue reference type : ref(r) { } ... work? The expression "r" is, in fact, an lvalue reference to the actual object, regardless of its declared type in the constructor parameter list, right? Maybe I don't know rvalue references as well as I had thought... :/ - Jeff
Jeffrey Hellrung: ...
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above? ... Maybe I don't know rvalue references as well as I had thought... :/
I don't think that casting a T (rvalue or lvalue) to T&& was ever supposed to create a temporary; it's always a direct reference binding. This is not a rrv1 vs rrv2 issue; it looks like a plain compiler bug.
On 29/04/2010 20:35, Peter Dimov wrote:
Jeffrey Hellrung: ...
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above? ... Maybe I don't know rvalue references as well as I had thought... :/
I don't think that casting a T (rvalue or lvalue) to T&& was ever supposed to create a temporary; it's always a direct reference binding. This is not a rrv1 vs rrv2 issue; it looks like a plain compiler bug.
Compiles fine and prints "6" in GCC 4.5.0 Best, Ion #include <iostream> //store_and_forward_func takes a Target type, catches all references, //packs them in store_and_forward class, and calls a deferred call //using the stored arguments: class int_holder { int _i; public: int_holder(const int &i) { _i = i; } int_holder(int &&i) { _i = i; i = 0; std::cout << _i << std::endl; } void func(){} }; template<class Target, class Arg> struct store_and_forward { Arg &&ref; //Stores a reference for further forwarding store_and_forward(Arg &&r) : ref(static_cast<Arg&&>(r)) {} void call() { Target a(static_cast<Arg&&>(ref)); a.func(); } }; template<class Target, class Arg> void store_and_forward_func(Arg &&r) { struct store_and_forward<int_holder, Arg> fwd(static_cast<Arg&&>(r)); fwd.call(); } int main () { //This should lead to a compilation error const int & cref = 1; //Ok store_and_forward_func<int_holder>(cref); //Bad forwarding, member reference is not bound //to the temporary int(6) store_and_forward_func<int_holder>(int(6)); return 0; }
On 29/04/2010 20:00, Jeffrey Hellrung wrote:
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above?
Yes, it's something strange, but I think this seems a compiler bug. This makes some porting to MSVC-10.0 a bit harder. One option is to store all the addresses in pointers and cast them back somehow without bitting this bug. I'll try to getg some GCC 4.5 binary for MinGW to see what happens. If someone can test it before I find and install it, please let me know. Best, Ion
Ion Gaztañaga wrote:
On 29/04/2010 20:00, Jeffrey Hellrung wrote:
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above?
Yes, it's something strange, but I think this seems a compiler bug. This makes some porting to MSVC-10.0 a bit harder. One option is to store all the addresses in pointers and cast them back somehow without bitting this bug.
To reiterate: is it possible to just use a lvalue reference for the member variable? - Jeff
On 29/04/2010 22:01, Jeffrey Hellrung wrote:
To reiterate: is it possible to just use a lvalue reference for the member variable?
I don't think so, because we would lose the rvalueness of the catched parameter and we could not longer distinguish between passed lvalue or lvalu references to forward them correctly. Best, Ion
Ion Gaztañaga wrote:
On 29/04/2010 22:01, Jeffrey Hellrung wrote:
To reiterate: is it possible to just use a lvalue reference for the member variable?
I don't think so, because we would lose the rvalueness of the catched parameter and we could not longer distinguish between passed lvalue or lvalu references to forward them correctly.
I thought the rvalue- or lvalue-ness was encoded in the type of the template parameter Arg? I.e., Arg = T& or Arg = T const& is an lvalue reference; Arg = T (no reference qualifiers) or Arg = T&& is an rvalue reference. - Jeff
On 29/04/2010 22:46, Jeffrey Lee Hellrung, Jr. wrote:
I thought the rvalue- or lvalue-ness was encoded in the type of the template parameter Arg? I.e., Arg = T& or Arg = T const& is an lvalue reference; Arg = T (no reference qualifiers) or Arg = T&& is an rvalue reference.
Ummm, you are right. That should do the trick to implement some ad-hoc forwarding in store and forward classes. Best, Ion
Jeffrey Hellrung wrote:
Ion Gaztañaga wrote:
On 29/04/2010 20:00, Jeffrey Hellrung wrote:
I'm confused. So static_cast< Arg&& >(r) creates a new temporary object (rather than just a (rvalue) reference to the r object) when used in direct construction, but does not behave this way otherwise (e.g., the line after "//Correct binding" above?
Yes, it's something strange, but I think this seems a compiler bug. This makes some porting to MSVC-10.0 a bit harder. One option is to store all the addresses in pointers and cast them back somehow without bitting this bug.
Wouldn't it be a good idea to release boost version 1.43 even with this pending issue. a) VC 10.0 has only been released for a month ( I believe ) b) Presumably it will take a while from many copies to be "out there" So the number of users with this issue is not yet large. c) Anyone who really, really needs VC 10 and boost can likely wait a couple of months for either a VC 10 service pack or boost 1.44 d) Looks like this is not a trivial issue. Attempts to address it in "panic mode" might well create unintended consequences which are currently unknown and can be very problematic. Seems like it would be better to address it in the normal methodical way. e) The sooner we get 1.43 out, the sooner that 1.44 will be out. f) Presure builds for "just one more fix" from other libraries - which can also lead to unforseen consequences. g) This way of handling it can generate a lot of extra work. We would hope that the "release process" be more routine and auotmated. This kinds of minor snafus - although probably unavoidable to some extent, should be minimized when we can. I believe that this one (vc 10 and gcc 4.5 issue) falls into this category. So I thik it should be considered to release 1.43 NOW and work on this other stuff for the next release. Robert Ramey
On 29/04/2010 23:43, Robert Ramey wrote:
Wouldn't it be a good idea to release boost version 1.43 even with this pending issue.
Yes, I was no talking about 1.43, just trying to guess the impact of new rvalue ref binding rules. IMHO 1.43 should just declare VC10 as not supported or just define BOOST_NO_RVALUE_REFERENCES until we fix the issues. Ion
----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Thursday, April 29, 2010 11:43 PM Subject: Re: [boost] VC10 config - some regressions in several libraries
Wouldn't it be a good idea to release boost version 1.43 even with this pending issue.
a) VC 10.0 has only been released for a month ( I believe ) b) Presumably it will take a while from many copies to be "out there" So the number of users with this issue is not yet large. c) Anyone who really, really needs VC 10 and boost can likely wait a couple of months for either a VC 10 service pack or boost 1.44 d) Looks like this is not a trivial issue. Attempts to address it in "panic mode" might well create unintended consequences which are currently unknown and can be very problematic. Seems like it would be better to address it in the normal methodical way. e) The sooner we get 1.43 out, the sooner that 1.44 will be out. f) Presure builds for "just one more fix" from other libraries - which can also lead to unforseen consequences. g) This way of handling it can generate a lot of extra work. We would hope that the "release process" be more routine and auotmated. This kinds of minor snafus - although probably unavoidable to some extent, should be minimized when we can. I believe that this one (vc 10 and gcc 4.5 issue) falls into this category.
So I thik it should be considered to release 1.43 NOW and work on this other stuff for the next release.
I agree with Robert. Presure is a symptom of unexpected errors. If a solution to this issue is found one week after 1.143 is released, the solution could be provided as a patch for the people needing it. Best, Vicente
On Mon, Apr 26, 2010 at 12:05 PM, John Maddock <boost.regex@virgin.net> wrote:
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types.
It seems some explicit casts are required, for example in boost/interprocess/detail/move.hpp:
template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return t; }
Should be either:
template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return std::move(t); }
or
template <class T> inline typename remove_reference<T>::type&& move(T&& t) { return static_cast<typename remove_reference<T>::type&&>(t); }
Likewise for the "forward" function.
However that still leaves errors deep within the Boost.Preprocessor code:
...
Where does that leave us as far as 1.43.0 is concerned? --Beman
Correct. This wasn't intentional, but /Za ("disable language extensions") has an extremely nasty bug in VC10. It performs elided-copy-constructor-accessibility checks when it shouldn't (specifically, when rvalue references are being bound, in which case no copy constructors are being called, even theoretically). Because of this bug, /Za should not be used. (Additionally, we no longer test our Standard Library implementation under /Za.) It's unfortunate, since /Za disables a bunch of evil extensions, but breaking conformant code is much worse than permitting nonconformant code. Stephan T. Lavavej Visual C++ Libraries Developer -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga Sent: Monday, April 26, 2010 4:36 AM To: boost@lists.boost.org Subject: Re: [boost] VC10 config - some regressions in several libraries On 26/04/2010 12:20, John Maddock wrote:
Looking at the test results, a bunch of the tests that are failing on VC10 are also failing on GCC 4.5 in C++0x mode.
Seems to be related to this: http://article.gmane.org/gmane.comp.lib.boost.devel/203080
OK seems to be a problem with our code then :-(
Hopefully this will be an incentive for folks to fix things up.
It seems that my problem with move emulation in projects imported from older MSVC to MSVC10 is that some rvalue references rules need language extensions option activated. Otherwise we can't have movable-only types. Best, Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 26/04/2010 21:08, Stephan T. Lavavej wrote:
Correct. This wasn't intentional, but /Za ("disable language extensions") has an extremely nasty bug in VC10. It performs elided-copy-constructor-accessibility checks when it shouldn't (specifically, when rvalue references are being bound, in which case no copy constructors are being called, even theoretically).
Thanks for the confirmation. Best, Ion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/26/2010 2:22 PM, Ion Gaztañaga wrote:
On 26/04/2010 21:08, Stephan T. Lavavej wrote:
Correct. This wasn't intentional, but /Za ("disable language extensions") has an extremely nasty bug in VC10. It performs elided-copy-constructor-accessibility checks when it shouldn't (specifically, when rvalue references are being bound, in which case no copy constructors are being called, even theoretically).
Thanks for the confirmation. Best,
/Za has been broken and useless for as long as I can remember, and Microsoft doesn't seem interested in either fixing or deprecating it. (See, for example, https://connect.microsoft.com/VisualStudio/feedback/details/486253/name-look..., not to mention the fact that Microsoft's own system headers won't compile with /Za.) No sane person should use it for anything. Steven, feel free to pass along this message: please fix it or drop it. Thanks, - -- Eric Niebler BoostPro Computing http://www.boostpro.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1gdSAAoJEAeJsEDfjLbXN0sH/RDHC+giA9f+JbvYlCdcx6Ud vPxSKLImEAUIo6nE9oDpCmpYGhktY6FExKScWrqmBt7vwDI7JvH7VzJ25CRIqXQA O4Mkg3CuL1LPwpMHJjR8UT2HDzbZP+C5tthkOX/rooqpdSpKTRIe6AJnAjauxMxd QyQXTk9e3GbvKzS7YPTE8C9MRGwKhAWP+Bo2U+ei4Nutj0IQ2/1VST7lSVssm2yd 64W2H8nZJdcvEe36BAU2b/45NpcS7ySkhA/+Sdoj4wwHsrd8CAH2FE3mopQf75Vw Kb48LTd3YOCKaZqMecV4XZwmStP7jn8E/ZcB+r09+xzSo8B0ztimvq++2VMjAds= =yXn3 -----END PGP SIGNATURE-----
I've made a note to myself to request that /Za be removed or at least deprecated in VC11 (our command-line deprecation warnings aren't silenceable, so they're pretty effective). I was already planning to request that /Wp64 be removed in VC11, since it was deprecated in VC9 and VC10. I don't always get what I want, but the cases for their removal are straightforward. Thanks, STL -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: Monday, April 26, 2010 2:36 PM To: boost@lists.boost.org Subject: Re: [boost] VC10 config - some regressions in several libraries -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/26/2010 2:22 PM, Ion Gaztañaga wrote:
On 26/04/2010 21:08, Stephan T. Lavavej wrote:
Correct. This wasn't intentional, but /Za ("disable language extensions") has an extremely nasty bug in VC10. It performs elided-copy-constructor-accessibility checks when it shouldn't (specifically, when rvalue references are being bound, in which case no copy constructors are being called, even theoretically).
Thanks for the confirmation. Best,
/Za has been broken and useless for as long as I can remember, and Microsoft doesn't seem interested in either fixing or deprecating it. (See, for example, https://connect.microsoft.com/VisualStudio/feedback/details/486253/name-look..., not to mention the fact that Microsoft's own system headers won't compile with /Za.) No sane person should use it for anything. Steven, feel free to pass along this message: please fix it or drop it. Thanks, - -- Eric Niebler BoostPro Computing http://www.boostpro.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1gdSAAoJEAeJsEDfjLbXN0sH/RDHC+giA9f+JbvYlCdcx6Ud vPxSKLImEAUIo6nE9oDpCmpYGhktY6FExKScWrqmBt7vwDI7JvH7VzJ25CRIqXQA O4Mkg3CuL1LPwpMHJjR8UT2HDzbZP+C5tthkOX/rooqpdSpKTRIe6AJnAjauxMxd QyQXTk9e3GbvKzS7YPTE8C9MRGwKhAWP+Bo2U+ei4Nutj0IQ2/1VST7lSVssm2yd 64W2H8nZJdcvEe36BAU2b/45NpcS7ySkhA/+Sdoj4wwHsrd8CAH2FE3mopQf75Vw Kb48LTd3YOCKaZqMecV4XZwmStP7jn8E/ZcB+r09+xzSo8B0ztimvq++2VMjAds= =yXn3 -----END PGP SIGNATURE----- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (13)
-
Beman Dawes -
Bo Persson -
Eric Niebler -
Ion Gaztañaga -
Jeffrey Hellrung -
Jeffrey Lee Hellrung, Jr.
-
John Maddock -
Peter Dimov -
Richard Webb -
Robert Ramey -
Stephan T. Lavavej -
Vicente Botet Escriba -
vicente.botet