Boost logo

Boost :

From: Philippe A. Bouchard (philippe_at_[hidden])
Date: 2003-07-28 09:13:22

Brock Peabody wrote:

>> -----Original Message-----
>> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]
>> On Behalf Of Philippe A. Bouchard
>> Sent: Monday, July 28, 2003 6:08 AM
>> To: boost_at_[hidden]
>> Subject: [boost] Re: Re: GUI/GDI template library
> [...]
>> By the way, this should be defined in the Boost Library:
>> template <typename T>
>> struct tree
>> {
>> list<T> element;
>> list<tree> children;
>> };
>> You get the idea that you have more control of how you wish to
> represent
>> you
>> container data & individual entries this way.
> If you want to (and you will) you can go crazy with the static types of
> the tree nodes. I'd recommend using some sort of mpl type list to
> define the structure of the tree and callbacks to generate the actual
> nodes at runtime - you don't necessarily want to have to generate them
> all at once.

Yes I know, this could be defined by another property what to do when you
expand a sub-list:

template <typename T>
        struct tree
                list<T> element;
                list<tree> children;

template <typename T>
        struct filesystem
                filesystem * parent; // Important generic property,
                                        // like an ownership smart pointer.
                                        // BTW shifted_ptr<> could handle
                                        // parent_of(new (so) filesystem(this)).

                DIR * d;
                bool open;

                list<T> element;
                list<filesystem> children;

This could be abstracted in a better way but the container could be defined
like this to handle read & non-read sub directories.

> I've got a tree built on top of the windows tree control that takes a
> type tree to specify its layout. You also need to be able to specify
> recursive tree structures statically since things like paths may be
> arbitrarily deep. You can access children by specifying the values of
> its parent nodes (assuming everything is less-than-comparable). All of
> the access functions can be generated as part of the compile time
> structure of the tree. If this doesn't make sense I can dig up some
> sample code. It wasn't pleasant but I got it to work under VC 6.

struct tree<> is recursive: list<tree> children. Why I like it this way is
because it is exactly like other containers and can be used for other
purposes. You could define any element type you want:

tree<lineedit>, tree<checkbox>, tree<label>, tree<pixmap_label> or tree<
..._ptr<mytype> > if the design is chosen upon smart pointers for widget

Philippe A. Bouchard

Boost list run by bdawes at, gregod at, cpdaniel at, john at