[mpl]suggested addition in vault/cppljevans/mpl/child_i_depth_j.zip
child_i_depth_j allows the traversal of a tree of applications. It's useful for accessing, for example, the i-th superclass of the results of mpl/fold, as demonstrated by the test file: libs/mpl/test/child_i_depth_j_test.cpp included in the zip file mentioned in the subject line. Could this be added to mpl? Is there something I could do to facilitate this addition? -regards Larry
Larry Evans wrote:
child_i_depth_j allows the traversal of a tree of applications. It's useful for accessing, for example, the i-th superclass of the results of mpl/fold, as demonstrated by the test file:
libs/mpl/test/child_i_depth_j_test.cpp
included in the zip file mentioned in the subject line.
Could this be added to mpl? Is there something I could do to facilitate this addition?
Writing some documentation might help. For instance, what is an application? You say it's defined in application_parts.hpp, but I don't see any definition there.
-regards Larry
Jonathan
On 08/03/2005 08:51 PM, Jonathan Turkanis wrote:
Larry Evans wrote:
child_i_depth_j allows the traversal of a tree of applications. It's useful for accessing, for example, the i-th superclass of the results of mpl/fold, as demonstrated by the test file:
libs/mpl/test/child_i_depth_j_test.cpp
included in the zip file mentioned in the subject line.
Could this be added to mpl? Is there something I could do to facilitate this addition?
Writing some documentation might help. For instance, what is an application? You
accessing, for example, the i-th superclass of the results of mpl/fold,
For example, I've used fold to calculate the size of both a tuple and variant. In order to access the offset of the j-th element of the tuple, I can use child_i_depth_j. I've also used it to access the j-th acceptor method in a class derived the variant. For a variant of n elements, there are n acceptor methods, one for each element. They are generated also with fold. Given that the value of the variant's tag is a run-time value, I need to create a vector of methods and access the appropriate acceptor method.... Oh it's getting to complicated to explain. I'll just upload it to the vault.
say it's defined in application_parts.hpp, but I don't see any definition there.
The comment under child_i_depth_j.zip in: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=cppljevans/mpl says it *uses* application_parts. It's defined in child_i_depth_j.hpp. The only reason I mentioned application_parts was that the last time I proposed application_parts I didn't have a real good application for it. child_i_depth_j is such an application.
Larry Evans wrote:
Jonathan Turkanis wrote:
Larry Evans wrote:
child_i_depth_j allows the traversal of a tree of applications. It's useful for accessing, for example, the i-th superclass of the results of mpl/fold, as demonstrated by the test file:
Could this be added to mpl? Is there something I could do to facilitate this addition?
Writing some documentation might help. For instance, what is an application? You
accessing, for example, the i-th superclass of the results of mpl/fold,
For example, I've used fold to calculate the size of both a tuple and variant. In order to access the offset of the j-th element of the tuple, I can use child_i_depth_j. I've also used it to access the j-th acceptor method in a class derived the variant. For a variant of n elements, there are n acceptor methods, one for each element. They are generated also with fold. Given that the value of the variant's tag is a run-time value, I need to create a vector of methods and access the appropriate acceptor method.... Oh it's getting to complicated to explain. I'll just upload it to the vault.
What I meant is that you should write a detailed decription of what it does: how many arguments it takes, what properties they must have, what nested types the result has, etc. Jonathan
On 08/04/2005 01:01 AM, Jonathan Turkanis wrote: [snip]
What I meant is that you should write a detailed decription of what it does: how many arguments it takes, what properties they must have, what nested types the result has, etc.
Like that in, for example: http://www.boost.org/libs/mpl/doc/refmanual/unpack-args.html ? If so, should I use .rst or .qbk to generate the .html file? All the mpl doc files are now created from .rst files, but I recall some mention of migrating to .qbk files.
On 08/04/2005 01:01 AM, Jonathan Turkanis wrote: [snip]
What I meant is that you should write a detailed decription of what it does:
how
many arguments it takes, what properties they must have, what nested types
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:dcubai$kpj$1@sea.gmane.org... the
result has, etc. Like that in, for example:
http://www.boost.org/libs/mpl/doc/refmanual/unpack-args.html
?
Yeah, that would be a good start. A little less terse would be nice ;-)
If so, should I use .rst or .qbk to generate the .html file? All the mpl doc files are now created from .rst files, but I recall some mention of migrating to .qbk files.
How about starting with .txt? Jonathan
On 08/04/2005 07:38 PM, Jonathan Turkanis wrote: [snip]
Yeah, that would be a good start. A little less terse would be nice ;-)
Just uploaded to vault documentation in html produced from rst. Thanks for the any feedback. -regards Larry
Larry Evans writes:
On 08/04/2005 01:01 AM, Jonathan Turkanis wrote: [snip]
What I meant is that you should write a detailed decription of what it does: how many arguments it takes, what properties they must have, what nested types the result has, etc.
Like that in, for example:
http://www.boost.org/libs/mpl/doc/refmanual/unpack-args.html
?
If so, should I use .rst or .qbk to generate the .html file? All the mpl doc files are now created from .rst files, but I recall some mention of migrating to .qbk files.
The MPL docs specifically are not migrating anywhere. -- Aleksey Gurtovoy MetaCommunications Engineering
On 08/04/2005 08:39 PM, Aleksey Gurtovoy wrote:
Larry Evans writes: [snip]
mpl doc files are now created from .rst files, but I recall some mention of migrating to .qbk files.
The MPL docs specifically are not migrating anywhere.
OK, I'll try .rst then, but I thought I remember David A. saying that the only reason he wasn't migrating to quickbook from ReStruturedText was because emacs had an rst-mode but not a qbk-mode. I thought he asked from help in creating such an emacs mode. Of course, now that you mention no intention of migrating, I suppose he was talking about other libraries beside mpl.
Larry Evans <cppljevans@cox-internet.com> writes:
On 08/04/2005 08:39 PM, Aleksey Gurtovoy wrote:
Larry Evans writes: [snip]
mpl doc files are now created from .rst files, but I recall some mention of migrating to .qbk files.
The MPL docs specifically are not migrating anywhere.
OK, I'll try .rst then, but I thought I remember David A. saying that the only reason he wasn't migrating to quickbook from ReStruturedText was because emacs had an rst-mode but not a qbk-mode.
That's one of the major obstacles. But I'm not ever planning to change the MPL reference manual sources (which are mostly Aleksey's creation/domain anyway) over unless there's some distinct advantage to doing so.
I thought he asked from help in creating such an emacs mode.
I did.
Of course, now that you mention no intention of migrating, I suppose he was talking about other libraries beside mpl.
Yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Aleksey Gurtovoy -
David Abrahams -
Jonathan Turkanis -
Larry Evans