220 34911 <405f3ea9-d886-4c3f-9543-a276f8214974@isocpp.org> 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 08:40:02 -0700 (PDT) Lines: 161 Approved: news@gmane.org Message-ID: <405f3ea9-d886-4c3f-9543-a276f8214974@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14431_1176117802.1507995602918" X-Trace: blaine.gmane.org 1507995612 23212 195.159.176.226 (14 Oct 2017 15:40:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 15:40:12 +0000 (UTC) Cc: euloanty@live.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDPYX6PYRQNBBU67RDHQKGQE2UP5RNY@isocpp.org Sat Oct 14 17:40:08 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3OXd-0003uj-8P for gclcip-std-proposals@m.gmane.org; Sat, 14 Oct 2017 17:39:57 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id f62sf164675vkb.7 for ; Sat, 14 Oct 2017 08:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=J1sBSG/r6OpZD2D41jbQoaT6SH2xqrNeFEb8/9Ym51w=; b=iK1+qH83Xbt2sJ+h4P7iXsAkz++c5yXz6uQvavGNSA5dOCiZfAFbtVvVZxHboExXlM SFVI6L1sL0OeKmt4QCjmQQID7jN3Cpz+Ff2P3vKLcxs9rA2X8LbElnS/5gVfAvn7aKG4 tnmwcqCzvGcNWrJJ/glbSMhFv99i0OG94oxBzE5H2i00bJXuR7gT1pMEz6NzP442M+a3 JU8Ge9zGJlaaAYQbZp2xxEExZ9ISWYE1LUfDkeuKBz/HWxfGWenOHVQcW+Yeqz+CeYir pHSLfpY4dQX/TnnbBgQW3v970+H11jPyJAbL0aXeqtr929erie9E3fvAju+DhNlnOr+P /auw== 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:cc: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=J1sBSG/r6OpZD2D41jbQoaT6SH2xqrNeFEb8/9Ym51w=; b=GqpcttJomvIIuM0ms9W5iLQgPvUiP1TUrWc72CBGdBvUtHE6TFoG+6wSBD+rBJQM7V xR3+NknqD1sgbkTmXwGwG7AS/9cYlyYIt/1ednj6Gr4KhzWeJBy2BGEgLbzijYxP0Up+ 2oH2vqnYVrUpNgiHHYG5Cs7pVcZQe6C3bWk59Nq3cts1YrDqVuoZECL/EDzIHUcBTkQH vu/lU1MI7GVJVsw4zysQqPbnkSPdee1hxHfobFSYv9c2X2ojzUJc/ERUBBrEcjZDiKiP KaxabJP1BWrysrOv/e253yGfB793SK00fP8RcaAKVNUiBFCMUE4JV57XlYJnu9MMP9Mj 1XNA== X-Gm-Message-State: AMCzsaUgyejEbxWX7YP8MtAdvR+4iJHzrRyxN43gX5MOcyo1qujTqdxz +7mu7kyvDO1a0La1XYdMwFd/FQ== X-Google-Smtp-Source: ABhQp+TBFVPLTyIjsNl3R2OWxOkyTbYBsCyS9UjpIn5eHx6/NfscT1zCd14e/U/LNJLWPilo/fbbUw== X-Received: by 10.176.75.142 with SMTP id v14mr934773uaf.21.1507995604676; Sat, 14 Oct 2017 08:40:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.131.146 with SMTP id f140ls2321937vkd.13.gmail; Sat, 14 Oct 2017 08:40:03 -0700 (PDT) X-Received: by 10.31.148.12 with SMTP id w12mr307888vkd.8.1507995603403; Sat, 14 Oct 2017 08:40:03 -0700 (PDT) In-Reply-To: <69a588d5-de2a-4be2-8add-9685d0b9a230@isocpp.org> 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:34911 Archived-At: ------=_Part_14431_1176117802.1507995602918 Content-Type: multipart/alternative; boundary="----=_Part_14432_1466122136.1507995602918" ------=_Part_14432_1466122136.1507995602918 Content-Type: text/plain; charset="UTF-8" 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-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/405f3ea9-d886-4c3f-9543-a276f8214974%40isocpp.org. ------=_Part_14432_1466122136.1507995602918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 ma= in purpose of C++ containers is to compete with other C style/OOP style imp= lementation.

... no, it's n= ot.

The main purpose of standard library container= s is to be useful to C++ programmers. To provide value to the language by h= aving lingua franca types that users can use where appropriate for common p= rogramming issues.
=C2=A0
No. If= vector<T> does not have same performance as T* c style array. C-styl= e array will just live forever. That is why std::vector is implemented as t= emplates, not OOP/
=C2=A0
If you add if check for [], that would encourage people cont= inue to use c-style-array for better performance.

= You have to do everything to make people not have a reason to write their o= wn 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 w= as to make it so that people would only use other containers in exceptional= circumstances.

There is no one-size-fits-all appr= oach here, and trying to build one will only end in tears.
That's not to say that I wouldn't mind having unchecke= d 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<= span style=3D"color:#660">;
file_strea= m >> count;

vector<int> vec;
vec.reserve(count);

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

Can an optimizer remove the test in this case? More importantly, if you&= #39;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 differ= ent behaviors. Before C++11, you might even expect optimizer to optimize co= py 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-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/405f3ea9-d886-4c3f-9543-a276f8214974= %40isocpp.org.
------=_Part_14432_1466122136.1507995602918-- ------=_Part_14431_1176117802.1507995602918-- .