From: jklowden@speakeasy.net   
      
   On Wed, 22 May 2013 09:28:01 -0700 (PDT)   
   Thomas Richter  wrote:   
      
   > On 16.05.2013 14:40, James K. Lowden wrote:   
   > > 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.   
   >   
   > 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.   
      
   > 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.   
      
   What you could not do is extend I/O streams to deal with user-defined   
   types.   
      
   > 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.   
      
   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.   
      
   > 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?   
      
   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.   
      
   > > 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.  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.   
      
   > >> 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.   
      
   > You seem to believe that most problems are database and serialization   
   > problems, but they aren't. Honestly, I believe you're holding the   
   > telescope the wrong way. (-;   
      
   Kudos for the apropo emoticon!   
      
   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.   
      
   > > We have typeof and sizeof and offsetof.  We do not have, say,   
   > > memberof or nameof or parentof or childof.   
   >   
   > In terms of inheritance, it should be possible to do that by language   
   > means and template magic   
      
   Maybe, but that is not a general solution.   
      
   > In terms of "pointers", it cannot be solved by the language in first   
   > place. C++ has no language means to identify a tree as a tree   
      
   Nor does it need one.  Do you deny that the tree exists, or that the   
   language could provlde an iterator for it?   
      
   > > 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.   
   >   
   > Correct, but that's how C++ is defined. It is a design decision that   
   > has been made, on purpose, because C++ is a derivative of C, and as   
   > such still very close to the bare metal. Making such features   
   > accessible would impose run-time overhead most people don't need, so   
   > it wasn't required.   
      
   Yes, that's how it's defined.  I dispute the costs.  I'm not aware of   
   any research on the topic that quantify them.  We already bear much of   
   the cost ourselves, by repeating metadata in the form of data.   
      
   > > Now, suppose you could trap SIGSEGV and walk the stack in your   
   > > program, using standard functions to identify each object by name   
   > > and type.   
   >   
   > Which would impose quite an implementation overhead not needed by most   
   > programs. But still, an implementation could support it. But,   
   > actually, I *don't need it*, so I don't want to pay for the feature.   
   > Actually, such a thing would probably require that function inlining   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)