From: jklowden@speakeasy.net   
      
   On Fri, 24 May 2013 17:06:11 -0700 (PDT)   
   Francis Glassborow  wrote:   
      
   > >> I don't consider CORBA a "library solution" (setting aside   
   > >> whether it's a solution at all, to anything).  CORBA is not a C++   
   > >> library.  It's a foreign system with C++ bindings.   
   > >   
      
   > > So may it be - but does it matter? You need a solution, you got   
   > > one.  Why does C++ need to address this problem if there is a   
   > > solution that works.   
   >   
   > WG21 is usually very reluctant to introduce changes to the core   
   > unless they solve wider problems. I suspect that reflection might   
   > help to solve serialisation problems but it will also help in quite   
   > a few other ways (or so I am told) So the serialisation problem   
   > might add motivation for reflection.   
   >   
   > However there is another issue. The problem is not just endian-ness.   
   > C++ specifies very little about fundamental types and that is a   
   > deliberate design decision that has been around since the beginning   
   > (and has been reconsidered and re-affirmed).  If different   
   > implementations have different widths for int how will serialisation   
   > help in transfer of int data between programs even given a solution   
   > to the endian-ness?   
      
   There's no general solution to that, right, because we can't 10 pounds   
   of flour in a 5-pound sack?   
      
   In a more limited way, though, I don't see the difficulty.  The   
   protocol can define or transmit the information required for the   
   receiver to interpret the data correctly.   
      
   As the guy who'd like to write that library, I'm stymied not by things   
   I can detect but by things I can't.  I can, awkardly, determine the   
   endianism and size of integer types.  I can't know the number of bits   
   (or sign) of a char, but I'm willing to assume or specify 8 bits,   
   signed, because that's hugely popular.   
      
   I'd be happier, though, with access to a table whose tuples gave name,   
   bit-size, endianism, and bit-semantics (not only sign but schema e.g.   
   two's complement) for every primitive type.  it's not enough just to   
   embed such a table in the executable or translation unit.  For it to   
   be used by a library, it must be accessible through the language.   
      
   (Someone will object, correctly, that we cannot know what bit-level   
   semantics may be implemented in the future, and conclude, incorrectly,   
   that we cannot therefore enumerate the widely used small set of   
   existing ones.  The problem is neither large nor complex.  As an order   
   of magnitude, the variety of int sizes, char sizes (in bits), integer   
   bit semantics, and floating point representations for which, say, GNU   
   can produces executable code each number less than 10.)   
      
   Where the language really falls down is class/struct member   
   enumeration.  There's simply no way to iterate over the members of a   
   struct.  Because of that, there's no way for a library to map the rows   
   in a database to an in-memory struct, even if the names and types of   
   the struct members exactly match those of the columns in the database   
   table.  And that's just one important specific example.  In general   
   it's impossible to map any C++ data structure onto an external   
   definition, except by hand.   
      
   > Now rather than messing with the core of the language it would, I   
   > think, be very helpful if implementers ensured that relevant   
   > meta-data was retained in object files so that linkers could ensure   
   > that all TUs were compatible (e.g. every object file should contain   
   > a header identifying the settings of all compiler switches.   
      
   Yes, except for "rather than".  :-)   
      
   I doubt there is much demand for linkers that can ensure TU   
   compatibility.  The answer to that has generally been "recompile".   
      
   Even a linker -- as currently defined -- that could detect   
   incompatible TUs couldn't do much more than abort with a diagnostic.   
   A "linker" that marshalls incompatible data across TUs would be a very   
   different beast indeed.   
      
   As a practical matter, getting implementations to do anything in a   
   standard way not specified by the standard is a lost cause.  We have   
   25 years of name-mangling as a poster child.  :-(   
      
   --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)