From: firstname.dot.lastname@googlemail.com   
      
   On Tue, 21 May 2013 07:08:03 -0700, James K. Lowden wrote:   
      
   >> 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?   
      
      
   Just to confirm what you mean:   
      
   let's say we have:   
      
   struct Foo   
   {   
   	//some variables   
   	double a_double;   
   	//some more variables;   
   };   
      
   Let's say we have a pointer:   
      
   double* d;   
      
   One can imaging that the information already exists so that the system   
   can know whether d points to the stack, the heap or some other area not   
   covered by the other two. Let's assume that it points to the stack.   
      
   If d points into the heap somwehere, it is not too much of a stretch to   
   know where the beginning of the chunk of allocated memory is, and how big   
   it is.   
      
   > 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.   
      
   I'm not sure it does solve that entirely. What it would solve is that the   
   serialisation system could know that the memory that d points into has   
   been serialised. That way it could know that (a) the pointee of d has   
   been written and (b) where it is, so it could then serialise d itself in   
   some appropriate way.   
      
   In principle, if you know the chunk of memory that d points into, then   
   you could dump out that entire chunk. If d points into double[10], then   
   it would work (endian and format issues aside). If it points into a struct   
   with pointers and other data, then the compiler would dump out a bunch of   
   meaningless information. I suppose that's OK, since that information   
   wouldn't have been reachable from d anyway, so it does not really matter   
   if it's filled with junk.   
      
   Is this effectively what you're saying?   
      
      
   -Ed   
      
      
   --   
         [ 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)