Re[2]: [lmi] Why does this crash?

[Vadim Zeitlin]

On Sat, 17 Apr 2010 17:46:58 +0200 Vaclav Slavik <address@hidden> wrote:

VS> On Sat, 2010-04-17 at 16:43 +0200, Vadim Zeitlin wrote:
VS> >  The principle applies only when you assign the value returned by the
VS> > function to a (const) reference. It doesn't apply if you use it in any
VS> > other way. 
VS> 
VS> Moreover, xmlwrapp is weird. It attempts to expose std iterators-like
VS> interface in xml::node::iterator, but the internals of xmlwrapp
VS> implementation make it impossible, so if you rely on exactly std
VS> behavior, you may encounter weird and totally unexpected failures.

 I didn't know about this, thanks for your explanations.

VS>  1. Equal iterators return different references:
VS> 
VS>             xml::node root("root");
VS>             root.push_back(xml::node("child"));
VS>             xml::node::const_iterator a = root.find("child");
VS>             xml::node::const_iterator b = root.find("child");
VS>             const xml::node& na = *a;
VS>             const xml::node& nb = *b;
VS>             BOOST_CHECK( a == b ); // ok
VS>             BOOST_CHECK_EQUAL( &na, &nb ); // fails!

 This IMO is not a big problem, I don't see any reasonable scenario in
which you'd rely on this (but, of course, I could be missing something, as
usual).

VS>  2. Iterator instance always returns the same reference, so you can't
VS>     remember it and change the iterator:
VS> 
VS>             xml::node root("root");
VS>             root.push_back(xml::node("one"));
VS>             root.push_back(xml::node("two"));
VS>             xml::node::const_iterator i = root.begin();
VS>             const xml::node& one = *i;
VS>             BOOST_CHECK_EQUAL( one.get_name(), "one" );
VS>             ++i;
VS>             const xml::node& two = *i;
VS>             BOOST_CHECK_EQUAL( two.get_name(), "two" );
VS>             BOOST_CHECK_EQUAL( one.get_name(), "one" ); // fails!

 This is not too bad neither because I guess you usually would make a copy
of the return value of operator*() instead of keeping a reference to it,
after all it's arguably not totally unexpected that the reference to the
value pointed to by an iterator changes when it changes itself. But it
still would be better if it didn't, of course.

VS> The second problem could be fixed by returning a value -- in light of
VS> the principle you brought up, this should be backward compatible and not
VS> result in any problems (or am I missing something?).

 I don't see any reason to not do this and it would be an improvement IMHO.

VS> Number one is a harder problem and fixing it would cost some extra
VS> memory. I wonder if any of these is worth fixing.

 I don't think the first one is worth it. The second one IMO is.

 Regards,
VZ