220 5543 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A library to provide a virtual memory vector of strings Date: Wed, 24 Jul 2013 11:00:42 -0700 (PDT) Lines: 157 Approved: news@gmane.org Message-ID: References: <861959e9-74f3-4ed8-aeca-bad9c3256acd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1629_8720705.1374688842450" X-Trace: ger.gmane.org 1374688845 28542 80.91.229.3 (24 Jul 2013 18:00:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2013 18:00:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTFMYCHQKGQELG2EWGA@isocpp.org Wed Jul 24 20:00:47 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V23Mk-00082w-Dh for gclcip-std-proposals@m.gmane.org; Wed, 24 Jul 2013 20:00:46 +0200 Original-Received: by mail-oa0-f72.google.com with SMTP id l10sf3707777oag.11 for ; Wed, 24 Jul 2013 11:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=76robP+a/PQXvMAQp8/mUO6s4Axfl6W7TNw/hjyDq/4=; b=WD7WXHYTJfepvj2dOWtAeMmchJg/Az0PJNSoAcTmtYhCoRZ6GmPttHWEdpNVBu8EA0 nCCMX3XWjoTmVLmihM/mausI5i9DOrjmvyR810fpBaPNUx2fOkTLFrlWPCBGs72lpsJ1 chY+K6hh8vOD5l8TwDYRtXNxVAUn/Is4/DA5ZoPGU+xcrSL5qVWCl87Me7PUrdzep0v0 MgCyhN4ZX8N65a+jcU++0bMQAnB2JbF6rILNgxzpd5KgPL+PBqmA5Pla3EPvQItWgCQu IXMoXngoygpAvksk32kzrP3WnbH466cxo543rmAbGt94Y+0oDPJd8v+kphXLWZ0dUdhq DGgA== X-Received: by 10.42.175.69 with SMTP id az5mr25337761icb.2.1374688844963; Wed, 24 Jul 2013 11:00:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.120.9 with SMTP id ky9ls2678161igb.5.canary; Wed, 24 Jul 2013 11:00:43 -0700 (PDT) X-Received: by 10.50.11.69 with SMTP id o5mr396505igb.13.1374688843772; Wed, 24 Jul 2013 11:00:43 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5543 Archived-At: ------=_Part_1629_8720705.1374688842450 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, July 24, 2013 10:11:07 AM UTC-7, Fernando Cacciola wrote: > > On Wed, Jul 24, 2013 at 7:01 AM, Jonathan Wakely > > wrote: > >> >> From a (very quick) glance at your PDF it seems the interesting part and >> the novelty is in the implementation, but the C++ standard is not an >> implementation, it's a specification of visible behaviour, not internal >> details. >> > > I got the exat same impression while scanning over the PDF (it's way too > large to read top to bottom) but then I started thinking if we are doing > the right thing by only standarizing specifications as opposed to somehow > "officially" adopting actual libraries. This is just me thinking out loud > but, I think most other languages don't work that way. Users of them have > "the language on the one hand" but also an "official distribution" which > contains a selection of field-proven libraries. Or at the very least they > routinely use this or that "de-facto standard", so to speak, library. > Well, the reason why other languages do that is because other languages typically only have *one* implementation. Or at the very least, there is a central body who maintains the "official" implementation of the language. Java is officially maintained by Oracle, C# by Microsoft, Python by the Python Software Foundation, etc. They all have unofficial implementations, and some of those are quite good. But there is clearly a single "real" implementation, with the rest all playing catchup. C++ has 3 major implementations, none of whom share much code with the other, and several "smaller" implementations running around. Telling them all "use this exact code" is probably not a good idea. And how would you specify that behavior? We have boost, but that doesn't quite cute it. I wonder if it isn't > somewhat inefficient to standarize, say, a boost library, given the > incredible effort it takes and with the only outcome of more prople using > it just because "it comes with the compiler". Wouldn't it be better to just > find a process by which any C++ user is given "direct access" to, for > example, the boost libraries, as if they where part of C++ itself, but > outside ISO? Do end users care about the C++ standard and its specification > of libraries? I'd say that not at all, they just care about direct > availability of it (i.e. I just grab this compiler and certains libs are > right there to use) > Or compiler developers could, on their own, ship Boost and whatever other libraries they want. Here's the problem with that; just look at Boost. It's 2013; how long did it take many Boost libraries to get support for C++11 features? When did move support come to Boost.Any, Boost.Variant, Boost.Optional, and so on? Do any of them provide constexpr stuff where appropriate? How long will it be until Boost.Variant uses variadic templates? How much would Boost.Fusion or Boost.Phoenix benefit from C++11 features that they simply don't support yet? And when C++14 runs around, how quickly will *they* get support for those features? Standard libraries don't have that problem (theoretically). When we add language features, we make a good faith effort to stick them into the standard libraries too. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1629_8720705.1374688842450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, July 24, 2013 10:11:07 AM UTC-7, Fernando Cacciola wr= ote:
On Wed, Jul 24, 2013 at 7:01 AM, Jonathan Wakely <c...@kayari.org> wrote:

From a (very quick) glance at your = PDF it seems the interesting part and the novelty is in the implementation,= but the C++ standard is not an implementation, it's a specification of vis= ible behaviour, not internal details.
 
I got the exat same impression wh= ile scanning over the PDF (it's way too large to read top to bottom) but th= en I started thinking if we are doing the right thing by only standarizing = specifications as opposed to somehow "officially" adopting actual libraries= .. This is just me thinking out loud but, I think most other languages don't= work that way.  Users of them have "the language on the one hand" but= also an "official distribution" which contains a selection of field-proven= libraries. Or at the very least they routinely use this or that "de-facto = standard", so to speak, library.

Well,= the reason why other languages do that is because other languages typicall= y only have one implementation. Or at the very least, there is a cen= tral body who maintains the "official" implementation of the language. Java= is officially maintained by Oracle, C# by Microsoft, Python by the Python = Software Foundation, etc. They all have unofficial implementations, and som= e of those are quite good. But there is clearly a single "real" implementat= ion, with the rest all playing catchup.

C++ has 3 major implementati= ons, none of whom share much code with the other, and several "smaller" imp= lementations running around. Telling them all "use this exact code" is prob= ably not a good idea. And how would you specify that behavior?

We have boost, but that doesn't quite cute it. I wonder if it isn't somewha= t inefficient to standarize, say, a boost library, given the incredible eff= ort it takes and with the only outcome of more prople using it just because= "it comes with the compiler". Wouldn't it be better to just find a process= by which any C++ user is given "direct access" to, for example, the boost = libraries, as if they where part of C++ itself, but outside ISO? Do end use= rs care about the C++ standard and its specification of libraries? I'd say = that not at all, they just care about direct availability of it (i.e. I jus= t grab this compiler and certains libs are right there to use)

Or compiler developers could, on their own, ship B= oost and whatever other libraries they want.

Here's the problem with= that; just look at Boost. It's 2013; how long did it take many Boost libra= ries to get support for C++11 features? When did move support come to Boost= ..Any, Boost.Variant, Boost.Optional, and so on? Do any of them provide cons= texpr stuff where appropriate? How long will it be until Boost.Variant uses= variadic templates? How much would Boost.Fusion or Boost.Phoenix benefit f= rom C++11 features that they simply don't support yet? And when C++14 runs = around, how quickly will they get support for those features?
Standard libraries don't have that problem (theoretically). When we add la= nguage features, we make a good faith effort to stick them into the standar= d libraries too.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
 
 
------=_Part_1629_8720705.1374688842450-- .