Re: [Boost-users] [FunctionTypes] function_arity for non-built-ins

On 1/6/2011 4:00 PM, Larry Evans wrote:

On 01/06/11 12:51, Edward Diener wrote:

...

On 1/6/2011 12:32 PM, Larry Evans wrote:

...

On 01/06/11 08:48, Roman Perepelitsa wrote:

...

2011/1/6 Hossein Haerimailto:powerprogman@yahoo.com>

Hi Roman,

> This is actually possible in most cases. Check this nice article by Eric > Niebler:

http://www.boost.org/doc/libs/1_45_0/doc/html/proto/appendices.html#boost_pr...

...

This is beautiful, thanks! :) So, from the description, it seems like this can_be_called guy (or its siblings) is in heavy use for Proto. Does Proto then also port this as a part of its toolbox? Or, is it only for internal use and I'll need to craft my own version of it?

Unfortunately, there's no official boost implementation of can_be_called. You'll have to roll your own version.

Eric's code was used as a basis for a variadic templates implementation of can_be_called which is available here:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/function_typ...

...

A use is shown here:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_st...

...

Are you still working on the variadic templates sandbox project ?

Yes.

...

What is the project meant to do ?

Originally, it was meant to just see if variadic templates could be used in a rewrite of mpl. Since then, I've been trying various other things, such as the multiple_dispatch code. I'd like to eventually see if the code can't be used as a springboard to using monads and list comprehension, like in the fc++ library:

http://sourceforge.net/projects/fcpp/

but, again, using variadic templates.

I am aware of fc++ library. Is not Phoenix supposed to be a replacement of most of the concepts in fc++ ? But Phoenix after years and years has still not been released as a Boost library for whatever reason. So I do not know if list comprehension or monads are part of Phoenix. I know what list comprehensions are from Python but I have never looked at monads or know for what they are useful.

Also, I'd like to see if something like the DeBruijn indices method, mentioned here:

http://lists.boost.org/Archives/boost/2010/09/171123.php

could be used to solve some problems I had in mpl, which *may* be related to name clashes since mpl uses _1 for the 1st formal arg of any Lambda Expression. However, there's another method, call HOAS (Higer Order Abstract Syntax) to avoid the same problem:

http://www.cse.unsw.edu.au/~chak/haskell/term-conv/

So, I may decide to grok that before I decide how to do thing.

It sounds like that essentially you are attempting to rewrite areas of boost.mpl using variadic templates. Are you adding new functionality to the mpl that is useful ?

In addition, several haskell papers mention using monads to provide a trace facility for language interpreters. For example:

http://www.cs.yale.edu/~liang-sheng/popl95.ps.gz

I thought maybe such a trace facility, translated to c++, would help debugging template metaprograms.

That would be spectacular. Anthing to help debugging template code and/or help with understanding compiler error messages is always most welcome by me.

...

It looks like you are using variadic templates for various Boost libraries.

Yes. I'm also thinking it could be used for spirit or proto or something akin to those. I know Christopher is working on variadic template fusion; so, I probably won't try that one.

My understanding of variadic templates is that it also could make some end-user interfaces much easier syntactically to use.

...

I am interested in using variadic templates in a sandbox project in which I am working, so I was interested when I saw your variadic templates library, but there was no explanation or documentation there.

The variadic mpl library is almost one-to-one with the original mpl; hence, I was hoping the docs for the original would suffice. The major difference is sometimes changing the order of the arguments to satisfy the variadic template compiler constraint that packs only occur at the end or the template argument list.

I appreciate your intent but I think you must be realistic that if you do not document at least the differences between what you are doing and what the current mpl is doing, nobody is going to want to study the source code just to see how it might be beneficial.

Now as far as composite_storage is concerned, I was hoping that just looking at the code and test drivers would make it apparent how it differs from boost::fusion containers and boost::variant. Basically,

* For tuple-like containers:

the only difference between:

fusion::vector < T1 , T2 ... ,Tn >

and:

composite_storage::pack::container < all_of_aligned , mpl::integral_c , T1 , T2 ... , Tn >

is the use of Enumeration literals instead of unsigned literals to access the elements *and* the use of c.project() instead of at_c<i>(c), for some container c, to retrieve the i-th element where, if c is from composite storage, then:

enum Enumeration { E_0 , E_1 ... , E_n };

* For variant-like containers:

There's a more substantial difference. For:

boost::variant < T1 , T2 ... , Tn > bv;

bv defaults to T1. In addition, changing the contained type just requires an assigment:

bv = T2();

OTOH, for:

boost::composite_storage::pack::container < one_of_maybe , mpl::integral_c , T1 , T2 ... , Tn > cv;

the user must explicity state which type is to be stored:

cv.inject(T2());

The reason for this difference is that it's more in line with the way mathematicians express the operation. In addition, it's more in line with the way unix yacc treats its tokens. For example, any token in yacc has an explicit tag, and this is just how one_of_maybe works.

Thanks for the explanations, especially about variant which I do know.

Hope that explains things more and why it's taking me so long to get things more documented.

Thanks for telling me about your library. At the worst I will look at it to understand better how to use variadic templates for some of my own work. I think variadic templates offer a good potential for certain programming idioms. Unfortunately still very few compilers support it so unless one is strictly targeting the few compiler/versions that do one has to also write templates without it. I apologize for partially hijacking this thread.