From: jklowden@speakeasy.net   
      
   On Mon, 13 May 2013 23:41:14 -0700 (PDT)   
   Thomas Richter  wrote:   
      
   >   > The minimum I would like to see is the ability to iterate over the   
   >   > members of a structure.   
   >   
   > Again, I typically don't need that, but it would include some   
   > overhead.  For example, the structure layout would likely need to be   
   > stored somewhere at run time. I don't need this overhead. But if you   
   > do, I'm sure a library solution is feasible which does that.   
      
   Really?  Name one.   
      
   The compiler does not supply the information that a library would need   
   to execute generic serialization.  That is why every serialization   
   library used by C++ requires the buffers to be externally defined.   
      
   >   > We spend far too much time today dealing with I/O, recreating by   
   >   > hand the very metadata discarded by the compiler.  With support   
   >   > from the compiler, C++ could provide easy, standard, robust,   
   >   > efficient, reliable I/O for user-defined types of arbritrary   
   >   > complexity.  Until then, we'll party on like it's 1985.   
   >   
   > I would rather say, you picked the wrong tool for the job in first   
   > place. I don't know what you do or which types of problems you want to   
   > solve, but C++ does not sound like the solution for your problem.   
      
   I think it's safe to say I understand the problem I'm trying to solve   
   better than you do.   
      
   > If your programs are mostly I/O bound, I would check for programming   
   > languages that offer a higher abstraction level than C++.   
      
   I pretty much have to use C++, because I'm writing, um, C++ libraries.   
   I didn't say the programs were I/O bound.  I am saying they're I/O   
   awkward.  That matters because any useful computation requires input   
   and output.   
      
   >   > Why do people think pointers can't be serialized?   
   >   
   > In specific, the above "serialization" cannot distinguish   
   > between two pointers that point to the identical object, and two   
   > pointers that point to similar objects.   
      
   Pointers are nothing more than offsets, counters from zero into linear   
   memory.  To write them out and read them back in requires only to   
   encode and decode them.  If it couldn't be done, "marshalling" wouldn't   
   be part of our working vocabulary.   
      
   > The problem is just that you now assume networking to be part of the   
   > language   
      
   No.  The problem is you're looking through the wrong end of the   
   telescope.  You seem to think the problem is unimportant and can be   
   solved with a library.  It cannot, and it matters.   
      
   We have typeof and sizeof and offsetof.  We do not have, say, memberof   
   or nameof or parentof or childof.  We have, in short, incomplete   
   ad hoc access to program metadata. Without complete access to that   
   data, it impossible to do many things that can be done in Java or   
   Smalltalk or Python.   
      
   Many people wrongly assume that's because C++ is compiled.  It's not.   
   It's because of *how* it's compiled.  It's because the C++ compiler   
   discards the metadata, or makes it available only in nonstandard ways   
   to the debugger, rather than to the language itself.   
      
   It applies to more than I/O, too.  For example, what happens when you   
   deference a NULL pointer?  You get a PDP-11-era "segmentation fault"   
   and, if you're lucky, a core file.  Then, with the help of the debugger   
   and a symbol table, you can track down the problem, maybe.  (Another   
   example of interpreting serialized pointers, btw.)   
      
   Now, suppose you could trap SIGSEGV and walk the stack in your program,   
   using standard functions to identify each object by name and type.   
   Better, because if that information were made available in a standard   
   way, a standard library could evolve to deal with it, and you could   
   just call, say, std::stacktrace in your exception handler.   
      
   > If most of your job is writing serialization code, this is even more   
   > an indicator that C++ is the wrong choice for the problem.   
      
   Do this for me, Richard.  Examine every C++ ODBC library you can find,   
   and think about why they're such a pain in the tukkus.  Go ahead, I'll   
   wait.  While you're there, consider whether or not there might not be a   
   large class of programs that would benefit from more convenient -- nay,   
   *standard* -- access to a DBMS.   
      
   --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)