To serialize a class or structure I need to serialze each type (not hard)
then in the class serialize each variable. For a simple structure, such as
holding integers and std::strings, if there was some way to iterate through
the variables it would be simple something like in pseudo code:

std::ostream& operator<<( std::ostream& os)
{
   for_each_member( os << member );

I can't even think how to try to do this in C++ currently.

--
Jim Langston
tazmas...@rocketmail.com

Best,
Hernan

http://www.boost.org/libs/serialization/doc/index.html

There was also some posts about database interfaces here:

http://archives.free.net.ph/message/20061205.092349.9e2ebf91.en.html

HTH
-Larry

#include <iostream>
#include <string>

#include <boost/fusion/adapted/struct/adapt_struct.hpp>
#include <boost/fusion/algorithm/iteration/for_each.hpp>

using namespace std;
using namespace boost;

// structure, which fields you'd like to iterate
struct asset
{
    string name;
    double price;

struct print
{
    print(ostream & strm) : m_strm(strm) {}

    template <class T>
    void operator()(const T & val) const
    {
        m_strm << val << endl;
    }

private:
    ostream & m_strm;

#include <iostream>
#include <string>

#include <boost/fusion/adapted/struct/adapt_struct.hpp>
#include <boost/fusion/algorithm/iteration/for_each.hpp>

using namespace std;
using namespace boost;

// structure, which fields you'd like to iterate
struct asset
{
    string name;
    double price;

struct print
{
    print(ostream & strm) : m_strm(strm) {}

    template <class T>
    void operator()(const T & val) const
    {
        m_strm << val << endl;
    }

private:
    ostream & m_strm;

C++ does nto currently have a way to do it, it's not part of the language.

--
Jim Langston
tazmas...@rocketmail.com

With a lot of work (and a lot of peeking at the boost preprocessor
library) I was able to write a macro DECLARE_FIELDS that allows you to
write this:

class Pipo
{
        public:
        DECLARE_FIELDS
        (
                ((int,a))
                ((string,b))
        )

class Op
{
        public:
        template<class T>
        void operator()(const T& t) const
        {
//              cout << t << endl;
        }

Writing such code is an interesting challenge, but it feels really wrong
that we should need to do something so complicated as this to something
as essential as eliminating redundancy.

Ideally it should be possible to do this within the language itself. If
we have to resort to using the preprocessor it would help a lot if we
actually had a decent preprocessor, instead of the brain-dead
preprocessor we have today.

I would rather see it done in the language itself, but realistically,
it's going to be long time before C++ has evolved enough to make most of
the subtle trickery in boost unnecessary. In the meantime it would help
a lot if we had a decent preprocessor. It seems to me that it wouldn't
be too difficult to add functionality to the preprocessor that
eliminates most of the trickery in the boost preprocessor
metaprogramming library. I'm thinking of if's and for's, overloading and
recursion. We are already getting variadic macro's.

But perhaps things are more subtle than I think. I wonder what the
experts think about this.

#include <iostream>
#include <string>

#include <boost/preprocessor.hpp>
#include <boost/fusion/adapted/struct/adapt_struct.hpp>
#include <boost/fusion/algorithm/iteration/for_each.hpp>

#define DEFINE_STRUCT(name, fields)          \
    DEFINE_STRUCT_I(name,                    \
        BOOST_PP_CAT(DEFINE_STRUCT_X fields, 0))

#define DEFINE_STRUCT_X(x, y) ((x, y)) DEFINE_STRUCT_Y
#define DEFINE_STRUCT_Y(x, y) ((x, y)) DEFINE_STRUCT_X
#define DEFINE_STRUCT_X0
#define DEFINE_STRUCT_Y0

#define DEFINE_STRUCT_I(name, fields)        \
    struct name                              \
    {                                        \
        BOOST_PP_SEQ_FOR_EACH_I              \
            (DEFINE_STRUCT_FIELD, _, fields) \
    };                                       \
    BOOST_FUSION_ADAPT_STRUCT_I(name, fields)

#define DEFINE_STRUCT_FIELD(r, _, i, xy)     \
    BOOST_PP_TUPLE_ELEM(2, 0, xy)            \
        BOOST_PP_TUPLE_ELEM(2, 1, xy);

using namespace std;
using namespace boost;

DEFINE_STRUCT(asset,
    (string, name)
    (double, price)
)

struct print
{
    print(ostream & strm) : m_strm(strm) {}

    template <class T>
    void operator()(const T & val) const
    {
        m_strm << val << endl;
    }

private:
    ostream & m_strm;

Is there a comma missing after (string, name) or does it work as is?
Your example suggests that you are in fact allowed to have macro
arguments span multiple lines, something I wasn't sure of. Can anyone
confirm this is the case?

And is this something you would use in production code? I imagine it
confuses things like Intellisense, which would be a pity.

It seems to me that we aren't very far removed from what needs to be
done to do this sort of thing without boost. If type lists were added to
typeinfo, wouldn't that do the trick?

By the way, boost itself heavily uses preprocessor
metaprogramming. In C++0X most of it will go away, but at the
moment you either have to copy-pase large chunks of code,
use preprocessor or generate code with the help of external tool.

Regards,
Roman Perepelitsa.

I meant that type_info seems like the right place to store detailed
information about types. If I'm not mistaken, about all it does now is
generate an implementation-defined string representation and allow
instances of type_info to be compared for equality.

For persistance, serialisation etc you'd want to be able to loop over
all members and for each member be able to fetch a pointer to member.
With that pointer you could retrieve a value from an instance of the
type and write it to a stream or something. This isn't really a
typelist, but more a list of pairs of strings and function pointers.

I don't think you can fit this information into a fixed data structure
such as the type type_info. What you could do is have the compiler
generate a new subclass of type_info for every type whose typeinfo you
retrieve with typeid.

I was thinking that if we give type_info a virtual member ForEach, we
could use it to loop over the elements of the type and do something
appropriate. Now that I think more closely about it, I think that would
require a combination of member templates and virtual functions, which
is not possible at present and unlikely to be in future. Maybe you could
do something with decltype. Or maybe it is harder than I think.

I guess I'm just wondering how difficult it would be to add proper
reflection to C++. It would be nice if you could pass a templatised
closure to type_info.ForEach... How far do you think we are away from this?

class CC{
  public: int i;
  private: double x;

std::tuple_representation<CC> & ccTuple =
std::tuple_representation(cc);
ccTuple.get<0>(); // ok, return 1
ccTuple.get<1>(); // error: function
"std::tuple_representation::get<1>()" is private.

Would it be feasible?
Andrzej Krzemienski

/This type is similar to a tuple, but holds pointers
template <class... Args>
class DataSerializer {...};

class MyClass
{
public:
    typedef DataSerializer<int, float> serialization_data;

private:
    int a;
    float c;

public:
    SerialData data(){ return serialization_data(a, c); }

class AnotherClass
{
    int a;
    string b;

    //MyClass meets serializable concept
    MyClass m;

    typedef SerialData<int, string, MyClass> serial_data;

   serial_data data() { return serial_data(a, b, m); }

AnotherClass c;
save(c, myfile);

save is a generic algorithm that can serialize serializable types, as
long as they meet requirements.
So with minimal code, you can serialize data. Next things are pointers
and stl containers.

Regards,
Roman Perepelitsa.

 > What would be really useful is something

     I suppose something could be hacked up involving recursive template
instantiation.   One could have a primitive like like "typeof_field(T,N)",
returning the type of field N of object T.  Then, using recursive
templates, one could iterate through the fields.  It might also be
useful to have "field_count(T)", for termination checking.

     This would be useful for automatically generating marshalling code
at compile time.  That can be a substantial win, because marshalling code
usually consists of trivial copies slowed down by the run time machinery
which invokes them.

                                        John Nagle
                                        Animats

Brian Wood
Ebenezer Enterprises

http://www.boost.org/doc/html/boost/visit_each.html

quoting from there:

The visit_each mechanism allows a visitor to be applied to every
subobject in a given object.

HTH.

-regards,
Larry

I believe this design is fairly good:

template<typename T>
struct reflection {};

template<> struct reflection<MyClass>
{
     typedef mpl::map<
         mpl::pair<
             mpl::vector_c<char, 'm', 'e', 'm', 'b', 'e', 'r', '1'>,

a_function_object_type_which_allows_to_get_the_member_and_exposes_its_type
         >,
         ....
     > member_variables;

     typedef .... member_functions; /* same as member_variables except
the function object must expose and allow to call multiple overloads
*/

     typedef .... typedefs; /* nothing more than a type -> type map */
     typedef .... static_member_functions; /* same as
member_functions, except we don't take an object in the functor
constructor */
     typedef .... static_member_variables; /* same as
member_variables, except we don't take an object in the functor
constructor */

     typedef .... constructors; /* a single function object */

     typedef .... base_classes; /* a list of base types */

The only problem is how to expose the type of template member
functions.
Doing so would be quite complicated.

For example, to encode
template<int A, typename B> typename B::type func(B&, void*),

we could expose the template parameters and then construct an
expression tree for each element of the signature.

typedef mpl::vector<
    mpl::pair< mpl::vector_c<char, 'A'>, value_parameter<int> >,
    mpl::pair< mpl::vector_c<char, 'B'>, type_parameter >

Another simpler but less powerful way would be to expose the template
parameters and then allow the signature to be extracted given the
parameters.

typedef mpl::vector<
    mpl::pair< mpl::vector_c<char, 'A'>, value_parameter<int> >,
    mpl::pair< mpl::vector_c<char, 'B'>, type_parameter >