From: thor@math.tu-berlin.de   
      
   On 23.05.2013 07:49, James K. Lowden wrote:   
   >   
   >> You already did. CORBA does solve the problem nicely. Probably   
   >> "inverse" from the way you want it because you first have to write   
   >> the IDL and not the C++ classes, but anyhow, it'll do.   
   >   
   > So say you.  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.   
      
   >> If I had the same problem, I would probably write my "classes to be   
   >> serialized" in a restricted C++ dialect, then write a yacc or bison   
   >> code to parse that, and generate the necessary code automatically.   
   >   
   > Yup.  Instead of using the language you already have, you'd recreate   
   > the information discarded by the compiler in a bespoke, nonstandard   
   > way.   
      
   Why "nonstandard"? It's probably another standard. But certainly not the   
   C++ standard. As I already said, I believe there is no need to put this   
   burden on the shoulders of the C++ standard as there are solutions that   
   address this problem, and they work with C++. IOW, why do you care   
   whether this is part of C++ or not?   
      
   > What you could not do is extend I/O streams to deal with user-defined   
   > types.   
      
   Why not? Of course I could. It's the matter of generating the code for it.   
      
   >> Or I would pick java right away, which has such things built in.   
   >   
   > Yeah, except there is no "pick".  Stroustrup says there are billions of   
   > lines of extant C++, and some 3 million C++ programmers.  Every one of   
   > those systems reads and writes data.  Many thousands of those   
   > programmers have dealt with I/O, some not very well.   
      
   Why is that an argument against using java? Sorry, I don't understand.   
   The 3 million lines of code certainly do not need serialization. While I   
   cannot give you numbers, I would believe that only a minority of them   
   would profit from it, or solved it otherwise.   
      
   In the same vain, one could argue that C++ needs a standard GUI library,   
   a library that allows users to create graphical front-ends. It's really   
   missing, there are 3 million lines of C++ out there... and actually, I   
   (personally) would profit from it.   
      
   > C++ has some unique features, even some *good* unique features.   
   > Judging from the billions of lines and the lousy I/O support, it's safe   
   > to say it gets picked for good reason, and that I/O isn't one of them.   
      
   Probably not. GUIs are neither a strong argument for C++. But then   
   again, why solve the problem with C++ then in first place. It is   
   probably not the right language for that.   
      
   >> So why do you write C++ libraries if you need to solve database   
   >> problems? These are typically I/O bound in my experience, and you   
   >> don't need the low-level control C++ offers.   
   >>   
   >>> 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.   
   >>   
   >> That is so general that it applies to every program. Actually, a   
   >> program without output is pretty much useless, I would say.   
   >   
   > Good.  So we agree, at least that output matters?   
      
   Sure. So we need a GUI library, right? Something to make my output   
   readable by a user, in a convenient way. And output means output to HTML   
   these days, so actually, we need an HTML + css creator within standard C++.   
      
   *Neither* of these features are part of C++ today. I believe for good   
   reason. There are already solutions for them, so there is no need to put   
   them into the standard.   
      
   > In case it helps, the problems I face day-to-day are compute-bound.   
   > Efficiency is very important.  So is getting data in and out of the   
   > system, and sharing it with the rest of the organization.   
      
   So again, why not java? Have you made benchmarks?   
      
   >>> 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.   
   >>   
   >> Sorry, but how is that supposed to work? If I de-serialize two   
   >> objects, how can one ensure that they have the same offset they had   
   >> when they were serialized?   
   >   
   > I don't see the problem.  If, when those objects were serialized, the   
   > values of their pointers were stored, too, then on de-serialization you   
   > would have the exact information you needed to know if they were one and   
   > the same object.   
      
   How, and why? You need a unique identifier that identifies all the   
   objects you have written, then again on input, you need to scan this   
   information, need to keep the IDs in a local database, and re-set the   
   pointers correctly. Ok, probably do-able. But why do I need to put all   
   this stuff into the C++ core?   
      
   > I don't know what you mean by "same offset"; they   
   > don't need to have the same locations in memory, except relative to   
   > each other.   
      
   They will certainly not end up in the same relative offset. At least not   
   under a multitasking operating system.   
      
      
   >>>> 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.   
   >>   
   >> That depends on your problem domain. The problem actually *is*   
   >> unimportant for most C++ users, which is exactly why it is not part of   
   >> the language.   
   >   
   > That's not clear at all.  The language was invented before it was   
   > used.  As I pointed out elsewhere, it predates the Internet, the   
   > dominance of tcp/ip, and SQL.  I rather think C++ reflects   
   > its era and its origin in the land of C, not what's important to the 3   
   > million programmers using it in 2013.   
      
   ...and GUIs, don't forget the GUIs.... (-:   
      
   Honestly, for all that stuff are solutions that interact nicely with   
   C++. So again, why does that have to go into the language core?   
      
   > No, I'm simply addressing myself to the problem of I/O because I note   
   > it's a void in the language and the cause of a lot of work and   
   > nonstandardized behavior that would otherwise be unnecessary.  It's   
   > something I claim to know something about, and something we cannot   
   > program around.   
      
   You can't? I can. See above, it looks like a practical solution that   
   works. I mean, CORBA basically works this way. You write the idl, and   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)