cpp-netlib-devel

[cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

[Dean M. B. <mik...@gm...>]

I found one good hack to make the directives more generic and more
tied into the async-friendly messages. I've implemented it locally and
am in the process of gutting every directive we've ever written (I
really need to learn preprocessor metaprogramming at some point to
make this easier).

The basic pattern is this:

struct directive {
  boost::variant<
    string<tags::default_string>::type,
    string<tags::default_wstring>::type,
    boost::shared_future<string<tags::default_string>::type>,
    boost::shared_future<string<tags::default_wstring>::type>
  > value_;

  directive(string<tags::default_string>::type const & value)
    : value_(value) {}
  directive(string<tags::default_wstring>::type const & value)
    : value_(value) {}
  directive(boost::shared_future<string<tags::default_string>::type>
const & value)
    : value_(value) {}
  directive(boost::shared_future<string<tags::default_wstring>::type>
const & value)
    : value_(value) {}

  template <class Tag>
  struct value :
    mpl::if_<
      is_async<Tag>,
      boost::shared_future<typename string<Tag>::type>,
      typename mpl::if_<
        is_sync<Tag>,
        typename string<Tag>::type,
        unsupported_tag<Tag>
      >::type
    >
  {};

  template <class Tag, class Message>
  struct value_visitor : boost::static_visitor<> {
    Message const & message_;
    value_visitor(Message const & message)
      : message_(message) {}
    void operator() (typename value<Tag>::type const & value) const {
      message_.value(value);
    }
    template <class T> void operator() (T const &) const {
      // FIXME -- fail here somehow at compile time
    }
  };

  template <class Message>
  Message & operator() (Message const & message) const {
    apply_visitor(value_visitor<typename Message::tag,
Message>(message), value_);
    return message;
  }
};

So yeah, the idea is metaprogramming technically saves the day... :)

Expect a few changes (well, technically a lot of changes ;) ) to come
into the branch.

Have a good one guys, and it's good to be programming C++ again. :D

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

[Glyn M. <gly...@gm...>]

Hi Dean,

On 20 August 2010 12:03, Dean Michael Berris <mik...@gm...> wrote:

> I found one good hack to make the directives more generic and more
> tied into the async-friendly messages. I've implemented it locally and
> am in the process of gutting every directive we've ever written (I
> really need to learn preprocessor metaprogramming at some point to
> make this easier).
>
>
Cool, this is what I need because I'm a little blocked.  Let me know when
you have something that I can play with and I'll take a look.
G

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

[Dean M. B. <mik...@gm...>]

On Sat, Aug 21, 2010 at 5:22 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 20 August 2010 12:03, Dean Michael Berris <mik...@gm...> wrote:
>>
>> I found one good hack to make the directives more generic and more
>> tied into the async-friendly messages. I've implemented it locally and
>> am in the process of gutting every directive we've ever written (I
>> really need to learn preprocessor metaprogramming at some point to
>> make this easier).
>>
>
> Cool, this is what I need because I'm a little blocked.  Let me know when
> you have something that I can play with and I'll take a look.

And you might have to wait a little longer. Now the problem I'm
reaching is the consequence of the Request concept applying to both
asynchronous and synchronous request objects. The Request concept
refines the Message concept, which defines some primitive operations
to be defined.

Now I've added modifiers to the requirement on the Message concept,
which means creating messages just got a little "harder" and more
involved.

Maybe at some point I'm just going to make a Directive concept too.

I'm learning that generic programming is a little more involved (but
really safe) and thus fun to implement. ;)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

[Dean M. B. <mik...@gm...>]

On Tue, Aug 24, 2010 at 6:33 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> And you might have to wait a little longer. Now the problem I'm
> reaching is the consequence of the Request concept applying to both
> asynchronous and synchronous request objects. The Request concept
> refines the Message concept, which defines some primitive operations
> to be defined.
>
> Now I've added modifiers to the requirement on the Message concept,
> which means creating messages just got a little "harder" and more
> involved.
>
> Maybe at some point I'm just going to make a Directive concept too.
>
> I'm learning that generic programming is a little more involved (but
> really safe) and thus fun to implement. ;)
>

And now at least the thing builds. I'll just have to much around with
the linking and CMake on windows, but it should be usable in the next
push I do which should be within the day (my day).

Fingers crossed...

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

[Dean M. B. <mik...@gm...>]

On Fri, Aug 27, 2010 at 5:13 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> And now at least the thing builds. I'll just have to much around with
> the linking and CMake on windows, but it should be usable in the next
> push I do which should be within the day (my day).
>
> Fingers crossed...
>

I've pushed to the 0.7-devel branch a huge thunk of changes. I'm
afraid this branch is so unstable that it's going to take a while
before I can get something remotely release-ready anytime soon.

The problem I'm facing right now is in the ensuring that the concepts
are met -- which is going to be crucial if we intend to let users and
others build message types that deal with CString, QString, and other
string implementations.

Hopefully the message concept gets pinned down soon. I'm going to take
on this personally so that we can get a move on in other more
important things like the HTTP server and the middleware that allows
for streaming input and streaming output from the handlers.
Asynchronous writes and reads on the handler level would also be
welcomed by a lot of people.

-- 
Dean Michael Berris
deanberris.com