[container] stable_vector::back() is broken in Boost 1.53
Tested on both VS2010 and VS2012, boost 1.53, with default boost no option set: ############ #include <boost/container/stable_vector.hpp> #include <iostream> int main() { boost::container::stable_vector< int > values; values.emplace_back( 42 ); int& bad_value = values.back(); // bad address int& good_value = values.front(); int& also_good_value = values.at(0); // imply values[0] std::cout<< " ADDRESS OF BAD VALUE : " << &bad_value << std::endl; std::cout<< " ADDRESS OF GOOD VALUE : " << &good_value << std::endl; std::cout<< " ADDRESS OF ALSO GOOD VALUE : " << &also_good_value << std::endl; } ############ This code displays addresses of the bad_value object very low on Debug and very high on Release. I believe that .back() is broken. However, when I test there : http://liveworkspace.org/code/3F11CK$2 it seems to work with any available compiler. So either it's LiveWorkspace which use an older boost version, or this issue arise only on VC. I made a ticket: https://svn.boost.org/trac/boost/ticket/8412 Joel Lamotte
On 06/04/2013 08:52 p.m., Klaim - Joël Lamotte wrote:
This code displays addresses of the bad_value object very low on Debug and very high on Release. I believe that .back() is broken. However, when I test there :http://liveworkspace.org/code/3F11CK$2 it seems to work with any available compiler.
So either it's LiveWorkspace which use an older boost version, or this issue arise only on VC.
LiveWorkspace uses Boost 1.53 according to this: http://liveworkspace.org/code/3F11CK$11 Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On Sun, Apr 7, 2013 at 3:01 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com
wrote:
LiveWorkspace uses Boost 1.53 according to this: http://liveworkspace.org/code/**3F11CK$11<http://liveworkspace.org/code/3F11CK$11>
So it's a VS only bug... Someone confirmed the bug in the ticket but say it's fixed in trunk. Joel Lamotte
Zitat von Klaim - Joël Lamotte <mjklaim@gmail.com>:
On Sun, Apr 7, 2013 at 3:01 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com
So it's a VS only bug... Someone confirmed the bug in the ticket but say it's fixed in trunk.
it must fail on all compilers using 1.53, as it's because of out-of-bounds vector access. is it intentional that container::vector::operator[] doesn't assert n < size()? would have caught this bug.
Stefan Strasser wrote:
Zitat von Klaim - Joël Lamotte wrote:
So it's a VS only bug... Someone confirmed the bug in the ticket but say it's fixed in trunk.
it must fail on all compilers using 1.53, as it's because of out-of-bounds vector access. is it intentional that container::vector::operator[] doesn't assert n < size()? would have caught this bug.
The trunk version works for me on the Darwin toolset (MacOSX gcc). I wrote a different test program: #include <boost/utility.hpp> #include <boost/container/stable_vector.hpp> #include <boost/test/minimal.hpp> int test_main(int argc, char** argv) { boost::container::stable_vector<int> values; values.emplace_back(42); boost::container::stable_vector<int>::const_iterator value_itr = ( values.begin() ); int const& value_at = values.at(0); int const& indexed_value = values[0]; int const& back_value = values.back(); BOOST_CHECK(boost::addressof(*value_itr) == boost::addressof(value_at)); BOOST_CHECK( boost::addressof(*value_itr) == boost::addressof(indexed_value) ); BOOST_CHECK(boost::addressof(*value_itr) == boost::addressof(back_value)); BOOST_CHECK(boost::addressof(value_at) == boost::addressof(indexed_value)); BOOST_CHECK(boost::addressof(value_at) == boost::addressof(back_value)); BOOST_CHECK( boost::addressof(indexed_value) == boost::addressof(back_value) ); return 0; } HTH, Cromwell D. Enage
Stefan Strasser <strasser@uni-bremen.de> writes:
it's because of out-of-bounds vector access. is it intentional that container::vector::operator[] doesn't assert n < size()? would have caught this bug.
That's how std::vector behaves. If you want checking, you are supposed to use the "at" method. Thanks, PM
On Mon, Apr 8, 2013 at 6:03 PM, Petr Machata <pmachata@redhat.com> wrote:
That's how std::vector behaves. If you want checking, you are supposed to use the "at" method.
I think he meant to have the assert which would be active only in debug mode. std::vector::at() have the check in all modes. Joel Lamotte
El 08/04/2013 18:28, Klaim - Joël Lamotte escribió:
On Mon, Apr 8, 2013 at 6:03 PM, Petr Machata <pmachata@redhat.com> wrote:
That's how std::vector behaves. If you want checking, you are supposed to use the "at" method.
I think he meant to have the assert which would be active only in debug mode.
It's a good idea, I've added that check to stable_vector. Ion
On 07/04/2013 08:09 a.m., Klaim - Joël Lamotte wrote:
So it's a VS only bug... Someone confirmed the bug in the ticket but say it's fixed in trunk.
I can still reproduce the bug using VS2012 Nov CTP with Boost trunk at revision 83791. -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 07/04/2013 12:29 p.m., Agustín K-ballo Bergé wrote:
On 07/04/2013 08:09 a.m., Klaim - Joël Lamotte wrote:
So it's a VS only bug... Someone confirmed the bug in the ticket but say it's fixed in trunk.
I can still reproduce the bug using VS2012 Nov CTP with Boost trunk at revision 83791.
Sorry for the noise, there was something wrong with my configuration. The issue is indeed fixed in trunk. -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On Sun, Apr 7, 2013 at 11:19 PM, Agustín K-ballo Bergé < kaballo86@hotmail.com> wrote:
Sorry for the noise, there was something wrong with my configuration. The issue is indeed fixed in trunk.
Good thing it's definitely fixed! Joel Lamotte
participants (6)
-
Agustín K-ballo Bergé -
Cromwell Enage -
Ion Gaztañaga -
Klaim - Joël Lamotte -
Petr Machata -
Stefan Strasser