Re: [boost] The Wonder of Tuples
Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. (Note that the current Boost.Tuples is not one-to-one what was accepted into the TR. Most notably, the cons-list interface was not standardized.) The PP based tuples are not complete yet, and what the iteration interface will be is still undecided. /Jaakko -- -- -- Jaakko Järvi email: [EMAIL PROTECTED] -- Post Doctoral Fellow phone: +1 (812) 855-3608 -- Pervasive Technology Labs fax: +1 (812) 855-4829 -- Indiana University, Bloomington ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
- Original Message - From: Jaakko Jarvi [EMAIL PROTECTED] Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. (Note that the current Boost.Tuples is not one-to-one what was accepted into the TR. Most notably, the cons-list interface was not standardized.) The PP based tuples are not complete yet, and what the iteration interface will be is still undecided. Yup, I've been itching to reply to the thread but opted to wait for Jaakko. There's already a TR conformant tuple implementation in Spirit's CVS in the PHOENIX_X branch. It is PP and MPL based. Compiles on all relevant compilers. There is only one implementation, unlike boost tuples which has a different implementation for MSVC which can easily get out of sync (it is out of sync now in fact. e.g. the MSVC branch does not convert a make_tuple(ref(x)) to tupleX. And interestingly, some code that does not compile on some compilers now compile with this implementation. All of Jaakko's regression tests (except the cons related stuff) plus some more new ones compile and run. With the help of Jaakko, Aleksey et. al, I wish to implement a set of tuple algorithms similar to STLs. The tricky part is that it should work at compile time, run-time and half-run-compile time. Cheers, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. -Dave -- Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James P. Johnson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] The Wonder of Tuples
David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] The Wonder of Tuples
Over the weekend I realized just what strange and wonderful things
tuples are. This message is as much to get my thoughts recorded as it
is a request for discussion about the various classes and bits of
code presented within. Some of this stuff may be useful for Boost and
some may not. I'd like to hear what you all have to say. It may be
that I'm simply restating the obvious to some, but I found the whole
thing rather intriguing. I'll start from the beginning.
Last week I quickly wrote a prototype symbol manager for the students
in a compiler class I am helping to teach. The implementation is a
typical stack of symbol table objects so that names can be resolved at
the proper scope. Naturally, I wanted to provide an iterator
interface so they could examine the contents of the symbol manager.
Because each symbol table is an autonomous entity living on the scope
stack, there is no way to iterate across scopes. I've run into this
sort of problem several times and have long wished for an iterator
that can cross container boundaries. In the interest of time, I
hacked together an interface to allow the students to iterate at a
particular scope, but I'm not very satisfied with that solution.
Over the weekend I had a bit of free time so I wrote up a
spanning_iterator based on the iterator_adaptors framework. To throw
in a bit more complication, I wanted something generic enough that I
could span different kinds of container. There should be a way to
span a std::vector and a std::list as long as their value_types are
the same. The spanning_iterator holds two tuples -- one for the
current iterators and the other for the end iterators for each
container the spanning_iterator spans. The idea is that when the
current current iterator reaches its end (the corresponding element
in the ends tuple) the next iterator in the current tuple becomes
current and so on until all current iterators reach their ends.
Actually implementing the iterator_adaptor policies for this is
conceptually straightforward: simply walk the current tuple until an
iterator is found that is not at its end. Then simply operate on
that iterator (dereference it, increment it, etc.). Getting this to
work correctly with the tuple interface is non-trivial, however.
The fundamental problem is that it's inconvenient to iterate through a
tuple. All we have is the get template to access tuple elements.
Iterating is again conceptually simple -- just increment an index.
But the fact that get is a template implies the index must be a
compile-time constant, meaning we need a compile-time loop (or, if
you prefer, programmer-controlled loop unrolling) to iterate.
As I went through design after design, I realized why this was so
difficult to wrap my brain around: the tuple is neither a strictly
compile-time nor run-time entity. On one end of the spectrum, we have
MPL sequences. These are clearly compile-time only constructs. They
hold type information that is completely available at compile-time.
On the other end we have something like std::vector which provides
only a run-time interface.
Tuples sit somewhere in-between. They hold run-time values, but they
are indexed at compile-time. This means that the sorts of things we
want to do with tuples and how we want to iterate over them slide
along a spectrum -- they change depending on how we want to view the
tuple.
For example, in the spanning_iterator, I want to apply an operation to
a member of the tuple, but I don't know _which_ member until run-time.
Because the spanning_iterator can hold different types of iterator, I
don't even know at compile-time what kind of iterator is going to be
affected. This has two consequences: we must use run-time checks to
find the current element to operate upon and the operation itself must
be passed to the looping construct because the loop cannot return a
tuple element (how would we code the return type?). A static loop
does us no good because the execution condition (whether an iterator
is at its end) returns a run-time value. Furthermore, we need a loop
that can early out once it finds the correct iterator. We don't
want to go operating upon all of the iterators after the current one
as well.
Here's my solution: do_if_first. The idea is to have a loop with a
run-time condition that is checked for executing the body and
terminating and a compile-time condition for checking whether to
iterate. We need static iteration because tuples are indexed
statically. We need run-time execution because tuple values change at
run-time. The if_first part tells us that the loop will terminate
once it finds a tuple element that satifies the execution condition.
namespace detail {
templatetypename Body,
typename Result = typename Body::result_type
struct stop {
// Called if no element satifies the execution condition
static Result execute(typename Body::argument_type a) {
return(Body::default_result(a));
};
RE: [boost] The Wonder of Tuples
Over the weekend I had a bit of free time so I wrote up a spanning_iterator based on the iterator_adaptors framework. To throw in a bit more complication, I wanted something generic enough that I could span different kinds of container. There should be a way to span a std::vector and a std::list as long as their value_types are the same. The spanning_iterator holds two tuples -- one for the current iterators and the other for the end iterators for each container the spanning_iterator spans. The idea is that when the current current iterator reaches its end (the corresponding element in the ends tuple) the next iterator in the current tuple becomes current and so on until all current iterators reach their ends. While ago I wrote joining_iterator that join 2 iterator ranages. You can combine joining interator as many times as you wish to provide multiple ranges iterator. I never really have a chance to writte a docs for it It's if vault area. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
Rozental, Gennadiy wrote: Over the weekend I had a bit of free time so I wrote up a spanning_iterator based on the iterator_adaptors framework. To throw in a bit more complication, I wanted something generic enough that I could span different kinds of container. There should be a way to While ago I wrote joining_iterator that join 2 iterator ranages. You can combine joining interator as many times as you wish to provide multiple ranges iterator. I never really have a chance to writte a docs for it It's if vault area. That's almost certainly a better model than what I came up with. I'll go have a look. I'm not sure I can get at the vault since I'm not registered on Yahoo. Unless it got moved elsewhere. -Dave -- Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James P. Johnson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
