220 5914 <521DA66A.9060804@beamways.com> article
Path: news.gmane.org!not-for-mail
From: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Wed, 28 Aug 2013 09:27:38 +0200
Lines: 302
Approved: news@gmane.org
Message-ID: <521DA66A.9060804@beamways.com>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com>	<b06daeb3-a585-4c55-aebf-cae643146838@isocpp.org>	<CAGg_6+O_d85CBjT+cTV6vQqepUTXVvUMV_QUioS6ELpQCav6GQ@mail.gmail.com>	<521B07D2.8070000@beamways.com>	<7d0bc129-f8aa-4803-bbd9-bd5ca504d728@isocpp.org>	<CAGsORuB8omCBfjco6i_zENDn23tx-5wg1jeHuhsGsiVMbGk+Ww@mail.gmail.com>	<77e0868c-6aed-4578-acc7-7cf1227465f6@isocpp.org>	<CAGsORuAAZChA8cyx4JTTqRmMNSGQXZyGdzrm9P0WVRMZSSg6Qw@mail.gmail.com>	<4E5B6BD9-363D-4B42-ACA3-029301F3F54E@gmail.com> <CAGsORuCDbX4k2ZOcnoR1QwfQoain5anNrm1as5wvpe38Vg=iow@mail.gmail.com> <521C74C5.6060801@beamways.com> <a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------090301070808090304050208"
X-Trace: ger.gmane.org 1377674857 11448 80.91.229.3 (28 Aug 2013 07:27:37 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 28 Aug 2013 07:27:37 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCRIRSPDTQIRBZWM62IAKGQE3MA3ZJQ@isocpp.org Wed Aug 28 09:27:40 2013
Return-path: <std-proposals+bncBCRIRSPDTQIRBZWM62IAKGQE3MA3ZJQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-wi0-f200.google.com ([209.85.212.200])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCRIRSPDTQIRBZWM62IAKGQE3MA3ZJQ@isocpp.org>)
	id 1VEaAB-0007Nk-Pb
	for gclcip-std-proposals@m.gmane.org; Wed, 28 Aug 2013 09:27:35 +0200
Original-Received: by mail-wi0-f200.google.com with SMTP id c10sf2736296wiw.11
        for <gclcip-std-proposals@m.gmane.org>; Wed, 28 Aug 2013 00:27:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-original-sender:x-original-authentication-results
         :reply-to:precedence:mailing-list:list-id:list-post:list-help
         :list-archive:list-subscribe:list-unsubscribe:content-type;
        bh=is+i2eP4ahkhAZ5qRKT1nsStVNLcBlMr4m1MkqmrZUU=;
        b=H9hReTiJKaTQx1Vmm+Gr6HWjfDaRzqpypoPkJVbIXt9o1AnvozUCTKwATcGsAuTznk
         gHwnqujpn2xJk9xv5hwNMHg9+DMNLzyUobyqrkBPvK3c/IleONCBtFKP7pfjYeZUuqh3
         rO3kNeDJYHcQixwR0PNqZKPgDswsCWg/WeM2BkVRkKOgyf4ngmDY+MjqQESIxCQIYTQq
         FdydJhUCodiCiLuywL0sAunKVAH745BQMw3lBUwGDSIVDlGQ507xe62fl85YSWAhsQMU
         kJcUyvNUuAig6s1f0Nf1XouNNdGRPUgjkM7Ih+7b+CPcXeIDe7SU/KRUDiwD8lD46t3A
         n0mQ==
X-Received: by 10.112.149.102 with SMTP id tz6mr5658715lbb.7.1377674854969;
        Wed, 28 Aug 2013 00:27:34 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.152.36.137 with SMTP id q9ls13131laj.62.gmail; Wed, 28 Aug
 2013 00:27:34 -0700 (PDT)
X-Received: by 10.152.36.98 with SMTP id p2mr2898770laj.14.1377674853989;
        Wed, 28 Aug 2013 00:27:33 -0700 (PDT)
Original-Received: from vsp01.s.thehostingplatform.com (vsp01.s.thehostingplatform.com. [213.180.89.118])
        by mx.google.com with ESMTPS id h7si4938657laa.139.1969.12.31.16.00.00
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Wed, 28 Aug 2013 00:27:33 -0700 (PDT)
Received-SPF: neutral (google.com: 213.180.89.118 is neither permitted nor denied by best guess record for domain of bengt.gustafsson@beamways.com) client-ip=213.180.89.118;
Original-Received: from [192.168.1.68] (unknown [85.229.130.195])
	by vsp01.s.thehostingplatform.com (Halon Mail Gateway) with ESMTPSA
	for <std-proposals@isocpp.org>; Wed, 28 Aug 2013 09:27:30 +0200 (CEST)
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org>
X-Original-Sender: bengt.gustafsson@beamways.com
X-Original-Authentication-Results: mx.google.com;       spf=neutral
 (google.com: 213.180.89.118 is neither permitted nor denied by best guess
 record for domain of bengt.gustafsson@beamways.com) smtp.mail=bengt.gustafsson@beamways.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5914
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/5914>

This is a multi-part message in MIME format.
--------------090301070808090304050208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


Nicol Bolas skrev 2013-08-28 01:17:
>
>
> 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
>     > <howard....@gmail.com <javascript:>> 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<bool>::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<bool>
>     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*=20
> that this code works:
>
> |
> vector<T>t{...};
> T*tp =3D&t[0];
> tp +=3D3;
> *tp =3D=3Dt[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=20
> the interface that `vector` provides by the standard, and that is the=20
> interface that we should expect to have. And we do... as long as T is=20
> not `bool`.
>
No, the standard says exactly what the standard says: The code above=20
should work for all T except bool. There is a special clause in the=20
standard detailing that vector<bool> is to be specialized to NOT work as=20
you claim. That's what we are discussing here, isn't it? You can claim=20
that we should change the standard because it is inconsistent or=20
confusing but can NOT claim that we should change the standard because=20
it contradicts itself!

Personally I am indifferent, as I don't use vector<bool>. But I don't=20
want the standard to be changed under the feet of people, and I dislike=20
that more than it being clumsy as it is. In addition I think that C++=20
should focus on being an outstanding performer, which is why I suggested=20
to include APIs to allow fast implementations of algorithms in a=20
portable way.

> There is no reason why this should be the case. A space-optimized=20
> object can be used separately.
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com

--=20

---=20
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 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-proposa=
ls/.

--------------090301070808090304050208
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">Nicol Bolas skrev 2013-08-28 01:17:<br>
    </div>
    <blockquote
      cite="mid:a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        <br>
        On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson
        wrote:
        <blockquote class="gmail_quote" style="margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <br>
          Zhihao Yuan skrev 2013-08-27 01:57:
          <br>
          &gt; On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
          <br>
          &gt; &lt;<a moz-do-not-send="true" href="javascript:"
            target="_blank" gdf-obfuscated-mailto="Mz1mbb_j3g8J">howard....@gmail.com</a>&gt;
          wrote:
          <br>
          &gt;&gt; Question for Zhihao:
          <br>
          &gt;&gt;
          <br>
          &gt;&gt; Why does forward iterator's operator*() have to
          return a value_type&amp; ?
          <br>
          &gt;&gt;
          <br>
          &gt;&gt; I'm well aware that this is what C++98/03/11
          requires. &nbsp;That's not what I'm asking. &nbsp;I'm asking what is the
          benefit of this requirement in the C++1y context? &nbsp;What
          problem does this requirement solve?
          <br>
          &gt; Afaics, it makes the pointed object modifiable. &nbsp;And
          move_iterator
          <br>
          &gt; significantly benefits from it. &nbsp;(Here is something I'm
          not sure:
          <br>
          &gt; move_iterator requires only InputIterator, while
          dereferencing an
          <br>
          &gt; InputIterator may return anything convertible to T -- is
          there anything
          <br>
          &gt; broken here?)
          <br>
          &gt;
          <br>
          No, he must be refering to something else, as the return value
          of <br>
          vector&lt;bool&gt;::iterator::<wbr>operator* does indeed make
          the pointed object <br>
          modifiable.
          <br>
          <br>
          I don't like when people speak in riddles to make other people
          feel like <br>
          idiots! Please instead try to explain the issue at hand as
          clearly as <br>
          you can.
          <br>
          <br>
          The prime example I have been given of the badness of the
          vector&lt;bool&gt; <br>
          specialization is that it does not have a .data() method. So
          be it, but <br>
          in what case is using .data() preferred to using iterators?<br>
        </blockquote>
        <div><br>
          Because it's part of std::vector's interface. std::vector
          *requires* that this code works:<br>
          <br>
          <div class="prettyprint" style="background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code
              class="prettyprint">
              <div class="subprettyprint"><span style="color: #000;"
                  class="styled-by-prettify">vector</span><span
                  style="color: #660;" class="styled-by-prettify">&lt;</span><span
                  style="color: #000;" class="styled-by-prettify">T</span><span
                  style="color: #660;" class="styled-by-prettify">&gt;</span><span
                  style="color: #000;" class="styled-by-prettify"> t</span><span
                  style="color: #660;" class="styled-by-prettify">{...};</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  T</span><span style="color: #660;"
                  class="styled-by-prettify">*</span><span style="color:
                  #000;" class="styled-by-prettify"> tp </span><span
                  style="color: #660;" class="styled-by-prettify">=</span><span
                  style="color: #000;" class="styled-by-prettify"> </span><span
                  style="color: #660;" class="styled-by-prettify">&amp;</span><span
                  style="color: #000;" class="styled-by-prettify">t</span><span
                  style="color: #660;" class="styled-by-prettify">[</span><span
                  style="color: #066;" class="styled-by-prettify">0</span><span
                  style="color: #660;" class="styled-by-prettify">];</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  tp </span><span style="color: #660;"
                  class="styled-by-prettify">+=</span><span
                  style="color: #000;" class="styled-by-prettify"> </span><span
                  style="color: #066;" class="styled-by-prettify">3</span><span
                  style="color: #660;" class="styled-by-prettify">;</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                </span><span style="color: #660;"
                  class="styled-by-prettify">*</span><span style="color:
                  #000;" class="styled-by-prettify">tp </span><span
                  style="color: #660;" class="styled-by-prettify">==</span><span
                  style="color: #000;" class="styled-by-prettify"> t</span><span
                  style="color: #660;" class="styled-by-prettify">[</span><span
                  style="color: #066;" class="styled-by-prettify">3</span><span
                  style="color: #660;" class="styled-by-prettify">];</span></div>
            </code></div>
          <br>
          And that will work for all T... so long as T is not `bool`.<br>
          <br>
          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`.<br>
          <br>
        </div>
      </div>
    </blockquote>
    No, the standard says exactly what the standard says: The code above
    should work for all T except bool. There is a special clause in the
    standard detailing that vector&lt;bool&gt; is to be specialized to
    NOT work as you claim. That's what we are discussing here, isn't it?
    You can claim that we should change the standard because it is
    inconsistent or confusing but can NOT claim that we should change
    the standard because it contradicts itself!<br>
    <br>
    Personally I am indifferent, as I don't use vector&lt;bool&gt;. But
    I don't want the standard to be changed under the feet of people,
    and I dislike that more than it being clumsy as it is. In addition I
    think that C++ should focus on being an outstanding performer, which
    is why I suggested to include APIs to allow fast implementations of
    algorithms in a portable way.<br>
    <br>
    <blockquote
      cite="mid:a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org"
      type="cite">
      <div dir="ltr">
        <div>There is no reason why this should be the case. A
          space-optimized object can be used separately.<br>
        </div>
      </div>
      -- <br>
      &nbsp;<br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
      Visit this group at <a moz-do-not-send="true"
        href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link&ouml;ping, Sweden
+46 13 465 10 85
<a class="moz-txt-link-abbreviated" href="http://www.beamways.com">www.beamways.com</a>
</pre>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------090301070808090304050208--

.