Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-03-17 16:51:09

Peter Palotas wrote:

> That actually sounds pretty much what I was looking for. However I can't
> seem to find the source in the sandbox (using the web interface). Haven't
> poked around there before so maybe I'm just stupid, but I can't find the
> actual header-file in
> Where can I find it? And how stable/complete is your implementation?

The headers are like in the regular Boost: ../boost-sandbox/boost/*

I look at the implementation and it doesn't do what a rank tree does. It does
make it easier to base a rank tree implementation against it. The part that is
missing is keeping track of the rank of nodes as the tree changes, the
constant time op, that lets one have the logN ops later on. [ Unless I missed
something -- So correct me at will ;-) ]

To David...

It also looks to me that there is a much better way to support the custom
index aspect of assoc containers with something I thought about recently,
tuple_adaptor... The idea is to have a tuple compatible interface that can
access a subset of a larger structure. You can then use the tuple adaptor as
the comparison/index. Basically abstracting out the "index" like functionality
you have. Here are some notes I made up about it last week...

tuple_adaptor, provides the boost::tuple interface, and types, given an
existing structure and some of it's members. For example having this exiting

struct data_op
     int number;
     bool flag;
     std::string name;

typedef tuple_adaptor<data_op,&data_op::number,&data_op::flag,&data_op::name>

data_op_tuple x(1,false,"foo");
x.flag = true;
x.get<0>() = 13;

This facilitates adapting existing types for use in algorithms that take
tuples. Another option this opens is proving a subset tuple interface to a
large structure, for example:

typedef tuple_adaptor<data_op,&data_op::number,&data_op::name> data_op_tuple_2;

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/ - 102708583/icq

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