From -6556172218255157620 X-Google-Thread: f78e5,6294651cbc4b105c X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!proxad.net!newsfeed.stueberl.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: marc@klaralvdalens-datakonsult.se (Marc Mutz) Newsgroups: comp.std.c++ Subject: Re: C++ standard life cycle Date: Sat, 27 Aug 2005 05:52:52 GMT Organization: T-Online Lines: 126 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: 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 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1125121984 28013 158.152.254.254 (27 Aug 2005 05:53:04 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 27 Aug 2005 05:53:04 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: KNode/0.8.2 X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id j7R5r1ub016414 X-ID: ZBD8K4Z6Zekb-qXbzBzdx7c0TF1BB3zgNcynY7V9t+ZufOP1EDUMZQ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j7R5qq9i016389; Sat, 27 Aug 2005 15:52:52 +1000 (EST) X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1944 Thorsten Ottosen wrote: >> The Linux community is staying with C.=A0=A0(That, >> incidentally, needs to be thoroughly studied by those >> working on the C++ standard.=A0=A0It's=A0worth=A0understanding >> why=A0a=A0sizable=A0community has looked at and firmly >> rejected C++.)=A0=A0Application-level >=20 > 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. 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]. My personal feeling (which might be completely off) is that this complexity is for threefold reasons, two of which involve the language's class library, and the last one the core language efford. First, all levels of 'core' C++ libraries (boost, tr1, the 'old' standard library and to a lesser extend the C library) present themselves as a conglomerate of independantly designed components that are thrown into a pot without stirring. It seems to me that large, extensive, 'single-source' class libraries like .net, the Java class library, and - if I may add this - Qt provide _a lot_ more uniform APIs and also have the ability to dump dead ends over board, something that C++ refuses or is unable to do. API consistency is very important for the ease-of-use of a language, and C++ fares very badly in this regard. 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++. Third, the reluctance to change the core langauge. 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. 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++. In the same vein, as the communitiy learns what C++ is all about, it might be a good idea to revise the standard to accomodate what we have learned. After all, all software rots and needs to be kept up-to-date with the growing knowledge about the problem domain and implementation techniques, and why 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 =3D ...; std::vector r =3D ...; std::transform( v, r, std::bind( plus(), _1, 42 ) ); 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. Make void foo() throw() { throw 5; } ill-formed: error: function 'foo()' is not allowed to throw 'int'. Or language support for lamba functors: std::for_each( v, x->{ x +=3D 42; } ); //whatever syntax std::transform( v1, v2, (x,y)->{ x+y; } ); It's amazing that you can add lambda functions without explicit language support and I consider the authors or such libraries ingenious scientists that further the understanding of a language that is showing a most curious manifestation of emergent behaviour (TMP). But apart from very simple cases, the syntax is not exactly readable. Or maybe the need for a lambda library just shows that C++ badly lacks a foreach keyword. Let me stress that I'm awestruck at the power of modern C++ template libraries like Spirit or Boost.Lambda and that I fully understand that to shoulder large redesigns of the standard library, the committee simply lacks the man power, but we must ask why the industry lets this happen. Maybe the turn-around times for the ISO process is too long for companies to submit their stuff and get involved. Just my 2 cents. Sorry for the long post. You probably know all of the above already. Marc [1] Personally, I think that younger languages like Python, C# or Java will also become more complex as they add features C++ has had for the last decade already. These features are needed to write robust code and I'm looking forward to see new lean language effords like python was when it was invented pop up with a functionality set to rival C++ and but with a leaner, more consistent, less-dark-corner design. --- [ 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 ]