Boost logo

Boost :

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-09-03 09:35:08


Philippe A. Bouchard wrote:

> Regular garbage collectors do not have a clue when exactly the object
> should be destroyed. This is not good news for QT widgets, for example.
> Maybe we could mix rc & gc advantages... to determine exactly when the
> object's life is terminated with reference counts followed by destruction
> & deallocation of the object using some type traits at a given time.

[...]

> Integers shall be destroyed immediately, KeepAliveLANServers at the end of
> the thread and KeepAliveWANServers at the end of the process.
>
> We could add swap options, etc.

(Sorry I forgot some details).

- Types having normal constructors with slow _destructor_ could take
advantage of destruction_mark. For example:

class KeepAliveWANServers
{
        list< vector<int> > m_address; // Too bad list<int [4]> is not working

public:
        KeepAliveWANServers() {} // Fast

        void insertIPV4(int, int, int, int); // Used gradually

        ~KeppAliveWANServers // Really Slow
        {
                for (list< vector<int> >::iterator i = m_address.begin(); ...)
                {
                        ...
                }
        }
};

- The types with has_trivial_destructor could be added into a static list
to postpone their deallocation:

vector<void *> s_garbage = resize(vector<void *>(), 100); // Ex.

inline void destroy(void * p, __true_type const &)
{
        vector<void *> & g = s_garbage;

        g.push_back(p);

        if (g.size() == 100)
        {
                for (vector<void *>::iterator i = g.begin(); i != g.end(); ++ i)
                {
                        ::free(* i);
                }
        }
}

inline void placed_ptr<T>::destroy(void * p, __false_type const &)
{
        ::free(p + ...);
}

inline placed_ptr<T>::~placed_ptr()
{
        if (m_ptr && ! -- get_count())
        {
                get()->~T();
                destroy(m_ptr, __type_traits<T>::has_trivial_destructor());
        }
}

Suggestions are welcome if you don't like this one.

-- 
Philippe A. Bouchard

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