220 7479 article Path: news.gmane.org!not-for-mail From: Daryle Walker Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A proposal to add `make_array` Date: Fri, 25 Oct 2013 13:56:57 -0700 (PDT) Lines: 140 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_1061_559889.1382734617996" X-Trace: ger.gmane.org 1382734616 30605 80.91.229.3 (25 Oct 2013 20:56:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Oct 2013 20:56:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS6X4FNQMPBBGVWVOJQKGQE7OEL5ZI@isocpp.org Fri Oct 25 22:57:01 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VZoRI-00086M-BW for gclcip-std-proposals@m.gmane.org; Fri, 25 Oct 2013 22:57:00 +0200 Original-Received: by mail-ob0-f200.google.com with SMTP id uy5sf4852351obc.11 for ; Fri, 25 Oct 2013 13:56:59 -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=UzqXGEatr3zEz1Cye1lU4/wx/fi8HPUsGmmu+LdzD30=; b=a5yAD7ZOlFwH1JAiD65PVUTYcAstxs0dwE6KNGqyf5q7MxRnJhvDdrdKooB91XkNhW pM6EE6P9oFihpeAlYY4egoHbdhZ7WRJB81nK/Ujc8sFCvIzKaqDPVHjt+0OkTcbsdlpJ u5bsguC/ZgNaGMD+eqD1HZxFs23tt9oDXDG4wNwDlkHr5ts0hWVsEn8hFujEVupDh/+Q ErAe64mLYicowe3vrBANRz76O05TFbkPYoMtLYe5mqIs8UTIVjYJhxlhoH/mcMxsO9WA L5x7ZYq1NVH5o1uISoDW61W3wFzaHcse/1wu+NcF4A57/5Zvpcipw1oa/R7lXgJQPcTC 0kNw== 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=UzqXGEatr3zEz1Cye1lU4/wx/fi8HPUsGmmu+LdzD30=; b=EQxxNAs49GyubL592mGzT/+P7RiyqxXS8ayNyViyA+cN5CGP5GAbL9pPblRjKHJx3C xrfCzO35HdDCpxcljYAat3ksFE8ogFOSL8F4bPwAqkT2WAaZHVvCM3FXRQQj5S6KXyKr q6rkz2OofZBRwyBTnDVKu/Vw2QsBadecQ20AX1N+ftuqYN+/K5C1RxjZDRyK0rzTeQIo ku0eRKBW03dL4OzvspJzuhsFsjrJLsJSJlNNtT8oYxk4ruCcDF1VsbN058BTp0Q/W2YG ipaD9n8EhpiN+L+s3H/4k91AQLMbd/Go9G7x7/ZE0H8ADdGUfNkE7TZ1UWbZOsWDFO8U T1Yw== X-Gm-Message-State: ALoCoQndO5YRKxF/B5REGFLLh3bsUh/Id/Up2nlSEeLsg1foPMQq3ySDLJuyZj2cCtCTa8eKus7P X-Received: by 10.50.61.242 with SMTP id t18mr122222igr.3.1382734619275; Fri, 25 Oct 2013 13:56:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.241.168 with SMTP id wj8ls897766obc.57.gmail; Fri, 25 Oct 2013 13:56:58 -0700 (PDT) X-Received: by 10.182.113.194 with SMTP id ja2mr30433obb.31.1382734618673; Fri, 25 Oct 2013 13:56:58 -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:7479 Archived-At: ------=_Part_1061_559889.1382734617996 Content-Type: text/plain; charset=ISO-8859-1 On Friday, October 25, 2013 2:04:36 AM UTC-4, Zhihao Yuan wrote: > On Fri, Oct 25, 2013 at 1:20 AM, Daryle Walker > > wrote: > > 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? > > Because they are overloaded on template parameters, > not function parameters, so they are disambiguated during > substitution. (unless user supplies deduced template > parameters, which is just a wrong use) > AFAIK, you can explicitly fill in any template parameter for current Standard function templates. Your function templates would be the first ones where explicit filling will break stuff. Maybe we should use distinct function names like I did. > > 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.) > > If C++ supports C99 array literals then my `to_array` can > be extended to do this, but, you know :) > > Anyway, a solution I can think of is to use a special deduction > rule, like to deduce `reference_wrapper` to `T&`, deduce > a proxy type to initialize a C array. > > But TBH, I worry about the internal C array solution itself. One > of the major benefit of std::array is that it does not decay into > a pointer, while your design, iiuc, will decay from the second > level. > I'm not sure what you're talking about by "my design"? If you mean my off-the-cuff suggestion, then that "make_array" returns std::array objects, so no decay. If you mean N3794, then that "make_array" takes a linear list of T objects, so no decay (unless T itself is an array type, but you're already screwed in that case since built-in arrays are not Assignable). 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_1061_559889.1382734617996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Friday, October 25, 2013 2:04:36 AM UTC-4, Zhihao Yuan = wrote:
On Fri, Oct 25, 2013= at 1:20 AM, Daryle Walker <dar...@gmail.com> wrote:
> You made your version of "make_auto_array" an overload(?) of the r= egular
> make_array. How can they co-exist without ambiguities? Especially = if the
> first function argument's type matches that of your explicitly giv= en element
> type?

Because they are overloaded on template parameters,
not function parameters, so they are disambiguated during
substitution.  (unless user supplies deduced template
parameters, which is just a wrong use)

AFAIK, you can explicitly fill in any = template parameter for current Standard function templates. Your function t= emplates would be the first ones where explicit filling will break stuff. M= aybe we should use distinct function names like I did.
 
=
> AFAIK, function-cal= l 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 men= tioned in
> your paper? (I couldn't do that in my paper, since my proposed arr= ay
> directly uses a C-level multidimensional array, and not nested
> instantiations of array. Recall that built-in multidimensional arr= ays can be
> "sloppily" initialized linearly.)

If C++ supports C99 array literals then my `to_array` can
be extended to do this, but, you know :)

Anyway, a solution I can think of is to use a special deduction
rule, like to deduce `reference_wrapper<T>` to `T&`, deduce
a proxy type to initialize a C array.

But TBH, I worry about the internal C array solution itself.  One
of the major benefit of std::array is that it does not decay into
a pointer, while your design, iiuc, will decay from the second
level.

I'm not sure what you're talking about= by "my design"? If you mean my off-the-cuff suggestion, then that "make_ar= ray" returns std::array objects, so no decay. If you mean N3794, then that = "make_array" takes a linear list of T objects, so no decay (unless T itself= is an array type, but you're already screwed in that case since built-in a= rrays are not Assignable).

Daryle W.
&nb= sp;

--
 
---
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_1061_559889.1382734617996-- .