From: eldiener@tropicsoft.invalid   
      
   On 5/16/2013 8:44 AM, James K. Lowden wrote:   
   > On Tue, 14 May 2013 10:33:26 -0700 (PDT)   
   > Joshua Maurice  wrote:   
   >   
   >> On May 13, 11:11 pm, "James K. Lowden"  wrote:   
   >>> The serialization system would recognize "node" as a UDT, taken   
   >>> from the list of types provided by the compiler, and would   
   >>> therefore have access to the metadata array describing the   
   >>> members.  Pointers are denoted as offsets into the stream.  In   
   >>> reality, the stream reflects what the compiler itself must do to   
   >>> maintain the graph in memory.  (Because, after all, pointers are   
   >>> just offsets from zero into the linear address space we call   
   >>> "memory".)   
   >>>   
   >>> Of course, nothing prevents a graph built from such a structure   
   >>> from having cycles.  OTOH nothing prevents the serializer from   
   >>> detecting cycles.   
   >>   
   >> I take it you are talking about something very much like the Java   
   >> standard serialization scheme, and how more or less you can use a   
   >> generic piece of code to serialize any object graph in Java. You   
   >> can do that in Java. It can even handle cycles.   
   >   
   > Yes.  Not that I admire Java; I don't.  But I do think the C++   
   > community has a blind spot when it comes to I/O.   
   >   
   >> You cannot do this with generic C++. You can do this with Java   
   >> because of the very strong type safety. C and thus C++ have   
   >> inherited some weaker typing rules that make this impossible in the   
   >> general case.   
   >>   
   >> How would you serialize this data structure?   
   >>   
   >> struct Foo { void* p; size_t x; size_t y; };   
   >   
   > Given the language as it stands today, that can't be done, it's   
   > true.  It might well represent   
   >   
   > 	double[10][10];   
   >   
   > and there's no way to know.  And that's exactly what I'm saying   
   > should change.   
   >   
   > Consider: the compiler (or the heap) knows exactly the extent of the   
   > memory pointed to by Foo::p.   
      
   The compiler knows no such thing. It only knows that 'void* p' is a   
   pointer. What you think the "heap" ( whatever that is ) knows you need   
   to explain.   
      
   You cannot expect a run-time type system to do analysis of a program's   
   instructions at run-time to determine what a particular serialization   
   should be. The overhead of that would be ridiculous even if it were   
   possible.   
      
   You have made a good point that the compiler could have enough   
   information to do run-time serialization of some objects, so there is   
   no need to throw out your ideas entirely. But given the much more   
   liberal notation of data in C++ ( in particular C++'s pointer notation   
   ) than in other popular statically typed languages, doing automatic   
   serialization of all UDF would be impossible without the end-user   
   specify a notation, ala IDL, to do some of it.   
      
   I also believe that the possibility of run-time type programming could   
   be implemented in C++ with greater support from the compiler, but I am   
   not naive enough that this can be done with every UDF without some   
   sort of extended notation ( syntax ).   
      
      
   --   
         [ 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)