Re: [boost] [local] Help for the Alternatives section

Subject: Re: [boost] [local] Help for the Alternatives section
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-05-06 13:32:25

On Fri, May 6, 2011 at 7:49 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> On Thu, May 5, 2011 at 2:03 PM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:
> > On Thu, May 5, 2011 at 10:53 AM, lcaminiti <lorcaminiti_at_[hidden]>
> wrote:
> > [...]
> >
> >> I have been thinking if I can do something similar to this with
> >> Boost.Local.
> >> Given that local classes cannot have template members I can't do too
> >> much...
> >> However, I _could_ allow to specify multiple types (but not a generic
> type)
> >> for a local function parameter:
> >>
> >> void BOOST_LOCAL_FUNCTION_PARAMS(types(int, char) x, types(double,
> >> std::string, int) y, long z) {
> >>    std::cout << x << y << z << std::endl;
> >> } BOOST_LOCAL_FUNCTION_NAME(l)
> >>
> >> Then I can do:
> >>
> >> l(1, 1.2, -1);
> >> l('a', 1.2, -1);
> >> l('a', "bcd", -1);
> >> ... // and all the other parameter type combinations
> >>
> >> types(...) could accept a generic number of types but all these types
> will
> >> have to be known (and not generic as for templates).
> >>
> > [...]
> >
> >> This is more overloading than polymorphism... bus still:
> >> 1) Compiles on ISO C++.
> >> 2) Declares l locally (information hiding).
> >> 3) Does not repeat l declaration multiple times (avoid code
> duplication).
> >> 4) l is """effectively polymorphic""" (in between _many_ quotes :) ) in
> its
> >> argument type num as it accepts both doubles and std::strings (but no
> more
> >> than these two types :( ). (I will not actually claim that such a local
> >> function l polymorphic in num's type.)
> >>
> >> What do you think?
> >>
> > Better than nothing (=strict monomorphicity)!
>
> Does anyone else think this feature is useful??
>
> This is _not_ trivial to implement so I won't do it unless you guys
> think it is useful. I might just document it as a possibility in the
> docs and implement it only if the library gets accepted...
>

Although it *is* "better than nothing", I wouldn't consider this a
necessity, whether or not it's easy to implement.

[...]

> > Not related to the above discussion: Bound variables' types are deduced
> > using Boost.TypeOf; is it possible right now to explicitly specify their
> > type?
>
> Yes, I think either you or someone else already asked for this feature
> a while back. It's on my to-dos and I will implement it before
> submitting the library for review.
>

Excellent.  Yes, it was probably me.

> I am trying to get this syntax to work but it's requiring good amount
> of coordination between preprocessor and template metaprogramming (I
> haven't given up yet :) ):
>
> const bind& x // bind without specifying the type (uses Boost.Typeof)
> const bind<int>& x // bind specifying the type (doesn't use Boost.Typeof)
>
> If I can't get that to work, the following should be possible without
> too much trouble (because I can handle both expression the same way
> and just with preprocessor metaprogramming):
>
> const bind& x // bind without specifying the type (uses Boost.Typeof)
> const bind_type(int)& x // bind specifying the type (doesn't use
> Boost.Typeof)
>

Would "const bind(int)& x" work?

If not, and assuming "const bind<int>& x" also doesn't work,
"bind_type(int)" sounds like an acceptable alternative.

- Jeff