220 5903 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove vector? Date: Tue, 27 Aug 2013 16:17:25 -0700 (PDT) Lines: 161 Approved: news@gmane.org Message-ID: References: <521B07D2.8070000@beamways.com> <7d0bc129-f8aa-4803-bbd9-bd5ca504d728@isocpp.org> <77e0868c-6aed-4578-acc7-7cf1227465f6@isocpp.org> <4E5B6BD9-363D-4B42-ACA3-029301F3F54E@gmail.com> <521C74C5.6060801@beamways.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14_24552669.1377645445978" X-Trace: ger.gmane.org 1377645446 24518 80.91.229.3 (27 Aug 2013 23:17:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 23:17:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBB7H6SIAKGQEGFDXPHY@isocpp.org Wed Aug 28 01:17:29 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VESVs-0006gJ-Uq for gclcip-std-proposals@m.gmane.org; Wed, 28 Aug 2013 01:17:29 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id wc20sf20575548obb.9 for ; Tue, 27 Aug 2013 16:17:28 -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=5zjHyIHetEAqWetxJaGe4zuGE6IxVMjAlpEDs74ybeo=; b=SDgfwCI1haUYuJGQYblFNwDxFMR4V5Jtkz28Zj34eWlin4TUSBhgaTBNFdJBmGifPG GB1Un3Q9wdb2mtRiz/x4bcPd2EILq+U5b9d4ZXr+RSpz5iIG+KoZ49WqSXVC93qjEzO7 jpfGc3AXuIC314YL0ZjDcGh2XDg/KreaQh+VRMaAZsB+0bvpM2iUDUh7wndXpnv8vr/R 59aTj9b53r1J5n/ALCQK6bYe5juLLN6aZ+2mLYTOUKNm0LS0LLoUmIsxZr9mlD9/j0Yk O/o10d3fLSx/t8QiHAHU0PpMJL91N1nrFsJBVhVCTkB1gAO8rBHrRI3gINKSGvpZNmhh SLLQ== X-Received: by 10.50.129.42 with SMTP id nt10mr12348493igb.0.1377645447915; Tue, 27 Aug 2013 16:17:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.3.70 with SMTP id a6ls3436535iga.44.canary; Tue, 27 Aug 2013 16:17:26 -0700 (PDT) X-Received: by 10.50.61.162 with SMTP id q2mr782133igr.10.1377645446918; Tue, 27 Aug 2013 16:17:26 -0700 (PDT) In-Reply-To: <521C74C5.6060801@beamways.com> X-Original-Sender: jmckesson@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:5903 Archived-At: ------=_Part_14_24552669.1377645445978 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson wrote: > > > Zhihao Yuan skrev 2013-08-27 01:57: > > On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant > > > wrote: > >> Question for Zhihao: > >> > >> Why does forward iterator's operator*() have to return a value_type& ? > >> > >> I'm well aware that this is what C++98/03/11 requires. That's not what > I'm asking. I'm asking what is the benefit of this requirement in the > C++1y context? What problem does this requirement solve? > > Afaics, it makes the pointed object modifiable. And move_iterator > > significantly benefits from it. (Here is something I'm not sure: > > move_iterator requires only InputIterator, while dereferencing an > > InputIterator may return anything convertible to T -- is there anything > > broken here?) > > > No, he must be refering to something else, as the return value of > vector::iterator::operator* does indeed make the pointed object > modifiable. > > I don't like when people speak in riddles to make other people feel like > idiots! Please instead try to explain the issue at hand as clearly as > you can. > > The prime example I have been given of the badness of the vector > specialization is that it does not have a .data() method. So be it, but > in what case is using .data() preferred to using iterators? > Because it's part of std::vector's interface. std::vector *requires* that this code works: vector t{...}; T* tp = &t[0]; tp += 3; *tp == t[3]; And that will work for all T... so long as T is not `bool`. It is not for you to decide whether this is good code or not. That's the interface that `vector` provides by the standard, and that is the interface that we should expect to have. And we do... as long as T is not `bool`. There is no reason why this should be the case. A space-optimized object can be used separately. -- --- 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_14_24552669.1377645445978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Beng= t Gustafsson wrote:

Zhihao Yuan skrev 2013-08-27 01:57:
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> <howard....@gmail.com> wrote:
>> Question for Zhihao:
>>
>> Why does forward iterator's operator*() have to return a value= _type& ?
>>
>> I'm well aware that this is what C++98/03/11 requires.  T= hat's not what I'm asking.  I'm asking what is the benefit of this req= uirement in the C++1y context?  What problem does this requirement sol= ve?
> Afaics, it makes the pointed object modifiable.  And move_ite= rator
> significantly benefits from it.  (Here is something I'm not s= ure:
> move_iterator requires only InputIterator, while dereferencing an
> InputIterator may return anything convertible to T -- is there any= thing
> broken here?)
>
No, he must be refering to something else, as the return value of=20
vector<bool>::iterator::operator* does indeed make the point= ed object=20
modifiable.

I don't like when people speak in riddles to make other people feel lik= e=20
idiots! Please instead try to explain the issue at hand as clearly as= =20
you can.

The prime example I have been given of the badness of the vector<boo= l>=20
specialization is that it does not have a .data() method. So be it, but= =20
in what case is using .data() preferred to using iterators?

Because it's part of std::vector's interface. std::vector *re= quires* that this code works:

vector<T>= t{...};
T= * tp =3D &t[0];<= /span>
tp +=3D 3;
*tp =3D=3D t[3];
=

And that will work for all T... so long as T is not `bool`.
It is not for you to decide whether this is good code or not. That's the = interface that `vector` provides by the standard, and that is the interface= that we should expect to have. And we do... as long as T is not `bool`.
There is no reason why this should be the case. A space-optimized obje= ct can be used separately.

--
 
---
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_14_24552669.1377645445978-- .