220 3609 <57af1dd6-ec46-4f12-8f87-0d19903e3034@isocpp.org> article Path: news.gmane.org!not-for-mail From: Dominic Burghuber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Reaction to N3538 - Pass by Const Reference or Value (Formally N3445) Date: Sun, 7 Apr 2013 04:30:06 -0700 (PDT) Lines: 107 Approved: news@gmane.org Message-ID: <57af1dd6-ec46-4f12-8f87-0d19903e3034@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3614_16247580.1365334206576" X-Trace: ger.gmane.org 1365334207 27522 80.91.229.3 (7 Apr 2013 11:30:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2013 11:30:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCA7R65NYIORBQNRQWFQKGQE3DUBTRA@isocpp.org Sun Apr 07 13:30:11 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f199.google.com ([209.85.128.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UOnnW-0003rF-2s for gclcip-std-proposals@m.gmane.org; Sun, 07 Apr 2013 13:30:10 +0200 Original-Received: by mail-ve0-f199.google.com with SMTP id jw11sf8313471veb.2 for ; Sun, 07 Apr 2013 04:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id: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=/PwXGXQVwbvsA/NHoUBwysAfCvxbmIDVKEYOoc0A7z4=; b=qXMSXpKUXavUg58CxBhgVsVGqVgQX1pvmbGZ235twn7J+IfsR34vnuEhwJ9JIJrCIg DeEy7yLnvHnkNxqyJN6HsX6bTG4hJ/WLZ4iBLR/7gRFE+I/FuaOZOjwv+jga9jfnU+16 c8i4DxXLEFQHx3gwNqM7B0cqVhq/0z0xeaVeiAUJ5oRAYRb7X9tq1PWC1JE7Ouoh77d0 weuHVk8v7/Yp6J8exBS7gjG4V8mOr6dRQOFOIilLy9vBFHyWLgamOzoJ6Qm8oiOdAFuY X6UF0171PYxH5uXD18z9SNSA7VEFY8tLMqsROltXD4bqwZTby+CNTkkcO/z9qnXxgig6 n6pQ== X-Received: by 10.224.172.200 with SMTP id m8mr3293828qaz.0.1365334209243; Sun, 07 Apr 2013 04:30:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.63.137 with SMTP id g9ls2654903qes.87.gmail; Sun, 07 Apr 2013 04:30:07 -0700 (PDT) X-Received: by 10.49.60.170 with SMTP id i10mr1351224qer.41.1365334207084; Sun, 07 Apr 2013 04:30:07 -0700 (PDT) X-Original-Sender: dmb.youcangetme@googlemail.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:3609 Archived-At: ------=_Part_3614_16247580.1365334206576 Content-Type: text/plain; charset=ISO-8859-1 At moment, if performance is a concern of yours then aliasing should be too. Where pointer aliasing would be an issue, for a portable solution (i.e. non-compiler specific) you have to do a lot of small value passing, local variable usage (i.e. temps), & even class member copying, &/or manual common subexpression elimination. Also generally minimising the use of references & pointers (i.e. you are on a strict subset of C++). It's a disappointment that there is no clean portable way (like C's restrict keyword) to assist the compiler to generate optimal code. Instead work arounds such as those listed lead to more fuzzy code, greater instruction cache load, & lot more mental overload than if there were a default go-to solution like having a "restrict" keyword. The in parameter proposal is another decent solution, but will likely face difficulty in being adopted due to the significant change it proposes. With the restrict keyword as part of C, & implemented by some compilers already (though for some, implementation covers specific forms only - it appears that LLVM, for example, ignores restrict everywhere except function parameters) it does seem the most likely way forward for acceptance. C++ programmers got override & final keywords as opposed to attributes (a good thing IMHO). I'm really hoping we can get "restrict" in the next language enhancement. What critical arguments have there been against "restrict"? What has the general/initial reaction to N3538 (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html) been like? Also, once upon a time was there not a restricted pointer/reference proposal? I guess, without having reviewed it, this would now be a type of pointer/reference not to allow reseating and to somehow block the memory location from aliasing (like a cross between a unique pointer & a reference-counted pointer, in that it can be moved around (not copied), and a reference of only 1 is allowed on the memory location)? An idea, but still a restrict keyword applicable to both pointers & references is likely a better solution. -- --- 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/?hl=en. ------=_Part_3614_16247580.1365334206576 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

At moment, if performance is a concern of yours then aliasing shoul= d be too. Where pointer aliasing would be an issue, for a portable solution= (i.e. non-compiler specific) you have to do a lot of small value passing, = local variable usage (i.e. temps), & even class member copying, &/o= r manual common subexpression elimination. Also generally minimising the us= e of references & pointers (i.e. you are on a strict subset of C++).
It's a disappointment that there is no clean portable way (like C's re= strict keyword) to assist the compiler to generate optimal code. Instead wo= rk arounds such as those listed lead to more fuzzy code, greater instructio= n cache load, & lot more mental overload than if there were a default g= o-to solution like having a "restrict" keyword.

The in parameter pr= oposal is another decent solution, but will likely face difficulty in being= adopted due to the significant change it proposes.  With the restrict= keyword as part of C, & implemented by some compilers already (though = for some, implementation covers specific forms only - it appears that LLVM,= for example, ignores restrict everywhere except function parameters) it do= es seem the most likely way forward for acceptance. C++ programmers got ove= rride & final keywords as opposed to=20 attributes (a good thing IMHO). I'm really hoping we can get "restrict"=20 in the next language enhancement. 

What critical arguments hav= e there been against "restrict"?

What has the general/initial react= ion to N3538=20 (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html) been l= ike?

Also, once upon a time was there not a restricted pointer/refer= ence proposal? I guess, without having reviewed it, this would now be a typ= e of pointer/reference not to allow reseating and to somehow block the memo= ry location from aliasing (like a cross between a unique pointer & a re= ference-counted pointer, in that it can be moved around (not copied), and a= reference of only 1 is allowed on the memory location)? An idea, but still= a restrict keyword applicable to both pointers & references is likely = a better solution.

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_3614_16247580.1365334206576-- .