220 5545 article Path: news.gmane.org!not-for-mail From: Fernando Cacciola 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 16:11:16 -0300 Lines: 115 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=047d7b3434c2e3516804e246ae76 X-Trace: ger.gmane.org 1374693115 11842 80.91.229.3 (24 Jul 2013 19:11:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2013 19:11:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCOPV7FAXQPRB7GNYCHQKGQE3RGFGOI@isocpp.org Wed Jul 24 21:11:58 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f198.google.com ([209.85.215.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V24Te-00050E-4d for gclcip-std-proposals@m.gmane.org; Wed, 24 Jul 2013 21:11:58 +0200 Original-Received: by mail-ea0-f198.google.com with SMTP id z15sf560582ead.1 for ; Wed, 24 Jul 2013 12:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=2Ao6thnWKnjiRwBoNjZ7SejMs7OZ13rzjVi/NSPAJ5Q=; b=xNM8KsHMwpsPBVTTfVVDbSX6sVnZhYdk33iVOmCHzMDa6zo1dYE6Uu76bcnZKj+tkv nZHZmE9VUBXJhLPuNUNgewMNWkQTFJz2xIRsGaz2ZP61myDodhT9O5gEWwKj+bESUL0O zDwApRRLbfRqFd/w3LhUQFVKJ2lMqM70CILaqdzqbAuMB61C4qNeUBJw58zB+0bq5T6G AYj23JterH4iNCSiUx9aOz+BccXgbtohPZ7CjAByYu48GaPpFU06O3k1O9dWlGGqfxab 45VWnCoISCD55B1w8BpOvmyytG6A8qbX3ppBIqxifXnB61e1oJ93RyikV6qhfMsbtF4n zZkw== X-Received: by 10.112.57.74 with SMTP id g10mr8640479lbq.16.1374693117338; Wed, 24 Jul 2013 12:11:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.88.75 with SMTP id be11ls24833lab.1.gmail; Wed, 24 Jul 2013 12:11:56 -0700 (PDT) X-Received: by 10.152.4.194 with SMTP id m2mr17565230lam.23.1374693116741; Wed, 24 Jul 2013 12:11:56 -0700 (PDT) Original-Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [2a00:1450:4010:c03::236]) by mx.google.com with ESMTPS id j10si16276886laj.158.2013.07.24.12.11.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 12:11:56 -0700 (PDT) Received-SPF: pass (google.com: domain of fernando.cacciola@gmail.com designates 2a00:1450:4010:c03::236 as permitted sender) client-ip=2a00:1450:4010:c03::236; Original-Received: by mail-la0-f54.google.com with SMTP id ec20so640868lab.13 for ; Wed, 24 Jul 2013 12:11:56 -0700 (PDT) X-Received: by 10.112.150.231 with SMTP id ul7mr17363576lbb.92.1374693116562; Wed, 24 Jul 2013 12:11:56 -0700 (PDT) Original-Received: by 10.114.186.41 with HTTP; Wed, 24 Jul 2013 12:11:16 -0700 (PDT) In-Reply-To: X-Original-Sender: fernando.cacciola@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fernando.cacciola@gmail.com designates 2a00:1450:4010:c03::236 as permitted sender) smtp.mail=fernando.cacciola@gmail.com; dkim=pass header.i=@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:5545 Archived-At: --047d7b3434c2e3516804e246ae76 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 24, 2013 at 3:43 PM, Fernando Cacciola < fernando.cacciola@gmail.com> wrote: > > > I wonder if the collective effort here in reviewing and formalizing > library proposals wouldn't be more efective if the result where a library > implementation instead of an ISO formalization. > OK, responding to myself, I see some problems with that idea already: (1) Vendor library implementations have the luxury of knowing what their compiler does. This is huge. In Boost, catching up with C++11 is difficult because it is quite complicated to write code using features that not all compilers support; the code needs lots of ugly macro hacks all over, it is difficult to create and difficult to mantain. (2) We currently specify a library against a core specification for which there might not be any compiler yet. If we where to implement libraries instead, they would have to settle for the core features already available. (3) Vendors would not be able to provide their own implementations since there would be an exisiting library but not a formal specification to follow like there is now (they actually could, with certain effort, by studing the existing implementation, but they wouldn't I suppose) Well, so that doesn't seem like the solution. Still, I'd like to keep searching for one because I still believe that we have a problem (even though things are significantly more streamlined now that ever before) Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com -- --- 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/. --047d7b3434c2e3516804e246ae76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 24, 2013 at 3:43 PM, Fernando Cacciola <fernando.cacciol= a@gmail.com> wrote:


I wonder if the collective effort here in reviewing and form= alizing library proposals wouldn't be more efective if the result where= a library implementation instead of an ISO formalization.

OK, responding to myself, I see some prob= lems with that idea already:

(1) Vendor library implementations have the luxury of k= nowing what their compiler does. This is huge. In Boost, catching up with C= ++11 is difficult because it is quite complicated to write code using featu= res that not all compilers support;=A0 the code needs lots of ugly macro ha= cks all over,=A0 it is difficult to create and difficult to mantain.

(2) We currently specify a library aga= inst a core specification for which there might not be any compiler yet. If= we where to implement libraries instead, they would have to settle for the= core features already available.

(3) Vendors would not be able to provi= de their own implementations since there would be an exisiting library but = not a formal specification to follow like there is now (they actually could= , with certain effort, by studing the existing implementation, but they wou= ldn't I suppose)

Well,= so that doesn't seem like the solution. Still, I'd like to keep se= arching for one because I still believe that we have a problem (even though= things are significantly more streamlined now that ever before)

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--
 
---
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>.
 
 
--047d7b3434c2e3516804e246ae76-- .