f2d6b8a2   
   From: jklowden@speakeasy.net   
      
   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 problem is not that "pointers can't   
   be serialized".  The problem is that the compiler provides   
   insufficient information to the would-be serializer.   
      
   Please note this is not a deficiency of the type system.  The compiler   
   has no trouble dealing with your struct Foo.  It's just a little   
   tight-lipped about how.   
      
   Even if you can demonstrate that it's impossible in the general case   
   -- something I'm not going to make easy! -- must we then say there   
   isn't a large class of problems for which it *would* be useful?   
      
   I would say it falls in the same class of operations as the copy   
   constructor.  The compiler generates one for you if you invoke it.  If   
   it doesn't DTRT you're well advised to write your own.   
      
   > Throw on legal but obfuscated legal pointer arithmetic, and you've   
   > already lost.   
      
   Not at all.  If it's valid C++, it's representable externally, too,   
   just as in memory.   
      
   I'm actually saying something extremely simple and very easy to agree   
   with: if all the aspects of the program were available *to* the   
   program, the program could do exactly what the machine does.  No one   
   thinks it's peculiar that a debugger chases pointers, or that gdb can   
   recapture them from a core file.  We can argue about need and cost,   
   but the answer to feasibilty is found in implementations all around   
   us.   
      
   --jkl   
      
      
   --   
         [ 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)