220 34920 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:03:26 -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_14650_499460897.1508000606998" X-Trace: blaine.gmane.org 1508000610 10385 195.159.176.226 (14 Oct 2017 17:03:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 17:03:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDPYX6PYRQNBBX4GRHHQKGQEPWI6O6A@isocpp.org Sat Oct 14 19:03:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3PqL-0001bK-R2 for gclcip-std-proposals@m.gmane.org; Sat, 14 Oct 2017 19:03:22 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id c76sf4507780vkd.14 for ; Sat, 14 Oct 2017 10:03:29 -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=m9AsJj6xhWnlfe5W9wBblvHUYipzmQjVbgrJPXrU1vU=; b=sxj/18qJ7ufZmfc/RDpFnEUqKxAiRKTd3q7aRVIrpJyPl98Sl3IdvGNeQVMXa1KTW/ 8JabE3jCL9Xvrc4++WEcRev2sRF8Gbde7lQ15YONvqCxQOFFN98VAwnA1oAuPEBR2AI/ gP12bmZChQ+f7JY5ciH5MyaUgLcL6rQkc9q0vkPi5HlB2EfhnBYnZwol/OFe+GbafrOh mUOumOjGZYGjw2B5+v/Vpjs3O7eWeyTL96ilVZxKNprbvA3zWEZRLcNLwKhVz8eowV0H BbBa8D+clKZwPp2tAGGFQ9I7CaRIl0opBbHe+e/T+AH5e2WbB/21ec81s2zDb/FEDv3c rEfg== 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=m9AsJj6xhWnlfe5W9wBblvHUYipzmQjVbgrJPXrU1vU=; b=VoPykDW79esQFdquJdhC5iBhStM60M8c40PsvB5jjWPf31aKCbZNOZmGPfYp3UV3CX pTGH0U7/kaKsLGfri0Nu9Fb1kektfZ7Cpd4OKiNOivAm3ibwQlsytWJpX+5bzNdfHyWU tvKP75Jwq68ZcHNsdN6PbXY1hpXvR6sZTkwbqLpPwon12OVIa/OnaXT5iptW7M9qX2+2 vZ5N5tKweTE1V1w+RY3rKIxBrXrEkY3hKHFw5Q1lwILbHmPM+aa3qnWB2Ny3QxAPYjWX ezj0koDvum8VXBFpHAjfD+fzYkvyi3wA1XIHDrza9pJzWvnW4NrAmS6A59fnmqAyPm0/ JGzQ== X-Gm-Message-State: AMCzsaUvB7iHZyryrpLox0/Rogbc1EECHK03WsICaTUoID7Oz9wO+TAS jApXnts9U5PUGkLzQMtmWU/Fug== X-Google-Smtp-Source: AOwi7QDcP6pYiVUQYKHCGMOg50jfmxNpr4/EBrIBx5xK+AK03AAU2mGDzfD/EpsHez5N9yWz4F6DNw== X-Received: by 10.31.138.75 with SMTP id m72mr2488316vkd.123.1508000608956; Sat, 14 Oct 2017 10:03:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.77.90 with SMTP id k26ls850958uag.3.gmail; Sat, 14 Oct 2017 10:03:27 -0700 (PDT) X-Received: by 10.31.201.3 with SMTP id z3mr320360vkf.0.1508000607467; Sat, 14 Oct 2017 10:03:27 -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:34920 Archived-At: ------=_Part_14650_499460897.1508000606998 Content-Type: multipart/alternative; boundary="----=_Part_14651_280075224.1508000606999" ------=_Part_14651_280075224.1508000606999 Content-Type: text/plain; charset="UTF-8" Of course. However, std::array does not solve my problem. 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/c5ef6d4a-b54b-4398-ba57-cc22c34323e1%40isocpp.org. ------=_Part_14651_280075224.1508000606999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of course. However, std::array does not solve my problem.<= br>
On Saturday, October 14, 2017 at 12:44:17 PM UTC-4, Ren Industries w= rote:
Do you = happen to know of std::array?

On O= ct 14, 2017 11:40, <eulo...@live.com> wrote:
=


On Saturday, Octobe= r 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 oth= er C style/OOP style implementation.

... no, it's not.

The main purpose of st= andard library containers is to be useful to C++ programmers. To provide va= lue to the language by having lingua franca types that users can use where = appropriate for common programming issues.
=C2=A0
=
No. If vector<T> does not have same performance as = T* c style array. C-style array will just live forever. That is why std::ve= ctor is implemented as templates, not OOP/
=C2=A0
If you add if check for [], that would en= courage people continue to use c-style-array for better performance.
<= div>
You have to do everything to make people not have a reas= on to write their own version of container (for doing the same thing).
<= /div>

No, we don't. The goal of t= he container design was not to make it so that nobody would ever use any ot= her container. It was to make it so that people would only use other contai= ners in exceptional circumstances.

There is no one= -size-fits-all approach here, and trying to build one will only end in tear= s.

That's not to say that I wouldn't m= ind having unchecked push-back operations on `vector`. I think it's asi= nine to say that we don't need one because optimizers will remove it wh= en they can detect that it will always be filled. Optimizers can't see = or know everything:

int count;
file_stream >> count;

vector<i= nt> vec;
vec.reserve(count);

for(auto x : crange(count))
{
=C2=A0 vec.emplace_back();
=C2=A0 file_strea= m >> vec.back();
}

=
Can an optimizer remove the test in this case? More i= mportantly, 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 tes= t. They have different behaviors. Before C++11, you might even expect optim= izer to 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/c5ef6d4a-b54b-4398-ba57-cc22c34323e1= %40isocpp.org.
------=_Part_14651_280075224.1508000606999-- ------=_Part_14650_499460897.1508000606998-- .