From: bart@ingen.ddns.info.invalid   
      
   On Mon, 13 May 2013 23:11:46 -0700, James K. Lowden wrote:   
      
   > We don't need *the* one correct way.  We would benefit, though, from a   
   > correct, reversible way.  There is no reason it can't be done   
   > mechanically.   
   >   
   > For the reader's reference, the struct in question is   
   >   
   > 	struct node { int value; node* left; node* right; } n;   
   >   
   > How, you ask?  I'd do something I bet very like what you would do. What   
   > I do not see is why the standard library couldn't do it for me, with a   
   > little information from the compiler.   
   >   
   > I hope someone better versed in graph theory will come to my rescue, but   
   > here's a plausible Monday night hack:   
   >   
   > byte    type    size    value   
   >      0   node      20       -   
   >      0   int        4       x   
   >      4   node*      8      20   
   >     12   node*      8      40   
   >     20   node      20       -    // n.left   
   >     20   int        4       y   
   >     24   node*      8      60   
   >     32   node*      8      80   
   >     40   node      20       -   
   >     40   int        4       z    // n.right   
   >     44   node*      8     100   
   >     52   node*      8     120   
   >     etc.   
   >   
   > I wrote that in ASCII of course, because we're two humans communicating.   
   >  For communication between C++ programs, the above information would   
   > better be tokenized.   
      
   Trees are not that difficult to serialize. How about a slightly more   
   complex structure:   
      
   class X {   
     struct t {   
        size_t a;   
        char* b;   
     };   
      
     size_t c;   
     union {   
       char d[sizeof(t)];   
       t e;   
     } f;   
   };   
      
      
   An astute reader might recognize this as a possible layout for   
   std::string with short-string optimization. I have deliberately used non-   
   descriptive names for the members, because the compiler can't derive   
   meaning from the names either.   
   What would an auto-generated serialization format for this structure look   
   like?   
      
      
      
   > The problem as I see it is that the type system is unavailable at   
   > runtime.  The information I'm describing -- class hierarchy, member   
   > structure -- is discarded by the compiler (except insofar as it's made   
   > available to the debugger).   
   >   
   > Although the vogue term is "reflection", the idea is older than ancient.   
   >  Classes in Smalltalk could be interrogated at runtime. (Heck, IIRC   
   > classes could be *modified* at runtime.  But we won't go there!)   
      
   But, having reflection is not sufficient to do proper serialization of   
   user-defined types.   
   Look at the type X declared above. An auto-generated, reflection-based   
   serialization scheme would probably quite complex. But a hand-written   
   serialization routing would probably use the same format as for a char   
   array. All the rest is not an intrinsic part of the type, but is present   
   to allow certain optimizations and does not need to be included in the   
   serialization format.   
      
   >   
   > --jkl   
      
   Bart v Ingen Schenau   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)