|
Boost : |
From: Daryle Walker (darylew_at_[hidden])
Date: 2002-08-24 23:44:35
on 8/23/02 4:50 PM, Xiaoming Shi at polyrandom_at_[hidden] wrote:
> As for the base_from_member template
> http://www.boost.org/libs/utility/base_from_member.html the typical usage is
> as follow:
> ----------------------------------------------------------------------------
> ---------------------------------------------------
> class someclass
> : private boost::base_from_member<int>
> , private boost::base_from_member<long>
> , private boost::base_from_member<string,1>
> , private boost::base_from_member<string,2>
> {
> // Helper typedef's
> typedef boost::base_from_member<int> pbase0_type;
> typedef boost::base_from_member<long> pbase1_type;
> typedef boost::base_from_member<string, 1> pbase2_type;
> typedef boost::base_from_member<string, 2> pbase3_type;
>
> void some_func()
> {
> pbase0_type::member=0;
> pbase3_type::member="aaa";
> .............
> ----------------------------------------------------------------------------
> ---------------------------------------------------
[TRUNCATE complicated extension with typelists and without constructors]
That is not a typical usage. I meant for that template to be used in
situations like:
class fdostream : public std::ostream {
protected:
fdoutbuf buf;
public:
fdostream (int fd) : buf(fd), std::ostream(&buf) {
}
};
(It's from "The C++ Standard Library" book by Nicolai M. Josuttis.) The
author wants the initialization to happen in the order given. C++'s rules
will make the "std::ostream" base get initialized before the "buf" member,
so the base will use a pointer to unprepared memory. This template is
supposed to help get around the problem.
If you do not need a data member to be part of an initialization of a base
class, then you do not need to use "base_from_member" at all. There is no
need to extend the template with type-lists, especially if you drop the
pass-through constructors.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk