Boost logo

Boost :

Subject: Re: [boost] [Signal] Variadic template implementation of signal/slot
From: Kevin Brandon (staticrealm_at_[hidden])
Date: 2009-05-23 02:43:33


On Fri, May 22, 2009 at 8:12 AM, Frank Mori Hess wrote:
>If you like, you can try implementing a signals2/variadic_signal.hpp based on
>the preprocessor template code in signals2/detail/signal_template.hpp.

Last night I continued with my pursuits of using my class that I presented while
 I was waiting a response. For a test I created a signal that used a
function that
returned type void. It became clear to me as I researched the failing cause of
trying to have template that returns a void, that I needed to use some template
specialization.

  My c++ and c is strong; however, the last several years I have been
pretty focused
on Java. Template specialization, template meta programming, and the
entirety of
boosts functionality is pretty new to me. That said I still would
really love to help with
this effort... Although it seems like your running pretty well with
the idea Frank, and
signals2 is your baby.

Fri, May 22, 2009 at 1:14 PM, Frank Mori Hess wrote:
> But it seems to me now the existing signal interface might just need one
change to be implementable without preprocessor metaprogramming
   So does this pretty much settle it? Would this be the variadic
template implementation for Signals2?

On Fri, May 22, 2009 at 1:14 PM, Frank Mori Hess <frank.hess_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 22 May 2009, Doug Gregor wrote:
>> I think it would be really, really cool to have a version of Signals2
>> that uses variadic templates rather than preprocessor metaprogramming.
>> For me, personally, I'd rather see it as an alternative implementation
>> of exactly the same interface (switched based on
>> BOOST_NO_VARIADIC_TEMPLATES) rather than a separate library. But,
>> that's up to Frank :)
>
> That seems like the way to go.  I was thinking it might be good to expose a
> separate variadic_signal which was completely free of preprocessor
> metaprogramming, instead of keeping it entirely as an implementation detail.
> But it seems to me now the existing signal interface might just need one
> change to be implementable without preprocessor metaprogramming.  The
> arg1_type, arg2_type, etc typedefs need to be replaced with a template, so
> for example
>
> typedef signal<void (int)> sig_type;
>
> sig_type::arg1_type
>
> would look something like
>
> sig_type::arg<0>::type
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoXB5oACgkQ5vihyNWuA4VgdwCgjSgN47i0nI1wLR1PfTwB7YgL
> sakAn0AFMHpB/sl29O8uv4sjwpKm8ujo
> =9Sj2
> -----END PGP SIGNATURE-----
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk