home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 33,048 of 33,346   
   Edward Rosten to James K. Lowden   
   Re: compilers, endianness and padding   
   16 May 13 10:08:42   
   
   From: firstname.dot.lastname@googlemail.com   
      
   On Thu, 16 May 2013 05:44:12 -0700, James K. Lowden wrote:   
      
   > 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?   
      
   That's not entirely obvious to me.   
      
   The heap knows the extent of the memory which is being pointed to and   
   could go and serialise it. However, what it doesn't and can't easily   
   know is the type.   
      
   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.   
      
   -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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca