220 39299 article Path: news.gmane.org!.POSTED!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Standardising a type-erased iterator Date: Mon, 23 Jul 2018 10:16:18 -0400 Lines: 242 Approved: news@gmane.org Message-ID: References: <09db196a-e818-4d7a-9af1-48f07b2f4c3d@isocpp.org> <24d8f121-aba9-4ead-b107-bc4b72014870@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000008f1230571ab4a87" X-Trace: blaine.gmane.org 1532355255 10050 195.159.176.226 (23 Jul 2018 14:14:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2018 14:14:15 +0000 (UTC) To: Standard Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQILHRWX3ICRUBDAUIFI2@isocpp.org Mon Jul 23 16:14:11 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhbbF-0002RR-Rx for gclcip-std-proposals@m.gmane.org; Mon, 23 Jul 2018 16:14:10 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id t138-v6sf626592oih.5 for ; Mon, 23 Jul 2018 07:16:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1532355380; cv=pass; d=google.com; s=arc-20160816; b=cot66KWaVZZDMALDlcJrMS55dq2U7hexxpEZiewUk2oWqqxfje5v4aactVYSHgOCrq P1DugZwfrfukYdLzZJpRv7k155HHQbkKyggukXmT2M3xAwVy4gk4DO2GNv3e9CpxKsTO 5mMNzB97OxCQ65mYqgVL/lSyWuf6H95wA4eEB3f4oV3GYLJhxFQXicgZ3Jc+eXSKnrsT +zdbGM6zA4vKTinXCgCwXHHnwdOfUSzGRHDucXu7WEjnO8qgP0E4AlmBVI88D9ujoSaw PSSmj2Z2A9X+bCRpRpdZa6f2rmtSeHYZ+E9DtfeTxMW0KLGpQGqUnKCKgGN0hAve+IWJ MuOw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=plhd2cj0zT/WiRNJU0/pRR/y6xLRPmebWMyhUxRokjM=; b=kTZ1d/8mjlw6KsVfdjwcXgIU3n93eZ++drhuQANXDT930UXbFo1THXBQBaN0Nv6unN qyr2IBw/giIBYpr8Uw8uXbk13wert7HmqJ0fD/UxVpoSasbS/6fO1OSF6GFN4HUK1VNN 34PqgZrW4hz5nYIVyqM7KZwSyknyxMmypHK9S4P1hHp3o8z/pbbqtPlkAXE2IolbVmdB 5tubILykJPiVqKkrqaLN9lI6gvipnttUmm7bxvX4vra39VrxAMnf7inoBgPFda0Hs0/Z vmtpD+bj78148SKtGHK0bMJRQ5Csz5qQxmG7VxIJ6jnVRaDMUkyKICJs7VHroeB0Nfew jI8w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rOZzUzc9; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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; bh=plhd2cj0zT/WiRNJU0/pRR/y6xLRPmebWMyhUxRokjM=; b=hZLIyLAro/3L5V8BLDu3twjfvUNFAkUZfw+SXbB09EiJ7Y6sS5PwE9MhhZSeoNrEi/ xFmexjleKaanPVuB0Au849AKYbpPBHqqXjhEdxPVw9qdacJTOVDeX77uD9QInqY8l5cR JjJ6ZzTx99osL0hz+8aWWhmHJHTFTEnXTSrt9Xmjz122NllNR4UG5/4RaszZfj0wYBww hXqhW108WpOFQo33PFRNxq4N4NwPdUXUyWopxZL/HfeHEa5VpSW3PsGeMZ38BxIhXk5d 2ZUS2gBTvXjI3kh/AMQQM/vQUTTbGGMxKkh7QxEpLLHf4cSaGbl084PPU3anNrWc8d+K B3HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=plhd2cj0zT/WiRNJU0/pRR/y6xLRPmebWMyhUxRokjM=; b=lX1iQqL+uRrJpu1RZElu05NoivhGJ+y/bx4qaNIY6M82RnL2VC9usN26zGOdb1aTmT 8nk80CXiBNew/7sd3KaXirViRnK/aA9w+a0EBD5TdHYVpYv290j2TIM3IsI4yShdW6fu 2sb3uOl2xqQ2hr2NwfYi/19LrjRojkyVTqPsRljKZIBKdAvLbOIdo2DBPMcKoylbbFcg CjEyRS9vzAtuX/2BRS8ohIOryZzaYa5Mo0dKd+OOT4qltYbm8xE+i7YpNnFSen2yop7y 459h5RO4wde2pK5ifvVjoiM7viarnNDUglVs4MSqasgD0WYq8tpLfdVtcGg5QHXB8auz lJ9A== X-Gm-Message-State: AOUpUlFhHDyRKQOVAtPY0XzGFOb8v34/v0DvLxKLda2ctptf4o4HNoAq 5gglOuckAiC+57QbDzpik7X56A== X-Google-Smtp-Source: AAOMgpds8cr7wVFflwyeMOxNPQUvRDfLkpigq1/Wk4SqcaeUDqMbOS0aDvyjro7iRsN9Vy1LcRyRvw== X-Received: by 2002:aca:3903:: with SMTP id g3-v6mr9650740oia.85.1532355380546; Mon, 23 Jul 2018 07:16:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:430a:: with SMTP id q10-v6ls5097997oia.15.gmail; Mon, 23 Jul 2018 07:16:19 -0700 (PDT) X-Received: by 2002:aca:4141:: with SMTP id o62-v6mr7975273oia.24.1532355379417; Mon, 23 Jul 2018 07:16:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532355379; cv=none; d=google.com; s=arc-20160816; b=s6ZZV0JtyYHU9uS4kVTHfP4BioJBmDBhUtJDNmjeApHhWbFlnlGgSZe7ibNSlG0iNW tPuGY0Y7f+HhxqQ+pCw6DsCg8cUEFDBdbwKgHoVDKKmrMLmmDW9IMzxda4kDL5309B7o BKkYCBmA2sWJcjThNsab1rNBcsEUYt8rzOid89rlLbQ0C5xsYqck8FW/u/QuzXb89SKA qSiAF3FwxjJh5tJwIQjjNgf0PeebFXERre9v6ROLvD3WXUJ9WvFBVU/ThGcLsJWfeUdc F4d/l4caJukU66Pr7WZunNBHkJXkeYiAT2FfNTFA8Vh6xBbYu3iN56C03YJIc0raGrOU uidg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=f8aauzH6hJ2Q+ARYYJntBvCjenWThgjvZJlp697VXUE=; b=bahajduVYYupCq/lKbGa1P9V9lP72oEU/JT2W5nMzXZHoonVbXotdrYwKB8OmTvcuU +T9f8sLubvPNsFXYdKSLfGnSx90axWuzDobYBrriq38PunNrqzpExyAF71G4udn9hynB /I+jIyVN9WYFJM1CACw8u/ukxq1supFItpgRi2UV2AgIP18Yt3VaDobJp/SCYYq9F2Hn 0Ytv71fj0b3Tlsd7PX9WMrqFWefa1SfM43341X727Hx/LcIFBtE1rlyamDyiVeVRHdRK /+KgTjNc1m+N8N7mQwJeSlqtcTirv3R29twCkKzINBsd1FAQiBP40jXkLLCubmfQXmtc je8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rOZzUzc9; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id x66-v6sor5449663oia.100.2018.07.23.07.16.19 for (Google Transport Security); Mon, 23 Jul 2018 07:16:19 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:aca:5583:: with SMTP id j125-v6mr9293225oib.2.1532355378998; Mon, 23 Jul 2018 07:16:18 -0700 (PDT) Original-Received: by 2002:a9d:ea6:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 07:16:18 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rOZzUzc9; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39299 Archived-At: --00000000000008f1230571ab4a87 Content-Type: text/plain; charset="UTF-8" I've wanted type-erased iterators a few times, on various projects, various companies. Currently we deal with 3D points a lot. Often in vectors. Sometimes in other containers. Sometimes the 3D point is just part of a bigger struct. So we get a vector of FooBars and each FooBar has a 3D point (or 2 different 3D points, like 'source' and 'dest' and we need to pick which we are processing.) For many algorithms we use, the cost of "get next point" is small compared to other processing. And the amount of code in the algorithm is high for a template. So I see lots of code that copies tens of thousands of points from one container into another, so that it is in the right format, ie so that it can pass in a vector. We might also transform each point tmp = f(*it) before processing it. That could also be in the iterator. On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges wrote: > > > On Mon, 23 Jul 2018 at 09:01, Thomas Russell > wrote: > >> The motivation is similar to having any standard type-erased facility; it >> gives a concrete interface that accepts an arbitrary set of classes that >> conform to the required concepts. >> >> The closest existing parallel in the standard library is `std::function`, >> modelling the Callable concept. >> >> Having such a facility as a vocabulary type provides various benefits >> over function templates accepting Callables: >> - Reduced generated code-size (this can even go some way towards reducing >> the performance penalty). >> - Works with the OOP paradigm (virtual functions cannot be function >> templates) >> - Reduced compile-time >> - Can work across dynamically-linked library boundaries, providing the >> correctly corresponding build parameters are met. >> >> I think these are good motivations, but am interested to hear opposing >> opinions. >> > > I think it would be fair to say that they are theoretical or hypothesised > motivations, not actual concrete use cases where there is a demonstrable > benefit in providing a standardised type-erased iterator suite. > > I'm thinking in terms of "here's some current software that sucks because > we don't have type-erased iterators, and presented here is a better version > using my implementation of such iterators". > > I say this not to be argumentative. > > I say it because like you and many others, I have played with similar > ideas because they were fun or interesting ideas. Including for example a > type-erased iterator for iterating across a tuple (operator* returns a > boost::variant of references). > > However, in 30 years on and off writing commercial software, I have never > encountered an actual use case while using c++. > > This is probably because I reach for c++ when seeking concrete guarantees > on type safety, and python, perl or javascript when I'm seeking type > flexibility and expressiveness. > > But it could be that I am thinking myopically. I have experimented in the > past with providing more "script-like" library objects to the odd project. > Again, out of curiosity more than need. > > You see what I'm saying? Is this in reality a fun personal project, or is > there a tangible benefit to me if I find this in the std toolbox? > > >> >> -- >> 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/c9664ef6-f769-4942- >> 8e44-56761d091efc%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/CALvx3haDm01D7jCvJJA3JJycraXVZ > _WHz9A4md5h1WXhCR29cg%40mail.gmail.com > > . > -- Be seeing you, Tony -- 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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com. --00000000000008f1230571ab4a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've wanted type-erased iterators a few times, on= various projects, various companies.

Currently we= deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 Sometimes in othe= r containers.=C2=A0 Sometimes the 3D point is just part of a bigger struct.= =C2=A0 So we get a vector of FooBars and each FooBar has a 3D point (or 2 d= ifferent 3D points, like 'source' and 'dest' and we need to= pick which we are processing.)

For many algor= ithms we use, the cost of "get next point" is small compared to o= ther processing. And the amount of code in the algorithm is high for a temp= late.

So I see lots of code that copies tens o= f thousands of points from one container into another, so that it is in the= right format, ie so that it can pass in a vector<Point3D>.
We might also transform each point tmp =3D f(*it) before processing it.=C2= =A0 That could also be in the iterator.



On Mon, Jul 23, 201= 8 at 5:14 AM, Richard Hodges <hodges.r@gmail.com> wrote:


On Mon, 23 Jul 2018 at 09:01, Th= omas Russell <thomas.russell97@gmail.com> wrote:
The motivation is similar to having any standard type-erased = facility; it gives a concrete interface that accepts an arbitrary set of cl= asses that conform to the required concepts.

The closest existing parallel in the standard library is `std::function`, m= odelling the Callable concept.

Having such a facility as a vocabulary type provides various benefits over = function templates accepting Callables:
- Reduced generated code-size (this can even go some way towards reducing t= he performance penalty).
- Works with the OOP paradigm (virtual functions cannot be function templat= es)
- Reduced compile-time
- Can work across dynamically-linked library boundaries, providing the corr= ectly corresponding build parameters are met.

I think these are good motivations, but am interested to hear opposing opin= ions.

I think it would be fair = to say that they are theoretical or hypothesised motivations, not actual co= ncrete use cases where there is a demonstrable benefit in providing a stand= ardised type-erased iterator suite.

I'm thinki= ng in terms of "here's some current software that sucks because we= don't have type-erased iterators, and presented here is a better versi= on using my implementation of such iterators".

I say this not to be argumentative.

I say it bec= ause like you and many others, I have played with similar ideas because the= y were fun or interesting ideas. Including for example a type-erased iterat= or for iterating across a tuple (operator* returns a boost::variant of refe= rences).

However, in 30 years on and off writing c= ommercial software, I have never encountered an actual use case while using= c++.

This is probably because I reach for c++ whe= n seeking concrete guarantees on type safety, and python, perl or javascrip= t when I'm seeking type flexibility and expressiveness.

<= /div>
But it could be that I am thinking myopically. I have experimente= d in the past with providing more "script-like" library objects t= o the odd project. Again, out of curiosity more than need.=C2=A0
=
You see what I'm saying? Is this in reality a fun person= al project, or is there a tangible benefit to me if I find this in the std = toolbox?
=C2=A0

--
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.
To view this discussion on the web visit https://groups.google.co= m/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44= -56761d091efc%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-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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29c= g%40mail.gmail.com.



--
Be seeing = you,
Tony

--
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/CAOHCbivaZbbS= -zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com.
--00000000000008f1230571ab4a87-- .