Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2003-12-12 00:21:44


"Larry Evans" <cppljevans_at_[hidden]> wrote in message
news:br9se9$gnh$1_at_sea.gmane.org...
> [...]
> Exception in "multi_inherit_test": signal: memory access violation
> [...]
> *** errors detected in test suite "Basic smart_ptr framework tests";
> [...]

class super2
{
public:
    super2(int ssn) : ssn_(ssn) { }

    int ssn(void) const { return ssn_; }
private:
    int ssn_;
};

class child_mi : public object, public super2
{
public:
    child_mi(bool& dead, int age, int ssn) : object(dead), super2(ssn),
age_(age) { }
    int age(void) const { return age_; }
private:
    int age_;
};

void multi_inherit_test(void)
{
    bool dead(false);
    {
        typedef smart_ptr<child_mi, scalar_storage<_>, ref_counted<_>,
assert_check<_> > sp_type;
        typedef smart_ptr<super2, scalar_storage<_>, ref_counted<_>,
assert_check<_> > sp2_type;
        sp2_type p;
        BOOST_CHECK_EQUAL(use_count(p), 0u );
        {
            sp_type q(new child_mi(dead,50,999999999));
            p = q;
            BOOST_CHECK_EQUAL(use_count(p), 2u );
        }
        BOOST_CHECK(!dead);
        BOOST_CHECK_EQUAL(use_count(p), 1u );
    }
    BOOST_CHECK(dead);
}

Let's look at this carefully...p is basicallly a super2*, while
q is basically a child_mi*. We create a new child_mi,
transfer it to q, then copy q to p. We then let q go out of
scope, so p gets to delete it. So p attempts to delete a
super2* which is pointing to a child_mi object. If p were
omniscient (or even just psychic), it could know that p is
really pointing to a derived object. But it's neither, so how
is it supposed to know that super2 is a polymorphic type?
Where's the virtual d'tor? ;> When you add one, some
semblance of sanity returns to the wacky world of smart
pointers. ;)

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.544 / Virus Database: 338 - Release Date: 11/25/2003

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk