From: jklowden@speakeasy.net   
      
   On Thu, 16 May 2013 10:08:42 -0700 (PDT)   
   Edward Rosten  wrote:   
      
   > Is Foo::p pointing to a double inside an array of doubles or is it   
   > pointing to the double inside:   
   >   
   > struct Bar   
   > {   
   > 	double d;   
   > 	some_other_type* a_pointer;   
   > };   
   >   
   > > 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.   
   >   
   > The debugger can always chase Foo::p and get what it's pointing to. It   
   > can then increment the pointer by sizeof(double) and show you what the   
   > next set of bits look like in double form, but it can't tell you if   
   > that operation is a valid one.   
      
   True, the heap has no type information.  What it does have is the bits   
   and the extent.  The meaning of those bits -- the structure imposed on   
   them by the programmer -- is known to the compiler, else the program   
   couldn't run, right?   
      
   So, yes, the heap can't distinguish between   
      
   > struct Foo { void* p; size_t x; size_t y; };   
   and   
   > struct Bar   
   > {   
   > 	double d;   
   > 	some_other_type* a_pointer;   
   > };   
      
   but that's not the problem we're discussing.  The problem is: given   
   Foo above, how to know how much to write, or, for that matter, how   
   much to allocate upon reading.   
      
   You may say, correctly, that splatting out a void* buffer from the heap   
   isn't very portable, that because we know nothing about what it's   
   pointing to, we have no way of reconstructing the object on the far   
   side unless the machines agree on many particulars.  My take on that   
   is: so what?   
      
   We're wandering down the rabbit hole here, concocting structures with   
   less and less information.  At the same time we're raising the bar if   
   we insist that such structures be transmitted both faithfully *and*   
   portably.   
      
   Let's exclude void* from consideration of *portable* serialization.   
   That's really OK.  The objective is not to move untyped bits over the   
   wire; we have write(2) for that.  The objective is to move perfectly   
   ordinary workaday data -- int, double, string, char* -- the everyday   
   stuff of I/O buffers, the kinds of things handled by XML and JSON and   
   YAML and DBMSs millions of times every day.   
      
   --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)