From -7577910637552103176 X-Google-Thread: f78e5,6294651cbc4b105c X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: nesotto@cs.aau.dk ("Thorsten Ottosen") Newsgroups: comp.std.c++ Subject: Re: C++ standard life cycle Date: Sat, 27 Aug 2005 17:56:31 GMT Organization: SunSITE.dk - Supporting Open source Lines: 165 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <43103c30$0$18645$14726298@news.sunsite.dk> References: <1125063434.798372.40210@z14g2000cwz.googlegroups.com> <9gHPe.799$5k1.691@newssvr27.news.prodigy.net> <430f74ae$0$18647$14726298@news.sunsite.dk> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1125165405 18899 158.152.254.254 (27 Aug 2005 17:56:45 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 27 Aug 2005 17:56:45 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Priority: 3 X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Sat, 27 August 2005 03:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MSMail-Priority: Normal X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j7RHuV7i001669; Sun, 28 Aug 2005 03:56:31 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 1.2/5.0 3.0.4) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2800.1506 X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 39886 j7RAB0cW045363 mailbox8.ucsd.edu) Xref: g2news1.google.com comp.std.c++:1947 "Marc Mutz" wrote in message news:deobtp$fl9$00$1@news.t-online.com... Thorsten Ottosen wrote: >> The Linux community is staying with C. (That, >> incidentally, needs to be thoroughly studied by those >> working on the C++ standard. It's worth understanding >> why a sizable community has looked at and firmly >> rejected C++.) Application-level > > How can one reject something one does not understand > nor care to understand? Thorsten, as a member of said community that happens to be in one of the few camps (KDE) that uses almost only C++ as it's programming language I feel strongly insulted by your comment. >>>>>>>>>>> You shouldn't. Obviously you don't fall into that camp I'm talking about. I've meat some really important FreeBSD guys...really smart people working on OS cores. But they don't understand the power of C++ and how it might help them. One of them said, he had given up on C++ a long time ago. He's relunctant to change, even if it could help him enourmously. John, I agree with you that the C++ community should think about why the majority of Free Software developers refuse to use C++. Complexity is the prime argument I hear[1]. >>>>>>>>>> right, an that is often because they don't know how modern C++ works. pot without stirring. It seems to me that large, extensive, 'single-source' class libraries like .net, the Java class library, and >>>>>>>>>> The quality of the .Net class linbraries is not exactly great. For example, I've never seen a weak container library before. The remoting API is way to complex compare to what it should be Second, the C++ standardized (even when including boost here) libraries are way too low-level. We don't even have a standardized xml parser library, although both SAX and DOM could be trivially adapted and standardized almost as-is. We don't have classes for common network protocols, or even socket programming in general. And I won't even start thinking about GUIs. I know this is mostly due to the way the standardisation process works. No-one gets paid for working on the standard, and I guess that's the major drawback of C++. >>>>>>>>>>>>>>> right. we can't standardize everything. but C++ needs a more of these libraries...and I'm pretty sure that they will appear in boost within two years. Third, the reluctance to change the core langauge. >>>>>>>>>>>>>>> what reluctance? Sure, C++ compilers are complex beasts, and further complexification of the core language might reduce the number available high-quality C++ compilers, but other langauges demonstrate that langauge support for e.g. properties, delegates/signals-slots/callbacks (whatever you want to call them) are welcome in the developer community. >>>>>>>>>>>>>>>> properties are not really useful, except maybe for embedded domain specific languages. signals/slots will be added as a library, there is no need to make a core change for that. Considering that the C++ community itself only came to terms in the last few years with the 'monster' it created back in the nineties (TMP, exception-safety guidelines, export), it shouldn't be of any wonder if people not on the C++ research bleeding egde have trouble groking all the little details of C++. >>>>>>> right, they shoul have to. And C++0x will be much easier to use. count on it. should the standard class library be any different. The STL written in the boost era would look vastly different. But due to backwards compatibility and lack-of-manpower, local fixes (bind, function) need to ba added instead of a putting up a coordinated efford to design an STLv2 that looked like this: std::vector v = ...; std::vector r = ...; std::transform( v, r, std::bind( plus(), _1, 42 ) ); >>>>>>>>>>>>> I have a proposal about this for C++0x in the next mailing. (available in a week) Another example: Everyone seems to agree that exception specifications are a failure. Why not re-create them to do what most people new to C++ expect them to do: To make the compiler enforce the specifications at compile time. >>>>>>>>>>>>> Alisdair M. is working in this area. I think what everybody don't expect is that it can terminate the program. whether we need to detect it a compile time is another issue. I don't think exception-specs are that useful, though. readable. Or maybe the need for a lambda library just shows that C++ badly lacks a foreach keyword. >>>>>>>>>>>>>>>> Also described in one of my new papers. You may find the old version here (it contains a few errors, though) http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html happen. Maybe the turn-around times for the ISO process is too long for companies to submit their stuff and get involved. >>>>>>>>>>>> hear, hear. Anyway, be sure that C+0x is going to be much easier to use and and much more pleasant ride for everyone. best regards Thorsten --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]