Re: [boost] [Boost-interest] C++ library for runtime-concepts (type-erasure)

Subject: Re: [boost] [Boost-interest] C++ library for runtime-concepts (type-erasure)
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-02-15 11:58:32

On Tue, Feb 15, 2011 at 3:34 PM, Daniel Larimer <dlarimer_at_[hidden]> wrote:
> On 2/15/11 4:58 AM, "Germán Diago" <germandiago_at_[hidden]> wrote:
>
>>> I'm not sure if I understand correctly what you mean but if
>>> you are referring to transforming something like this...
>>>
>>> struct some_type
>>> {
>>> Â T1 m1;
>>> Â T2 m2;
>>> Â  ...
>>> Â Tn mn;
>>> };
>>>
>>
>> That was a goal of Boost.IDL interfaces, but I tried to make a summary of
>> what would be useful to take into account to design things that don't overlap.
>>
>>
>>>
>>> then it will be doable with Mirror (it actually already is
>>> in the old version and partially also in the new one
>>> but still undocumented).
>
> Color me very interested in how you achieved this. Â Though what I would
> really like to see is:

Basically the Mirror's registering macros create the following
two helper structures for every member variable:

template <typename X>
struct _by_name_typ
{
    typedef X member_variable_name;
};

template <typename X>
struct _by_name_val
{
    X member_variable_name;
};

then Mirror let's you choose the type(s) for X and compose them into
a single class via multiple inheritance. Currently only the 'by_name'
template class uses this to allow you to get access to member
variable meta-data via its name at compile time (although I could
not find too many use cases where this is really necessary to do :))

>
> struct some_type
> {
> Â  Â std::string append( std::string, double );
> };
>
> Converted Into functionally equivalent =>
>
> struct new_some_type
> {
> Â  Â future<string> append( string, double )
> Â  Â {
> Â  Â  Â  Â future<string> fut;
> Â  Â  Â  Â m_socket->async_sendto( serialize( s, d ),
> Â  Â  Â  Â  Â  Â host, boost::bind(wait_for_response, fut );
> Â  Â  Â  Â return fut;
> Â  Â }
> };

This is doable. Mirror does not implement it yet but
during the work on my master's thesis I've implemented
a simple RPC mechanism that did something very
similar to the above using reflection.

>
> Or converted Into =>
>
> struct some_new_type
> {
> Â  Â function<string(string,double)> append;
> };

Hmm, I've never considered turning a function into a member
variable but from the top of my head I don't see why this would
not work by using some variation of the approach described
above (well maybe overloads could cause some trouble...)

>
> Using just your Mirror mirror macros + templates?
>
> I am very impressed with Mirror, but its dependency on C++0x features that
> are not available in MSVC is almost a non-starter for me. Particularly
> because even though gcc supports much of C++0x, Mac OS X Development Tools
> still comes bundled with gcc 4.2.1 which does not support ANY C++0x.

Thank you and,
yes, this is a problem, but I hope that other compilers besides GCC
will implement C++0x after the final vote in March, many are already
working on it. Anyway I believe the transition from C++98 to C++0x was
worth it. In pre-C++0x I've spent more time struggling with the compilers
to do basic things that now work perfectly.

I do a lot of Windows programming myself and in projects using
Mirror I'm stuck with Cygwin so getting Mirror going in MSVC is
also one of my priorities.

>
> If you can show an example of how mirror would accomplish that, I will have
> to reconsider my approach to Type Erasure, RPC, and serialization.
>
> What is the status of Mirror's review for inclusion in official Boost?

There are several things currently preventing me from submitting
Mirror for review:

1) As already discussed above it is not (yet) portable because of
the lack of support for C++0x by the compilers

2) Expectation of breaking changes. I'm not going to submit the library
for review until I'm at least 95 percent sure that there will be no breaking
changes in the existing things. Now I'm somewhere around 70% :)

3) Few things to finish (like the manipulator generator mentioned before,
the transformations discussed above and some others)

4) Documentation

5) Missing unit-tests

As for a specific date, I've already made so many promises
to various people about the submission for review that even
I consider myself a liar now :) so I've stopped doing that.

BR,

Matus