[assign] fixes for msvc, msvc-stlport and vc7
The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.) Two changes applied, both in list_insert.hpp: 1. MSVC++ 6.0/7.0, in the presence of a templated memfuns, interprets additional overloads as if they were specializations of the former (which is not legal C++, AFAIK). This introduces problems with the copy ctors of list_insert, which can be workarounded by a) making the template copy ctor accept const references b) declaring and defining the plain default copy ctor of list_insert *after* the templated copy ctor. 2. list_insert::operator()(T t) has been changed to accept a const reference instead. With these changes, all tests build, though three of them crash at run-time (list_inserter, list_of and multi_index_container) I've checked the changes with a compiler other than MSVC (GCC 3.2), seems like nothing ain't broken. I've got two questions: 1. Could somebody (the author, I guess) validate these changes for commit? 2. list_inserter follows a strange convention (IMHO) of not forcing template params to be const references in its various copy ctors and assignment operators, for instance: list_inserter( Function fun ); template< class T > list_inserter& operator=( T r ); Any reason for this approach? I don't know if this can pose problems, but to me having these qualified with const & seems like the usual way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 164c164 < ---
168,170d167 < list_inserter( const list_inserter& r ) : insert_( r.insert_ ) < {} < 172c169 < list_inserter( list_inserter<Function2,Arg> r ) ---
list_inserter( const list_inserter<Function2,Arg>& r )
175a173,175
list_inserter( const list_inserter& r ) : insert_( r.insert_ ) {}
239c239 < list_inserter& operator()( T t ) ---
list_inserter& operator()( const T& t )
Hi Joaquin, |"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41503262.EE933BB4@tid.es... |The attached fix makes all tests compile for msvc (not |all run, though) and hopefully also for the other two toolsets |(can't try myself.) Two changes applied, both in |list_insert.hpp: wow! great work :-) |1. MSVC++ 6.0/7.0, in the presence of a templated |memfuns, interprets additional overloads as if they were |specializations of the former (which is not legal C++, |AFAIK). This introduces problems with the copy ctors |of list_insert, which can be workarounded by | a) making the template copy ctor accept const references | b) declaring and defining the plain default copy ctor of | list_insert *after* the templated copy ctor. ok, this should not be a problem to do. Amazing how simple it is to write non-portable code :-) | 2. list_insert::operator()(T t) has been changed to accept | a const reference instead. I have made this change as #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) template< class T > list_inserter& operator()( const T& t ) #else template< class T > list_inserter& operator()( T t ) #endif | With these changes, all tests build, though three of them | crash at run-time (list_inserter, list_of and multi_index_container) ok, this is much better than before! some of the test a big and fat and do some tricky conversions...but just having the basic stuff working is great! |I've got two questions: | |1. Could somebody (the author, I guess) validate these changes |for commit? I have comitted them. |2. list_inserter follows a strange convention (IMHO) of not |forcing template params to be const references in its various |copy ctors and assignment operators, for instance: | |list_inserter( Function fun ); |template< class T > |list_inserter& operator=( T r ); | |Any reason for this approach? I don't know if this can pose |problems, but to me having these qualified with const & seems |like the usual way. yes, the bitches are char[N] and wchar_t[N] which does not convert to char* and wchar_t* otherwise. this comes up in simple stuff like vector<string> = list_of( "foo" )( "goobar" ); of course, the Function arg could be const Function&, but is there any difference in inline code? Muchos gracias for the patch! Thorsten
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:ciq1b6$vla$1@sea.gmane.org... | | "Thorsten Ottosen" wrote: | | > I have made this change as | > | > #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) | > | You probably mean | | #if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) // VC7.0 and less ah yes! thanks Thorsten
Joaquín Mª López Muñoz writes:
The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.)
Joaquín, Could you please verify that you patch was correctly applied? It looks like things got better with MSVC in terms of compilation, but now "list_inserter" and "list_of" tests fail at run time -- http://tinyurl.com/6g499 ("multi_index_container" doesn't fail, but gets terminated by regression tools because apparently it takes more than 5 minutes to run). TIA, -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy ha escrito:
Joaquín Mª López Muñoz writes:
The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.)
Joaquín,
Could you please verify that you patch was correctly applied? It looks like things got better with MSVC in terms of compilation, but now "list_inserter" and "list_of" tests fail at run time -- http://tinyurl.com/6g499 ("multi_index_container" doesn't fail, but gets terminated by regression tools because apparently it takes more than 5 minutes to run).
I think the patch is correctly applied. When I submitted it, I reported that the tests list_inserter, list_of and multi_index_container would still crash at run-time, which is what's happening (more or less): * test_list_inserter: behaving as predicted * list_of: behaving as predicted (in fact, this test does not depend on the patch at all, list_inserter.hpp is not included) * multi_index_container: here we have differing results; in my local environment, there's no hang up, but a sure crash. Now I wonder about the results of test array for msvc-stlport and vc7. This test does not depend on the patch I proposed, so its current failing on these platforms must be due to something else. Does anybody remember whether they used to work in past days? (Thorsten?) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz writes:
Aleksey Gurtovoy ha escrito:
Joaquín Mª López Muñoz writes:
The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.)
Joaquín,
Could you please verify that you patch was correctly applied? It looks like things got better with MSVC in terms of compilation, but now "list_inserter" and "list_of" tests fail at run time -- http://tinyurl.com/6g499 ("multi_index_container" doesn't fail, but gets terminated by regression tools because apparently it takes more than 5 minutes to run).
I think the patch is correctly applied. When I submitted it, I reported that the tests list_inserter, list_of and multi_index_container would still crash at run-time,
Oh, I missed this somehow.
which is what's happening (more or less):
* test_list_inserter: behaving as predicted * list_of: behaving as predicted (in fact, this test does not depend on the patch at all, list_inserter.hpp is not included) * multi_index_container: here we have differing results; in my local environment, there's no hang up, but a sure crash.
OK. Thorsten, could you tell us what's up with the crashes?
Now I wonder about the results of test array for msvc-stlport and vc7. This test does not depend on the patch I proposed, so its current failing on these platforms must be due to something else. Does anybody remember whether they used to work in past days?
They were failing before, see http://thread.gmane.org/gmane.comp.lib.boost.devel/110081. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2ekktqveh.fsf@meta-comm.com... Joaquín Mª López Muñoz writes:
Aleksey Gurtovoy ha escrito:
I think the patch is correctly applied. When I submitted it, I reported that the tests list_inserter, list_of and multi_index_container would still crash at run-time,
Oh, I missed this somehow.
which is what's happening (more or less):
* test_list_inserter: behaving as predicted * list_of: behaving as predicted (in fact, this test does not depend on the patch at all, list_inserter.hpp is not included) * multi_index_container: here we have differing results; in my local environment, there's no hang up, but a sure crash.
OK. Thorsten, could you tell us what's up with the crashes? -------------------------------- The first is solved by non executing this long-haired code typedef vector<int> score_type; typedef map<string,score_type> team_score_map; typedef std::pair<string,score_type> score_pair; team_score_map team_score; insert( team_score )( "Team Foo", list_of(1)(1)(0) ) ( "Team Bar", list_of(0)(0)(0) ) ( "Team FooBar", list_of(0)(0)(1) ); BOOST_CHECK_EQUAL( team_score.size(), 3u ); BOOST_CHECK_EQUAL( team_score[ "Team Foo" ][1], 1 ); BOOST_CHECK_EQUAL( team_score[ "Team Bar" ][0], 0 ); for msvc. the second is simply that conversion operators don't work properly leading to the crash...I don't know exactly why, but applying ()()()().to_container( c ) to all lists fixed the crash. both have been comitted br Thorsten
participants (4)
-
Aleksey Gurtovoy -
Joaquín Mª López Muñoz -
Pavel Vozenilek -
Thorsten Ottosen