220 34922 article Path: news.gmane.org!.POSTED!not-for-mail From: euloanty@live.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on more methods towards containers in the future Date: Sat, 14 Oct 2017 10:08:37 -0700 (PDT) Lines: 220 Approved: news@gmane.org Message-ID: References: <973f04da-1354-44f4-9d1f-23f04596b8dc@isocpp.org> <20171014085305.GA24512@fukushima.lysator.liu.se> <79c51b8c-6cc2-4872-8651-9dae513d1e21@isocpp.org> <1550fc17-cf97-438d-9e7a-862f729adbf5@isocpp.org> <0cc942cf-a217-4175-98b0-b466ac224dc7@isocpp.org> <7e04a500-ba3a-432a-a844-7d4def1fb739@isocpp.org> <5c1bc3ef-c3a2-4406-8a7a-f82e12155386@isocpp.org> <69a588d5-de2a-4be2-8add-9685d0b9a230@isocpp.org> <405f3ea9-d886-4c3f-9543-a276f8214974@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14550_1672372146.1508000917616" X-Trace: blaine.gmane.org 1508000936 368 195.159.176.226 (14 Oct 2017 17:08:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 17:08:56 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDPYX6PYRQNBBFUJRHHQKGQENVUKGAA@isocpp.org Sat Oct 14 19:08:50 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3PvM-0005cR-0I for gclcip-std-proposals@m.gmane.org; Sat, 14 Oct 2017 19:08:32 +0200 Original-Received: by mail-ua0-f198.google.com with SMTP id 10sf5316078uav.16 for ; Sat, 14 Oct 2017 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=HEcs4+fE5SJOTEOg9kOWQYt+naXvPGNQEBlUPjsFN6M=; b=gSQ0QwpLXhAfiZJJV8GAnzlRkgKfP7Po0b0ksh0QUCNpqCf5LTsJMjJU2V3TP40L// vfcA9QtAWxzpEdThLx4rIBMlabc0mO9bv5NGxn4QCnY/FPM9mj2XRSh+JDKCFE55Dax8 1YodZEeo896zF0NvHdyI5aJkNjhVWey5PuRDoA8MPon5b/d6uTGcpVEfehZ9U2bshmBv WQkeY8HfSMZuHyPTGxGFEVnpQ4MrOmlVXl32cj4iMqDlKtHfcFXf1w5T241nTQBlHOgQ JgKFchkb+aEe/xX1EDCG6FtT53P6MfSGvGfrCZyMkzoERQQpU7+Uvw19lB6HmUchXRCp HlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=HEcs4+fE5SJOTEOg9kOWQYt+naXvPGNQEBlUPjsFN6M=; b=kIsbnQqO6cCI9rh8WYGF97qBpvwKq1uZnECoY6w/k2bUOgN6YKT+Xs8RkLhteSeNQP eCEX+RSvii01walWpzoSqCWaAnGOB4BWtfQcVPbt7q3q0xooO1iPhun3l4xMCA8pvM7g ONzSAs8iQdW+kulbrErxREfHCRhN+iA3yFpilsK1IrObrOmVYH9PB5+iuXcosuStqa5Z zWEXxBRTEkFfYR8hGA1/1or8d7VYpC5KZfebnS2Hv4kavp0L+iFwNAPn47Oapnj4yaH4 +ARdPZlOEwiM/Bz/+zWn/1yicF/kOKdXIBGYM41lIYfFAggHxwK1ufdQ/HTIDYt2b1Q6 b9Vw== X-Gm-Message-State: AMCzsaVh43dwboCjr9KQR9AMcNs9BNv/xEnsuhxzns8r2zsI+ROJD/cI 8UdM7Gs8CdocRx8Dalzy8Pymfw== X-Google-Smtp-Source: AOwi7QD2s5m9NyRHH9Axtelcrp0CZcwmMNSp1wdr8H3aNw6WOqmrUz35SHM++6K5bFD0xUTgpI6x4Q== X-Received: by 10.159.48.74 with SMTP id i10mr2619685uab.55.1508000919306; Sat, 14 Oct 2017 10:08:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.242.130 with SMTP id q124ls2424082vkh.19.gmail; Sat, 14 Oct 2017 10:08:38 -0700 (PDT) X-Received: by 10.31.11.69 with SMTP id 66mr315913vkl.6.1508000918101; Sat, 14 Oct 2017 10:08:38 -0700 (PDT) In-Reply-To: X-Original-Sender: euloanty@live.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:34922 Archived-At: ------=_Part_14550_1672372146.1508000917616 Content-Type: multipart/alternative; boundary="----=_Part_14551_986730312.1508000917617" ------=_Part_14551_986730312.1508000917617 Content-Type: text/plain; charset="UTF-8" For example, I can only get my size N at runtime. On Saturday, October 14, 2017 at 12:44:17 PM UTC-4, Ren Industries wrote: > > Do you happen to know of std::array? > > On Oct 14, 2017 11:40, > wrote: > >> >> >> On Saturday, October 14, 2017 at 11:26:58 AM UTC-4, Nicol Bolas wrote: >>> >>> On Saturday, October 14, 2017 at 11:02:29 AM UTC-4, ejsvifq mabmip wrote: >>>> >>>> The main purpose of C++ containers is to compete with other C style/OOP >>>> style implementation. >>>> >>> >>> ... no, it's not. >>> >>> The main purpose of standard library containers is to be useful to C++ >>> programmers. To provide value to the language by having lingua franca types >>> that users can use where appropriate for common programming issues. >>> >>> >> No. If vector does not have same performance as T* c style array. >> C-style array will just live forever. That is why std::vector is >> implemented as templates, not OOP/ >> >> >>> If you add if check for [], that would encourage people continue to use >>>> c-style-array for better performance. >>>> >>>> You have to do everything to make people not have a reason to write >>>> their own version of container (for doing the same thing). >>>> >>> >>> No, we don't. The goal of the container design was not to make it so >>> that nobody would ever use any other container. It was to make it so that >>> people would only use other containers in exceptional circumstances. >>> >>> There is no one-size-fits-all approach here, and trying to build one >>> will only end in tears. >>> >>> That's not to say that I wouldn't mind having unchecked push-back >>> operations on `vector`. I think it's asinine to say that we don't need one >>> because optimizers will remove it when they can detect that it will always >>> be filled. Optimizers can't see or know everything: >>> >>> int count; >>> file_stream >> count; >>> >>> vector vec; >>> vec.reserve(count); >>> >>> for(auto x : crange(count)) >>> { >>> vec.emplace_back(); >>> file_stream >> vec.back(); >>> } >>> >>> Can an optimizer remove the test in this case? More importantly, if >>> you're looking at this code, is it *reasonable* to expect an optimizer >>> to be able to do so? >>> >>> Pretty hard. >> Also we should not expect optimizer to remove test. They have different >> behaviors. Before C++11, you might even expect optimizer to optimize copy >> for vector. >> >> -- >> 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/405f3ea9-d886-4c3f-9543-a276f8214974%40isocpp.org >> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ceb5fbaa-7e73-4c54-b10e-46712f604836%40isocpp.org. ------=_Part_14551_986730312.1508000917617 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For example, I can only get my size N at runtime.

O= n Saturday, October 14, 2017 at 12:44:17 PM UTC-4, Ren Industries wrote:
Do you happen t= o know of std::array?

On Oct 14, 2= 017 11:40, <eulo...@live.com> wrote:


On Saturday, October 14, 20= 17 at 11:26:58 AM UTC-4, Nicol Bolas wrote:
On Saturday, October 14, 2017 at 11:02:29 AM UTC-4= , ejsvifq mabmip wrote:
The main purpose of C++ containers is to compete with other C sty= le/OOP style implementation.

..= .. no, it's not.

The main purpose of standard l= ibrary containers is to be useful to C++ programmers. To provide value to t= he language by having lingua franca types that users can use where appropri= ate for common programming issues.
=C2=A0
No. If vector<T> does not have same performance as T* c sty= le array. C-style array will just live forever. That is why std::vector is = implemented as templates, not OOP/
=C2=A0
If you add if check for [], that would encourage= people continue to use c-style-array for better performance.
You have to do everything to make people not have a reason to w= rite their own version of container (for doing the same thing).

No, we don't. The goal of the cont= ainer design was not to make it so that nobody would ever use any other con= tainer. It was to make it so that people would only use other containers in= exceptional circumstances.

There is no one-size-f= its-all approach here, and trying to build one will only end in tears.
<= /div>

That's not to say that I wouldn't mind hav= ing unchecked push-back operations on `vector`. I think it's asinine to= say that we don't need one because optimizers will remove it when they= can detect that it will always be filled. Optimizers can't see or know= everything:

int c= ount;file_stream >> count;

vector<int>= vec;
vec.<= /span>reserve(= count);=

for(au= to x :<= /span> crange(= count))=
{
=C2=A0 vec.emplace_back();
=C2=A0 file_stream >> ve= c.back<= /span>();
<= /span>}

=
Can an optimizer remove the test in this case? More importa= ntly, if you're looking at this code, is it reasonable to expect= an optimizer to be able to do so?

Pre= tty hard.
Also we should not expect optimizer to remove test. The= y have different behaviors. Before C++11, you might even expect optimizer t= o optimize copy for vector<T>.

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/405f3ea9-d886-4c3f-9543-= a276f8214974%40isocpp.org.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/ceb5fbaa-7e73-4c54-b10e-46712f604836= %40isocpp.org.
------=_Part_14551_986730312.1508000917617-- ------=_Part_14550_1672372146.1508000917616-- .