[boost] RE: Re: Re: GUI/GDI template library

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
creation.

-- 
Philippe A. Bouchard