From: jklowden@speakeasy.net   
      
   On Sat, 18 May 2013 06:45:59 -0700 (PDT)   
   Edward Diener  wrote:   
      
   > >> 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.   
      
   Of course it does, as you well know.  The information isn't recorded in   
   the pointer, but any allocated memory -- no matter how allocated -- has   
   size.  That size is tracked by the compiler/stack/heap.  It's C++'s way   
   of keeping everything from using the same space.   
      
   If you constrain yourself to thinking that the only thing the compiler   
   knows about void* is sizeof(void*) and its value, yes, your Foo can't be   
   serialized. If you allow the language to  be changed to track the size   
   of any memory assigned to any pointer, it can.   
      
   > What you think the "heap" ( whatever that is ) knows you need   
   > to explain.   
      
   What do you want me to call it?  The free store?  I'm not trying to be   
   obscure; I'm using standard terminology afaik.  Last I checked,   
   operator new was just malloc in heap's clothing, at least in GNU's   
   implementation.   
      
   > 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.   
      
   I don't believe I every suggested any run-time analysis.  All I've ever   
   mentioned is the potential utility of metadata:   
      
   1.  static metadata about class/union/struct members   
   2.  the static type-system graph   
   3.  pointer extents   
   4.  last-used union member   
      
   Also useful would be   
      
   5.  __ENDIAN__ or similar, and automatic conversion   
      
   Of these #1 is #1, because it would permit automatic handling of   
   the collection-of-records that are the bread and butter of I/O.   
      
   --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)