220 7475 article Path: news.gmane.org!not-for-mail From: Daryle Walker Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A proposal to add `make_array` Date: Thu, 24 Oct 2013 22:20:11 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_375_16489800.1382678411145" X-Trace: ger.gmane.org 1382678411 6130 80.91.229.3 (25 Oct 2013 05:20:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Oct 2013 05:20:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS6X4FNQMPBBC77U6JQKGQEFJWEKQQ@isocpp.org Fri Oct 25 07:20:13 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VZZoj-00059L-7m for gclcip-std-proposals@m.gmane.org; Fri, 25 Oct 2013 07:20:13 +0200 Original-Received: by mail-ie0-f198.google.com with SMTP id tp5sf9733238ieb.1 for ; Thu, 24 Oct 2013 22:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=f59kR+eFyiIviKhuN1nVaWNlBAjcjDbHAXhI8JwIdYY=; b=iSI0q9riq9rKCQTv9njr9t18JvI962DHzej/Rip9WU6qa8zoGliIOsjKMPz1fnmgIw kDsCxnBD51t3qhmrQSEawdIcBe9dioHX+NPBA711CvVunmEK3MrByux0upBU9nDRyUeZ T7tZOuEbTxNbp6IreWrXaRKlb5fuLje7JAQCv//5xZ6cZVI1uon3H5XeHcc+OVEF+uet uDDAIy5QplsgU6ucVrOlyNjGEnCUX8wY7a9xBEpns6XeNYoqFBoHzFfRMor2tXWBDET9 Gi1mq26VHJ/2itZRPAx87DsRke/3ZqX28Jn7QhdSTVtNDUBNeHh/2UyBDXVPC5UPSqqX DrUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=f59kR+eFyiIviKhuN1nVaWNlBAjcjDbHAXhI8JwIdYY=; b=j8sB5sC7SrjGXKkYLBb60wNefvohGt0htytYzzwF7G9nrsEhScLj7aE2jQrXlIZELp 9ObWAabtIPgJ3o6lwmdSnmL+Y+VGVFS3bEvX5+7A4ed2xDJvwBPRNalyOsenZKHmHG8z eQtImXhtZaK2ZvgZAN6GkfbRugcYb+BhEaCtf5xC4S9sYZWs2Hdtbi8guUwAhXgE3s4s +OoFTnjNNq9/xsKiziQr9X2VI9fj2C6yBYF+km6D8Q1FINa4/NC0iYSHo4hJ/8KIxA3B j5Emeulzjsf86Bwt8LXV5TRULncTlhU2f1eiTtcf9J+AO5bxubBgMhBa3n8pfb4lcoLO Ka5Q== X-Gm-Message-State: ALoCoQmnZSDffrVjBVioPUoTc5udKoj3LP3SbHCGn64tg9WGEYMi77OA3MsjY/5v66J69zt7cq0k X-Received: by 10.182.126.137 with SMTP id my9mr836405obb.13.1382678412255; Thu, 24 Oct 2013 22:20:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.35.194 with SMTP id k2ls1081685qej.45.gmail; Thu, 24 Oct 2013 22:20:11 -0700 (PDT) X-Received: by 10.49.13.40 with SMTP id e8mr181995qec.1.1382678411470; Thu, 24 Oct 2013 22:20:11 -0700 (PDT) In-Reply-To: X-Original-Sender: darylew@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:7475 Archived-At: ------=_Part_375_16489800.1382678411145 Content-Type: text/plain; charset=ISO-8859-1 On Monday, October 21, 2013 9:04:29 PM UTC-4, Zhihao Yuan wrote: > The idea of a utility to simplify std::array creation has been > around for a long time, now I wrote a formal paper to > address that: > > http://students.cs.niu.edu/~z1565938/make_array.html > > I read about this idea too. That's why I added it to N3794. > Roughly, I included two signatures to support three uses: > > make_array(a, b, c, ...) // an std::array of common_type > make_array(a, b, c, ...) // an std::array of T > > to_array("raw array") // create an std::array from a raw array > > Hope I can get some reviews. Thanks :) > I originally had just a "make_array" like yours. But there were complaints about leaving the choice of element type to std::common_type, and wanting a manual override. Then I remembered that make_shared (and the new make_unique) require the user to specify the return type via explicit template arguments to the creation function. That's why I changed the signature for make_array, and made a new function make_auto_array with the automatically-chosen element type semantics. (You just reminded me that make_tuple and make_pairdon't need explicit template arguments, but they allow the element types to not match each other.) You made your version of "make_auto_array" an overload(?) of the regular make_array. How can they co-exist without ambiguities? Especially if the first function argument's type matches that of your explicitly given element type? > PS: I noticed that the first signature conflicts with the one > included in N3794, but I kept mine because I think the idea > of creating a multidimensional array through a one > dimensional syntax is flawed. > My versions of the creation functions don't require multidimensionality; they can be made to work with a single-dimension-only std::array. I added them late in the process. I was already adding major changes to that section of the Standard, so why not add a common request. AFAIK, function-call syntax is linear, so what would alternatives for creating multidimensional arrays via functions be (besides giving up and use aggregate initialization only)? Nested calls to make_array, as mentioned in your paper? (I couldn't do that in my paper, since my proposed array directly uses a C-level multidimensional array, and not nested instantiations of array. Recall that built-in multidimensional arrays can be "sloppily" initialized linearly.) Daryle W. -- --- 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_375_16489800.1382678411145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Monday, October 21, 2013 9:04:29 PM UTC-4, Zhihao Yuan = wrote:
The idea of a utilit= y to simplify std::array creation has been
around for a long time, now I wrote a formal paper to
address that:

  http://students.cs.niu.edu/~z1565938/make_array.htm= l  

I read about this ide= a too. That's why I added it to N3794.
 
Roughly, I included two signatures to su= pport three uses:

  make_array(a, b, c, ...)  // an std::array of common_type
  make_array<T>(a, b, c, ...)  // an std::array of T

  to_array("raw array")  // create an std::array from a raw a= rray

Hope I can get some reviews.  Thanks :)

I originally had just a "make_array" like yours. But there were comp= laints about leaving the choice of element type to std::common_type, and wanting a manual override. Then = I remembered that make_shared = (and the new make_unique) requ= ire the user to specify the return type via explicit template arguments to = the creation function. That's why I changed the signature for make_array, and made a new function make_auto_array with the automaticall= y-chosen element type semantics. (You just reminded me that make_tuple and make_pair don't need explicit template arguments, but they a= llow the element types to not match each other.)

Y= ou made your version of "make_auto_array" an overload(?) of the regular make_array. How can they co-exist= without ambiguities? Especially if the first function argument's type matc= hes that of your explicitly given element type?
 
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">PS: I noticed that the first si= gnature conflicts with the one
included in N3794, but I kept mine because I think the idea
of creating a multidimensional array through a one
dimensional syntax is flawed.

My versions of the creation functions = don't require multidimensionality; they can be made to work with a single-d= imension-only std::array. I ad= ded them late in the process. I was already adding major changes to that se= ction of the Standard, so why not add a common request.

AFAIK, function-call syntax is linear, so what would alternatives for= creating multidimensional arrays via functions be (besides giving up and u= se aggregate initialization only)? Nested calls to make_array, as mentioned in your paper? (I couldn't do= that in my paper, since my proposed array directly uses a C-level multidimensional array, and not n= ested instantiations of array.= Recall that built-in multidimensional arrays can be "sloppily" initialized= linearly.)

Daryle W.

--
 
---
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_375_16489800.1382678411145-- .