Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
Jesse Perla wrote:
I have attached my test files. Any ideas or patches would be appreciated
I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
#define _HAS_ITERATOR_DEBUGGING 0 ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0)
Works like a charm. The only problem is that it looks like I have to compile every other library I use with the same definition or the linker gets angry. I may do that later.
, std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because
the reference reference This change seems to work beautifully and has no effect on all of my code that uses this library. Which leads me to a philosophical question: Is it really a lie if it passes all of your regression tests? As always, thanks for you help, Jesse
On Sat, Mar 13, 2010 at 10:34 AM, Jesse Perla <jesseperla@gmail.com> wrote:
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
#define _HAS_ITERATOR_DEBUGGING 0 ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0)
Works like a charm. The only problem is that it looks like I have to compile every other library I use with the same definition or the linker gets angry. I may do that later.
Correct, and yes it does have a huge speed hit. In one specific project of mine, without putting that it runs in about 12 minutes, if I put that in then it runs in less then 100ms (or less then 10ms in release). Whoever was the retard that created those flags needs to have certain... er... catch my speech right quick... Conseqently, for a few years now I use this in *everything* I compile, added to the end of every definition line in Visual Studio: ;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0 Or for CMake: /D_CRT_NONSTDC_NO_DEPRECATE /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_NO_WARNINGS /D_SECURE_SCL=0 /D_SCL_SECURE_NO_DEPRECATE /D_HAS_ITERATOR_DEBUGGING=0 Or for BJam: -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SECURE_SCL=0 -D_SCL_SECURE_NO_DEPRECATE -D_HAS_ITERATOR_DEBUGGING=0 Etc...
Hi, i have run into the exact same problem when the copy constructor of a multi_array is called. Is there a fix to get this working without the macros above? It is sadly no option to compile all dependencies from scratch. Regards -chris On Sun, Mar 14, 2010 at 3:29 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
On Sat, Mar 13, 2010 at 10:34 AM, Jesse Perla <jesseperla@gmail.com> wrote:
Thomas Klimpel <Thomas.Klimpel <at> synopsys.com> writes:
#define _HAS_ITERATOR_DEBUGGING 0 ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0)
Works like a charm. The only problem is that it looks like I have to compile every other library I use with the same definition or the linker gets angry. I may do that later.
Correct, and yes it does have a huge speed hit. In one specific project of mine, without putting that it runs in about 12 minutes, if I put that in then it runs in less then 100ms (or less then 10ms in release). Whoever was the retard that created those flags needs to have certain... er... catch my speech right quick...
Conseqently, for a few years now I use this in *everything* I compile, added to the end of every definition line in Visual Studio: ;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0
Or for CMake: /D_CRT_NONSTDC_NO_DEPRECATE /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_NO_WARNINGS /D_SECURE_SCL=0 /D_SCL_SECURE_NO_DEPRECATE /D_HAS_ITERATOR_DEBUGGING=0
Or for BJam: -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SECURE_SCL=0 -D_SCL_SECURE_NO_DEPRECATE -D_HAS_ITERATOR_DEBUGGING=0
Etc... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christopher Lux wrote:
i have run into the exact same problem when the copy constructor of a multi_array is called.
Is there a fix to get this working without the macros above? It is sadly no option to compile all dependencies from scratch.
If you put the question like this, the other "workaround" I proposed in order to explain what goes wrong should work for you: Thomas Klimpel wrote:
But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag
This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy):
Of course, it would be best to fix it in Boost.Iterator, but this might be tricky as there seems to be some reason why the authors of Boost.Iterator initially (2003...) gave up on this problem. Regards, Thomas
Thomas Klimpel wrote:
But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag
This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy):
Of course, it would be best to fix it in Boost.Iterator, but this might be tricky as there seems to be some reason why the authors of Boost.Iterator initially (2003...) gave up on this problem.
Thanks for the Workaround. I do not have a complete overview of the problem, but i am afraid that it will hinder the use of VS2010 in many cases. I hope there will be some kind of proper workaround or fix to it. Regards -chris
Hi Chris, Christopher Lux wrote:
Thanks for the Workaround. I do not have a complete overview of the problem, but i am afraid that it will hinder the use of VS2010 in many cases. I hope there will be some kind of proper workaround or fix to it.
While trying to make progress towards a proper workaround, I found out that the workaround I proposed to you is still buggy. It's not sufficient to change "multi_array/iterator.hpp:56", but you also have to apply the same change to "multi_array/iterator.hpp:74". The results of my attemps to make progress can be found here: <http://lists.boost.org/Archives/boost/2010/05/165798.php> <http://lists.boost.org/Archives/boost/2010/05/165810.php> I don't expect much feedback on this before 15.5.2010 (end of BoostCon...). My initial plan was actually to only resume work on this after that date, and I will probably stick to my intial plan from now on, especially considering the feedback I received up to now. Regards, Thomas
participants (4)
-
Christopher Lux -
Jesse Perla -
OvermindDL1 -
Thomas Klimpel