220 5824 <521B07D2.8070000@beamways.com> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove vector? Date: Mon, 26 Aug 2013 09:46:26 +0200 Lines: 272 Approved: news@gmane.org Message-ID: <521B07D2.8070000@beamways.com> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010404030202090303070601" X-Trace: ger.gmane.org 1377503185 24838 80.91.229.3 (26 Aug 2013 07:46:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2013 07:46:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRBUUP5SIAKGQEGMXHCBA@isocpp.org Mon Aug 26 09:46:28 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f200.google.com ([209.85.215.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDrVL-0006uS-B8 for gclcip-std-proposals@m.gmane.org; Mon, 26 Aug 2013 09:46:27 +0200 Original-Received: by mail-ea0-f200.google.com with SMTP id q16sf3134173ead.3 for ; Mon, 26 Aug 2013 00:46:27 -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=3oGXv0eTjlbUHbegn7sscFLzlimGb4RANy5hcWtacAs=; b=cvEHwqob/mImajrSKOy/ydHu44P0pg0KLzRR16iW/xXgoEQti7ZjkM+8LFGGpJdNaT uk7mbbqZbNvvN4RlGdW1aLY7zK6YDRJYQNywmuu0FCCxSOi2tyT7CuAnu6H1bQfZEGrO fKuSMbfnbcDvOHkdTVhuVxOQsxA11KYFMOVN+IqDmkdlu6cvieSldJEmf75Nnrgutylt YyQSN32aZ6B41lOTfobYAkIuuCyOHrgG4Lh1ONWn54L+J+QCeh0W4Ih9gnE6+3G/a03F 2ZQU9vQWrn5aTB9mkChHy2ZcBG/oVN9NARmtqybRlTCUlGLgg5H7Zpw5fFU94kMdrUIa u7xA== X-Received: by 10.152.10.72 with SMTP id g8mr2583155lab.10.1377503186709; Mon, 26 Aug 2013 00:46:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.7.74 with SMTP id h10ls171589laa.81.gmail; Mon, 26 Aug 2013 00:46:25 -0700 (PDT) X-Received: by 10.112.64.36 with SMTP id l4mr11525990lbs.15.1377503185499; Mon, 26 Aug 2013 00:46:25 -0700 (PDT) Original-Received: from vsp02.s.thehostingplatform.com (vsp02.s.thehostingplatform.com. [213.180.89.90]) by mx.google.com with ESMTPS id z2si2722569lad.168.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Aug 2013 00:46:25 -0700 (PDT) Received-SPF: neutral (google.com: 213.180.89.90 is neither permitted nor denied by best guess record for domain of bengt.gustafsson@beamways.com) client-ip=213.180.89.90; Original-Received: from [192.168.1.68] (unknown [85.229.130.195]) by vsp02.s.thehostingplatform.com (Halon Mail Gateway) with ESMTPSA for ; Mon, 26 Aug 2013 09:46:22 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 213.180.89.90 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: 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:5824 Archived-At: This is a multi-part message in MIME format. --------------010404030202090303070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I was just trying to be pragmatic about solving the actual problems we=20 are discussing, which should be problems that are of interest to real=20 programmer's use of the language. I freely admit that the vector=20 specialization is a wart but I don't see that this actually creates a=20 lot of problems in the real world. Could anyone exemplify a reasonable=20 usage that fails in a hard to detect way? The real problems I could detect with vector were that the=20 performance of algorithms like count() is significantly less than it=20 could be. I suggested how this could be solved in a way that is totally=20 invisible to the programmer. I also suggested that the API required=20 could be standardized to allow user-defined algorithms to take advantage=20 of the speedup. From a practical programmer's standpoint I think it is very neat that=20 vector hides the fact that there is a special implementation=20 underneath. If another very similar but different class is introduced I=20 can't see that this would make the language easier to understand or use. If bit_vector is introduced all template code that uses vector and=20 would benefit from a packed structure would need to be specialized for=20 bool. Is that really better? In short I think that the formal drawbacks of vector such as "it=20 not being a proper sequence" has very little practical consequence. The=20 advantages of the packed storage is large in some applications, many of=20 which have already been written assuming that storage use will be on par=20 with a packed implementation. I must also correct myself, I was too quick when testing the error=20 message. There is no error message if you do &* on a=20 vector::iterator. This is a real practical problem that can puzzle=20 a programmer, although doing things that would fail like size_t length =3D= =20 &*vec.end() - &*vec.begin() seems rather odd... Most other uses of the=20 pointer actually work as the reference class is intended to mimic what a=20 bool does. Overloading vector::reference::operator&() to do a=20 static_assert(false) could be a solution. Of course there will be a few=20 programs out there that correctly use this operator, but my guess is=20 that such a overload would discover 10 times more bugs than it will=20 break existing, meaningful code. A regular method could be added to do=20 the work of the unoverloaded operator: class reference { .... reference* operator&() { static_assert(false, "you can no longer=20 take the address of a vector::reference, instead use=20 make_pointer()"); } reference* make_pointer() { return this; } }; An alternative solution would be to let operator& return an iterator=20 again. This could be confusing as the main use of &* on an iterator is=20 to convert it to a plain pointer, so personally I would prefer to outlaw=20 operator&, if anything really must be changed. Nevin Liber skrev 2013-08-26 00:04: > On 25 August 2013 16:28, Bengt Gustafsson=20 > >=20 > wrote: > > > - Define that vector::iterator has an API to access more > than one bit at a time, > > > I do not believe the solution to the vector issue is to make it=20 > even more special and different. -1. > > If you really think this functionality is needed in the standard, (a)=20 > create a different class with that functionality, (b) get a lot of=20 > real world usage experience with that class and (c) then propose such=20 > a class for standardization. > > Just my humble opinion, > > --=20 > > Nevin ":-)" Liber > (847) 691-1404 > --=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/. --------------010404030202090303070601 Content-Type: text/html; charset=ISO-8859-1 I was just trying to be pragmatic about solving the actual problems we are discussing, which should be problems that are of interest to real programmer's use of the language. I freely admit that the vector<bool> specialization is a wart but I don't see that this actually creates a lot of problems in the real world. Could anyone exemplify a reasonable usage that fails in a hard to detect way?

The real problems I could detect with vector<bool> were that the performance of algorithms like count() is significantly less than it could be. I suggested how this could be solved in a way that is totally invisible to the programmer. I also suggested that the API required could be standardized to allow user-defined algorithms to take advantage of the speedup.

From a practical programmer's standpoint I think it is very neat that vector<bool> hides the fact that there is a special implementation underneath. If another very similar but different class is introduced I can't see that this would make the language easier to understand or use.

If bit_vector is introduced all template code that uses vector<T> and would benefit from a packed structure would need to be specialized for bool. Is that really better?

In short I think that the formal drawbacks of vector<bool> such as "it not being a proper sequence" has very little practical consequence. The advantages of the packed storage is large in some applications, many of which have already been written assuming that storage use will be on par with a packed implementation.

I must also correct myself, I was too quick when testing the error message. There is no error message if you do &* on a vector<bool>::iterator. This is a real practical problem that can puzzle a programmer, although doing things that would fail like size_t length = &*vec.end() - &*vec.begin() seems rather odd... Most other uses of the pointer actually work as the reference class is intended to mimic what a bool does.

Overloading vector<bool>::reference::operator&() to do a static_assert(false) could be a solution. Of course there will be a few programs out there that correctly use this operator, but my guess is that such a overload would discover 10 times more bugs than it will break existing, meaningful code. A regular method could be added to do the work of the unoverloaded operator:

class reference {
    ....
    reference* operator&() { static_assert(false, "you can no longer take the address of a vector<bool>::reference, instead use make_pointer()"); }
    reference* make_pointer() { return this; }
};

An alternative solution would be to let operator& return an iterator again. This could be confusing as the main use of &* on an iterator is to convert it to a plain pointer, so personally I would prefer to outlaw operator&, if anything really must be changed.

Nevin Liber skrev 2013-08-26 00:04:
On 25 August 2013 16:28, Bengt Gustafsson <bengt.gustafsson@beamways.com> wrote:

- Define that vector<bool>::iterator has an API to access more than one bit at a time,

I do not believe the solution to the vector<bool> issue is to make it even more special and different.  -1.

If you really think this functionality is needed in the standard, (a) create a different class with that functionality, (b) get a lot of real world usage experience with that class and (c) then propose such a class for standardization.

Just my humble opinion,

-- 
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
--
 
---
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/.

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

--
 
---
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/.
--------------010404030202090303070601-- .