From: thor@math.tu-berlin.de   
      
   { This thread is becoming somewhat repetitive.  Please keep that in   
   mind; thanks! -mod }   
      
      
   On 02.06.2013 22:41, James K. Lowden wrote:   
   >   
   > On Fri, 24 May 2013 10:59:24 -0700 (PDT)   
   > Thomas Richter  wrote:   
   >   
   >>> Like you, I live in the land of colossal computing where programs   
   >>> are measured in compute-hours (or days).  Unlike you, apparently,   
   >>> my programs also move a lot of data over the wire.  The basic   
   >>> questions I have, and I haven't found a convincing answer is:   
   >> *) Why is C++ the right solution for the job?   
   >   
   > I have answered that to the best of my ability.  When I tell someone   
   > that my compute jobs are measured in CPU-days, and am then asked why   
   > C++ is the right language, I tend to agree with Jamie Zawinski that   
   > maybe tending bar would be more profitable.   
      
   Well, to ask this question again, have you tried anything *but* C++,   
   then?   
      
   >> *) Why is using external tools on C++ not a good solution?   
   >   
   > First, because it requires two parties to agree on a tool.   
      
   Why do you need to agree on such a tool? You would need to agree on an   
   interface, indeed, but whether this interface is hand-written, or   
   machine-written should not matter for your customers.   
      
   > You seem seem to start with the assumptions that the programmer   
   > begins with a clean slate and controls all technical choices.  Drop   
   > those assumptions, and imposing an external tool becomes infeasible.   
      
   It becomes very well feasible. I still don't get the problem. Create   
   the structures you need to handle in your database in some external   
   language, probably cut-down C. Write a small parser, probably in yacc   
   or bison, that from that creates C++ classes plus the necessary code   
   to map them to the database layer. You don't need to agree with anyone   
   how these tools work because they are not part of the interface. They   
   just create the code that implements the interface.   
      
   > My personal hobbyhorse is database client libraries: They are harder   
   > to use than would otherwise need be because the programmer is forced   
   > to define operator<< (or similar) for every data structure   
   > representing a row in the database he wants to use.   
   > That work is boring, error-prone, and pointless.  It would not be   
   > improved in any way by introducing CORBA into the mix.   
      
   Well, probably not, but CORBA is a solution to a different problem. It   
   is not a database problem it solves (though I personally wouldn't want   
   to use CORBA for anything these days, because it is a dead technology,   
   but that's a different matter). Anyhow, but why do you create these   
   classes then by hand in first place?   
      
   > The absence of metadata in the compiled output forces the programmer   
   > to restate the contents of any user-defined structure when the data   
   > pass through a process boundary.  To say that work would be   
   > unnecessary if the compiler included the requisite metadata isn't   
   > just obvious; it's tautological.   
      
   It becomes less tautological if you start to realize that the compiler   
   is only one tool in a larger toolchain, and that you problably need to   
   re-think your toolchain, and use another tool and another language to   
   include the metadata you need, and from that derive the input the   
   compiler needs. C++ is not the end of all problems. It is one tool out   
   of many to solve a problem.   
      
   Greetings,   
   	Thomas   
      
      
      
      
   --   
         [ 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)