------=_Part_571_1435158571.1482517023723
Content-Type: multipart/alternative;
 boundary="----=_Part_572_649963070.1482517023723"

------=_Part_572_649963070.1482517023723
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,
For a long time I found it misses a simple solution to implode/explode a=20
string in a collection.
There=E2=80=99s solution in boost with split/join but it=E2=80=99s pretty h=
eavy just to=20
paste some string.
I suggest adding on 'basic_string' and 'basic_stringview' an 'explode'=20
method
And on 'basic_string' a static 'implode' method.

Implode can be like that
template<class T, class U>
static auto string_implode(T &InputStringList, U Separator);
taking a container and a separator as parameters

For 'explode' I propose two approaches that can be implemented together at=
=20
the same time.
One with an output reference parameter
template<class T >
void explode(const basic_string& Separator, T &Result)
Another option with a returned container
template<class T >
T explode(const basic_string& Separator)
The result could be both a string collection or a string_view collection
Explode may also be interesting to be part of string_view

You can see implementation example as function here
https://github.com/laurent-n/cpp17_implode_explode

It's not complex but can be helpfull


Regards,
 Laurent

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f609c0d3-c9ba-4a64-a99f-c2e64091b4e2%40isocpp.or=
g.

------=_Part_572_649963070.1482517023723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div>For a long time I found it misses a =
simple solution to implode/explode a string in a collection.</div><div>Ther=
e=E2=80=99s solution in boost with split/join but it=E2=80=99s pretty heavy=
 just to paste some string.</div><div>I suggest adding on <font face=3D"cou=
rier new, monospace">&#39;basic_string&#39;</font> and<font face=3D"courier=
 new, monospace"> &#39;basic_stringview&#39;</font> an <font face=3D"courie=
r new, monospace">&#39;explode&#39;</font> method</div><div>And on=C2=A0<sp=
an style=3D"font-family: &quot;courier new&quot;, monospace;">&#39;basic_st=
ring&#39;</span>=C2=A0a static <font face=3D"courier new, monospace">&#39;i=
mplode&#39;</font> method.</div><div><br></div><div>Implode can be like tha=
t</div><div><font face=3D"courier new, monospace">template&lt;class T, clas=
s U&gt;</font></div><div><font face=3D"courier new, monospace">static auto =
string_implode(T &amp;InputStringList, U Separator);</font></div><div>takin=
g a container and a separator as parameters</div><div><br></div><div>For &#=
39;explode&#39; I propose two approaches that can be implemented together a=
t the same time.</div><div>One with an output reference parameter</div><div=
><font face=3D"courier new, monospace">template&lt;class T &gt;</font></div=
><div><font face=3D"courier new, monospace">void explode(const basic_string=
&amp; Separator, T &amp;Result)</font></div><div>Another option with a retu=
rned container</div><div><font face=3D"courier new, monospace">template&lt;=
class T &gt;</font></div><div><font face=3D"courier new, monospace">T explo=
de(const basic_string&amp; Separator)</font></div><div>The result could be =
both a string collection or a string_view collection</div><div>Explode may =
also be interesting to be part of string_view</div><div><br></div><div>You =
can see implementation example as function here</div><div><a href=3D"https:=
//github.com/laurent-n/cpp17_implode_explode">https://github.com/laurent-n/=
cpp17_implode_explode</a></div><div><br></div><div>It&#39;s not complex but=
 can be helpfull</div><div><br></div><div><br></div><div>Regards,</div><div=
>=C2=A0Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f609c0d3-c9ba-4a64-a99f-c2e64091b4e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f609c0d3-c9ba-4a64-a99f-c2e64091b4e2=
%40isocpp.org</a>.<br />

------=_Part_572_649963070.1482517023723--

------=_Part_571_1435158571.1482517023723--

.

------=_Part_495_1583199172.1482518019228
Content-Type: multipart/alternative;
 boundary="----=_Part_496_1738142451.1482518019228"

------=_Part_496_1738142451.1482518019228
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, December 23, 2016 at 1:17:03 PM UTC-5, lnal...@gmail.com wrote:
>
> Hello,
> For a long time I found it misses a simple solution to implode/explode a=
=20
> string in a collection.
> There=E2=80=99s solution in boost with split/join but it=E2=80=99s pretty=
 heavy just to=20
> paste some string.
> I suggest adding on 'basic_string' and 'basic_stringview' an 'explode'=20
> method
> And on 'basic_string' a static 'implode' method.
>

Um... maybe you should explain what "implode" and "explode" are supposed to=
 *actually=20
do*. I have seen many versions of both of these methods, and I've never=20
heard them referred to with those names. Google suggests that it's a PHP=20
thing, which is yet another reason *not* to use these names.

Typically, it's "split" and "concatenate". Though tokenize is sometimes=20
also used.

Personally, I'd prefer that the "split" function return a range that you=20
can iterate over. That way, we're not wasting valuable memory by allocating=
=20
these things.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/28acb614-af7e-419e-919e-dc4cdfb78999%40isocpp.or=
g.

------=_Part_496_1738142451.1482518019228
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 23, 2016 at 1:17:03 PM UTC-5, lnal...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>Hello,</div><div>For a long time I found it misses a simple solutio=
n to implode/explode a string in a collection.</div><div>There=E2=80=99s so=
lution in boost with split/join but it=E2=80=99s pretty heavy just to paste=
 some string.</div><div>I suggest adding on <font face=3D"courier new, mono=
space">&#39;basic_string&#39;</font> and<font face=3D"courier new, monospac=
e"> &#39;basic_stringview&#39;</font> an <font face=3D"courier new, monospa=
ce">&#39;explode&#39;</font> method</div><div>And on=C2=A0<span style=3D"fo=
nt-family:&quot;courier new&quot;,monospace">&#39;basic_string&#39;</span>=
=C2=A0a static <font face=3D"courier new, monospace">&#39;implode&#39;</fon=
t> method.</div></div></blockquote><div><br>Um... maybe you should explain =
what &quot;implode&quot; and &quot;explode&quot; are supposed to <i>actuall=
y do</i>. I have seen many versions of both of these methods, and I&#39;ve =
never heard them referred to with those names. Google suggests that it&#39;=
s a PHP thing, which is yet another reason <i>not</i> to use these names.<b=
r><br>Typically, it&#39;s &quot;split&quot; and &quot;concatenate&quot;. Th=
ough tokenize is sometimes also used.<br><br>Personally, I&#39;d prefer tha=
t the &quot;split&quot; function return a range that you can iterate over. =
That way, we&#39;re not wasting valuable memory by allocating these things.=
<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/28acb614-af7e-419e-919e-dc4cdfb78999%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28acb614-af7e-419e-919e-dc4cdfb78999=
%40isocpp.org</a>.<br />

------=_Part_496_1738142451.1482518019228--

------=_Part_495_1583199172.1482518019228--

.

------=_Part_576_2086405790.1482529499530
Content-Type: multipart/alternative;
 boundary="----=_Part_577_885145490.1482529499530"

------=_Part_577_885145490.1482529499530
Content-Type: text/plain; charset=UTF-8

Hello Nicol,

You are right, Implode and explode are names coming from PHP

So, I agree with you, talking about join (as in Boost string algorithms, D
and Python) would be clearer than implode and using split will be clearer
than explode too.

Regarding resource consumption, ability to return collection of string_view
may allow to have a reduced memory consumption. I think it's interesting to
have a solution returning an easy to use object with random access operator
(or not if returning a list).

However, having a complementary solution returning an iterator may also be
useful and can save resources in some situation by allowing lazy parsing of
the string.

But I'm not comfortable to specify and propose a demo implementation of
this iterator, if you are confident on that fell free to push it here, I've
never written an iterator.

Thanks for your feedback.

  Laurent

--
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/ea0d6095-9a94-4a5a-aadb-4b7391b9dd9b%40isocpp.org.

------=_Part_577_885145490.1482529499530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello Nicol,</div><div><br></div><div>You are ri=
ght, Implode and explode are names coming from PHP</div><div><br></div><div=
>So, I agree with you, talking about join (as in Boost string algorithms, D=
 and Python) would be clearer than implode and using split will be clearer =
than explode too.</div><div><br></div><div>Regarding resource consumption, =
ability to return collection of string_view may allow to have a reduced mem=
ory consumption. I think it&#39;s interesting to have a solution returning =
an easy to use object with random access operator (or not if returning a li=
st).</div><div><br></div><div>However, having a complementary solution retu=
rning an iterator may also be useful and can save resources in some situati=
on by allowing lazy parsing of the string.</div><div><br></div><div>But I&#=
39;m not comfortable to specify and propose a demo implementation of this i=
terator, if you are confident on that fell free to push it here, I&#39;ve n=
ever written an iterator.</div><div><br></div><div>Thanks for your feedback=
..</div><div><br></div><div>=C2=A0 Laurent</div></div><div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea0d6095-9a94-4a5a-aadb-4b7391b9dd9b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea0d6095-9a94-4a5a-aadb-4b7391b9dd9b=
%40isocpp.org</a>.<br />

------=_Part_577_885145490.1482529499530--

------=_Part_576_2086405790.1482529499530--

.

On Fri, Dec 23, 2016 at 9:33 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Personally, I'd prefer that the "split" function return a range that you can
> iterate over. That way, we're not wasting valuable memory by allocating
> these things.
>
BTW, this is already implemened in boost:
http://www.boost.org/doc/libs/1_62_0/libs/tokenizer/tokenizer.htm

--
Regads,
   Mikhail Maltsev

--
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/CAOqAUTjneuSSayEpJ1evg1L8Hf8oMP01S6KGk0eJNJTLkpDtOw%40mail.gmail.com.

.

------=_Part_355_232735534.1482606542502
Content-Type: multipart/alternative;
 boundary="----=_Part_356_946577847.1482606542503"

------=_Part_356_946577847.1482606542503
Content-Type: text/plain; charset=UTF-8

On Friday, December 23, 2016 at 4:44:59 PM UTC-5, lnal...@gmail.com wrote:
>
> Hello Nicol,
>
> You are right, Implode and explode are names coming from PHP
>
> So, I agree with you, talking about join (as in Boost string algorithms, D
> and Python) would be clearer than implode and using split will be clearer
> than explode too.
>
> Regarding resource consumption, ability to return collection of
> string_view may allow to have a reduced memory consumption. I think it's
> interesting to have a solution returning an easy to use object with random
> access operator (or not if returning a list).
>

std::vector sv(std::split(some_string, "\n"));

This assumes `vector` is upgraded to be constructible from ranges. Note
that this also allows you to use `list`, `deque`, or even `set`, rather
than being forced into using `vector`.

This will also be no less efficient than having `split` return a `vector`.

However, having a complementary solution returning an iterator may also be
> useful and can save resources in some situation by allowing lazy parsing of
> the string.
>

I did not say an iterator; I said a *range*.

--
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/f2d564c0-c43f-4fb1-a9cd-8d9deefb3141%40isocpp.org.

------=_Part_356_946577847.1482606542503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 23, 2016 at 4:44:59 PM UTC-5, lnal...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div>Hello Nicol,</div><div><br></div><div>You are right, Implode a=
nd explode are names coming from PHP</div><div><br></div><div>So, I agree w=
ith you, talking about join (as in Boost string algorithms, D and Python) w=
ould be clearer than implode and using split will be clearer than explode t=
oo.</div><div><br></div><div>Regarding resource consumption, ability to ret=
urn collection of string_view may allow to have a reduced memory consumptio=
n. I think it&#39;s interesting to have a solution returning an easy to use=
 object with random access operator (or not if returning a list).</div></di=
v></div></blockquote><div><br><div style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">vector sv</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">split</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">some_string</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">&quot;\n&quot;</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">));</span></div></code></div><br>This ass=
umes `vector` is upgraded to be constructible from ranges. Note that this a=
lso allows you to use `list`, `deque`, or even `set`, rather than being for=
ced into using `vector`.<br><br>This will also be no less efficient than ha=
ving `split` return a `vector`.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div></div><div>However, having a comp=
lementary solution returning an iterator may also be useful and can save re=
sources in some situation by allowing lazy parsing of the string.</div></di=
v></div></blockquote><div><br>I did not say an iterator; I said a <i>range<=
/i>.<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f2d564c0-c43f-4fb1-a9cd-8d9deefb3141%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2d564c0-c43f-4fb1-a9cd-8d9deefb3141=
%40isocpp.org</a>.<br />

------=_Part_356_946577847.1482606542503--

------=_Part_355_232735534.1482606542502--

.

Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bolas =
escreveu:
> std::vector sv(std::split(some_string, "\n"));
>=20
> This assumes `vector` is upgraded to be constructible from ranges. Note
> that this also allows you to use `list`, `deque`, or even `set`, rather
> than being forced into using `vector`.
>=20
> This will also be no less efficient than having `split` return a `vector`=
..

How?

If std::split returned something other than std::vector<std::string>, then=
=20
that object would have allocated memory that std::vector can't reuse and wo=
uld=20
have to allocate again. So there's an extra memory allocation.

Moreover, the move-construction of the elements may be fast, but it's not=
=20
free, even for nothrow-move-constructible types. It's definitely more compl=
ex=20
than simply moving one std::vector into another.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3442124.REmILjNyMN%40tjmaciei-mobl1.

.

------=_Part_2957_1259555723.1482618475084
Content-Type: multipart/alternative;
 boundary="----=_Part_2958_450126305.1482618475084"

------=_Part_2958_450126305.1482618475084
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 24, 2016 at 4:39:38 PM UTC-5, Thiago Macieira wrote:
>
> Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bola=
s escreveu:=20
> > std::vector sv(std::split(some_string, "\n"));=20
> >=20
> > This assumes `vector` is upgraded to be constructible from ranges. Note=
=20
> > that this also allows you to use `list`, `deque`, or even `set`, rather=
=20
> > than being forced into using `vector`.=20
> >=20
> > This will also be no less efficient than having `split` return a=20
> `vector`.=20
>
> How?=20
>
> If std::split returned something other than std::vector<std::string>, the=
n=20
> that object would have allocated memory that std::vector can't reuse and=
=20
> would=20
> have to allocate again. So there's an extra memory allocation.
>

There's no reason for `split` to allocate memory at all. We want `split`,=
=20
much like `to_chars` and `from_chars`, to be a function that anyone can use=
=20
for this purpose, no matter how constrained their memory situation is.

So it shouldn't be hard-coded to deal in `std::string`s; it should be=20
dealing with `std::string_view`s. So `split` would return a forward range,=
=20
whose `value_type` will be `string_view`.

Therefore, the above code would (through a range-based deduction guide)=20
create a `vector<string_view>`. But one would be equally capable of storing=
=20
it in an `auto` variable and using it directly.

Of course, this also means that using `split` with a temporary string can=
=20
be dangerous. There may be things we can do to fix that. For example, if=20
you provide an rvalue-reference to some container type that is convertible=
=20
to a `string_view`, then the returned range will store a move-constructed=
=20
value of that temporary's type. Thus, the range would own the actual data,=
=20
but still be able to provide `string_view`s into it.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9ffaa22e-3dd6-44cb-a8e4-338cf886cfcd%40isocpp.or=
g.

------=_Part_2958_450126305.1482618475084
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 24, 2016 at 4:39:38 PM UTC-5, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em s=C3=A1bado=
, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bolas escreveu:
<br>&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>&gt;=20
<br>&gt; This assumes `vector` is upgraded to be constructible from ranges.=
 Note
<br>&gt; that this also allows you to use `list`, `deque`, or even `set`, r=
ather
<br>&gt; than being forced into using `vector`.
<br>&gt;=20
<br>&gt; This will also be no less efficient than having `split` return a `=
vector`.
<br>
<br>How?
<br>
<br>If std::split returned something other than std::vector&lt;std::string&=
gt;, then=20
<br>that object would have allocated memory that std::vector can&#39;t reus=
e and would=20
<br>have to allocate again. So there&#39;s an extra memory allocation.<br><=
/blockquote><div><br>There&#39;s no reason for `split` to allocate memory a=
t all. We want `split`, much like `to_chars` and `from_chars`, to be a func=
tion that anyone can use for this purpose, no matter how constrained their =
memory situation is.<br><br>So it shouldn&#39;t be hard-coded to deal in `s=
td::string`s; it should be dealing with `std::string_view`s. So `split` wou=
ld return a forward range, whose `value_type` will be `string_view`.<br><br=
>Therefore, the above code would (through a range-based deduction guide) cr=
eate a `vector&lt;string_view&gt;`. But one would be equally capable of sto=
ring it in an `auto` variable and using it directly.<br><br>Of course, this=
 also means that using `split` with a temporary string can be dangerous. Th=
ere may be things we can do to fix that. For example, if you provide an rva=
lue-reference to some container type that is convertible to a `string_view`=
, then the returned range will store a move-constructed value of that tempo=
rary&#39;s type. Thus, the range would own the actual data, but still be ab=
le to provide `string_view`s into it.<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9ffaa22e-3dd6-44cb-a8e4-338cf886cfcd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ffaa22e-3dd6-44cb-a8e4-338cf886cfcd=
%40isocpp.org</a>.<br />

------=_Part_2958_450126305.1482618475084--

------=_Part_2957_1259555723.1482618475084--

.

------=_Part_474_896567851.1482625144322
Content-Type: multipart/alternative;
 boundary="----=_Part_475_1764430823.1482625144322"

------=_Part_475_1764430823.1482625144322
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about using an output iterator instead?=20

template <class OutputIt>
OutputIt split(string_view str, string_view delim, OutputIt out);

example:
std::vector<std::string> result;
split("foo bar moo", " ", std::back_inserter(result));


Or a unary functor that receives each result/token?

template <class UnaryFunction>
void split(string_view str, string_view delim, UnaryFunction func);


example:
std::vector<std::string> result;
split(" foo bar moo", " ", [&](auto token) { result.push_back(token); });


Den l=C3=B6rdag 24 december 2016 kl. 22:27:55 UTC skrev Nicol Bolas:
>
> On Saturday, December 24, 2016 at 4:39:38 PM UTC-5, Thiago Macieira wrote=
:
>>
>> Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bol=
as=20
>> escreveu:=20
>> > std::vector sv(std::split(some_string, "\n"));=20
>> >=20
>> > This assumes `vector` is upgraded to be constructible from ranges. Not=
e=20
>> > that this also allows you to use `list`, `deque`, or even `set`, rathe=
r=20
>> > than being forced into using `vector`.=20
>> >=20
>> > This will also be no less efficient than having `split` return a=20
>> `vector`.=20
>>
>> How?=20
>>
>> If std::split returned something other than std::vector<std::string>,=20
>> then=20
>> that object would have allocated memory that std::vector can't reuse and=
=20
>> would=20
>> have to allocate again. So there's an extra memory allocation.
>>
>
> There's no reason for `split` to allocate memory at all. We want `split`,=
=20
> much like `to_chars` and `from_chars`, to be a function that anyone can u=
se=20
> for this purpose, no matter how constrained their memory situation is.
>
> So it shouldn't be hard-coded to deal in `std::string`s; it should be=20
> dealing with `std::string_view`s. So `split` would return a forward range=
,=20
> whose `value_type` will be `string_view`.
>
> Therefore, the above code would (through a range-based deduction guide)=
=20
> create a `vector<string_view>`. But one would be equally capable of stori=
ng=20
> it in an `auto` variable and using it directly.
>
> Of course, this also means that using `split` with a temporary string can=
=20
> be dangerous. There may be things we can do to fix that. For example, if=
=20
> you provide an rvalue-reference to some container type that is convertibl=
e=20
> to a `string_view`, then the returned range will store a move-constructed=
=20
> value of that temporary's type. Thus, the range would own the actual data=
,=20
> but still be able to provide `string_view`s into it.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9ad22dbd-3d37-44e7-9a23-f557b068d91f%40isocpp.or=
g.

------=_Part_475_1764430823.1482625144322
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How about using an output iterator instead?=C2=A0<div><br>=
</div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">OutputIt</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">OutputIt</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> split</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">string_view str</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> string_view delim</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Out=
putIt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">out</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>example</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">string</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>split</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">&quot;foo bar moo&quot;=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&quot; &quot;</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">back_inserter</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">result</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">));</span></div></code></div><div><br><br></div><div>Or a =
unary functor that receives each result/token?</div><div><br></div><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">UnaryFunction</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> split</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">stri=
ng_view str</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_=
view delim</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">UnaryFunction</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>example</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">string</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>split</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&quot; foo bar moo&qu=
ot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">&quot; &quot;</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">[&amp;](</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> token</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> re=
sult</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">push_back</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">token</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">});</span></div></code></div><div><br></div><=
div><br>Den l=C3=B6rdag 24 december 2016 kl. 22:27:55 UTC skrev Nicol Bolas=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday,=
 December 24, 2016 at 4:39:38 PM UTC-5, Thiago Macieira wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s =
11:09:02 BRST, Nicol Bolas escreveu:
<br>&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>&gt;=20
<br>&gt; This assumes `vector` is upgraded to be constructible from ranges.=
 Note
<br>&gt; that this also allows you to use `list`, `deque`, or even `set`, r=
ather
<br>&gt; than being forced into using `vector`.
<br>&gt;=20
<br>&gt; This will also be no less efficient than having `split` return a `=
vector`.
<br>
<br>How?
<br>
<br>If std::split returned something other than std::vector&lt;std::string&=
gt;, then=20
<br>that object would have allocated memory that std::vector can&#39;t reus=
e and would=20
<br>have to allocate again. So there&#39;s an extra memory allocation.<br><=
/blockquote><div><br>There&#39;s no reason for `split` to allocate memory a=
t all. We want `split`, much like `to_chars` and `from_chars`, to be a func=
tion that anyone can use for this purpose, no matter how constrained their =
memory situation is.<br><br>So it shouldn&#39;t be hard-coded to deal in `s=
td::string`s; it should be dealing with `std::string_view`s. So `split` wou=
ld return a forward range, whose `value_type` will be `string_view`.<br><br=
>Therefore, the above code would (through a range-based deduction guide) cr=
eate a `vector&lt;string_view&gt;`. But one would be equally capable of sto=
ring it in an `auto` variable and using it directly.<br><br>Of course, this=
 also means that using `split` with a temporary string can be dangerous. Th=
ere may be things we can do to fix that. For example, if you provide an rva=
lue-reference to some container type that is convertible to a `string_view`=
, then the returned range will store a move-constructed value of that tempo=
rary&#39;s type. Thus, the range would own the actual data, but still be ab=
le to provide `string_view`s into it.<br></div></div></blockquote></div></d=
iv>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9ad22dbd-3d37-44e7-9a23-f557b068d91f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ad22dbd-3d37-44e7-9a23-f557b068d91f=
%40isocpp.org</a>.<br />

------=_Part_475_1764430823.1482625144322--

------=_Part_474_896567851.1482625144322--

.

------=_Part_1755_740632924.1482627174687
Content-Type: multipart/alternative;
 boundary="----=_Part_1756_2112698777.1482627174688"

------=_Part_1756_2112698777.1482627174688
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 24, 2016 at 1:39:38 PM UTC-8, Thiago Macieira wrote:
>
> Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bola=
s escreveu:=20
> > std::vector sv(std::split(some_string, "\n"));=20
> >=20
> > This assumes `vector` is upgraded to be constructible from ranges. Note=
=20
> > that this also allows you to use `list`, `deque`, or even `set`, rather=
=20
> > than being forced into using `vector`.=20
> >=20
> > This will also be no less efficient than having `split` return a=20
> `vector`.=20
>
> How?=20
>
> If std::split returned something other than std::vector<std::string>, the=
n=20
> that object would have allocated memory that std::vector can't reuse and=
=20
> would=20
> have to allocate again. So there's an extra memory allocation.=20
>

There is absolutely zero reason for the type 'vector' to be anywhere near=
=20
the string split or join interfaces. Let's look at split for example:

The split function can return a "generator" type range that calculates the=
=20
splits on demand, requires no heap allocation itself, and can be unpacked=
=20
efficiently into any container or only be partially consumed or passed into=
=20
a mutator or whatever. Right now today that would be done by having split=
=20
return an Input_iterator, but with the facilities provided by the Ranges TS=
=20
that would turn into a Input_range or even a type-erased generator.

In today's C++17:

    auto split(string_view source, string_view separator) ->=20
string_split_iterator; // return an Input_iterator

    vector(split("foo bar baz", " ").as_iterator(),=20
string_split_iterator()); // not the most elegant syntax, but can be made=
=20
to work without changing vector

and it can be taken a bit further with slightly more sophisticated library=
=20
bits to add real ranges and generators (aka "input ranges") with C++20 or=
=20
Ranges TS:

    auto split(string_view source, string_view separator) ->=20
generator<string_view>; // type-erased "generator" with SBO to avoid heap=
=20
allocations
    auto split(string_view source, string_view separator) ->=20
string_split_generator; // without type-erasure, if you prefer it ever so=
=20
slightly faster

    vector(split("foo bar baz")); // even better once vector supports=20
ranges TS, or if you have your own STL/vector you can modify today

And of course, this proposal is impossible to land for C++17 at this point,=
=20
so there's approximately zero reasons to not target the C++20 timeframe's=
=20
expected language and library features.

Moreover, the move-construction of the elements may be fast, but it's not=
=20
> free, even for nothrow-move-constructible types. It's definitely more=20
> complex=20
> than simply moving one std::vector into another.
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b885cf70-b39f-4c7c-b35f-719cdbebe6bf%40isocpp.or=
g.

------=_Part_1756_2112698777.1482627174688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 24, 2016 at 1:39:38 PM UTC-8, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em s=C3=A1bado=
, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bolas escreveu:
<br>&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>&gt;=20
<br>&gt; This assumes `vector` is upgraded to be constructible from ranges.=
 Note
<br>&gt; that this also allows you to use `list`, `deque`, or even `set`, r=
ather
<br>&gt; than being forced into using `vector`.
<br>&gt;=20
<br>&gt; This will also be no less efficient than having `split` return a `=
vector`.
<br>
<br>How?
<br>
<br>If std::split returned something other than std::vector&lt;std::string&=
gt;, then=20
<br>that object would have allocated memory that std::vector can&#39;t reus=
e and would=20
<br>have to allocate again. So there&#39;s an extra memory allocation.
<br></blockquote><div><br></div><div>There is absolutely zero reason for th=
e type &#39;vector&#39; to be anywhere near the string split or join interf=
aces. Let&#39;s look at split for example:</div><div><br></div><div>The spl=
it function can return a &quot;generator&quot; type range that calculates t=
he splits on demand, requires no heap allocation itself, and can be unpacke=
d efficiently into any container or only be partially consumed or passed in=
to a mutator or whatever. Right now today that would be done by having spli=
t return an Input_iterator, but with the facilities provided by the Ranges =
TS that would turn into a Input_range or even a type-erased generator.</div=
><div><br></div><div>In today&#39;s C++17:</div><div><br></div><div>=C2=A0 =
=C2=A0 auto split(string_view source, string_view separator) -&gt; string_s=
plit_iterator; // return an Input_iterator<br></div><div><br></div><div>=C2=
=A0 =C2=A0 vector(split(&quot;foo bar baz&quot;, &quot; &quot;).as_iterator=
(), string_split_iterator()); // not the most elegant syntax, but can be ma=
de to work without changing vector<br></div><div><br></div><div>and it can =
be taken a bit further with slightly more sophisticated library bits to add=
 real ranges and generators (aka &quot;input ranges&quot;) with C++20 or Ra=
nges TS:</div><div><br></div><div>=C2=A0 =C2=A0 auto split(string_view sour=
ce, string_view separator) -&gt; generator&lt;string_view&gt;; // type-eras=
ed &quot;generator&quot; with SBO to avoid heap allocations</div><div>=C2=
=A0 =C2=A0 auto split(string_view source, string_view separator) -&gt; stri=
ng_split_generator; // without type-erasure, if you prefer it ever so sligh=
tly faster<br></div><div><br></div><div>=C2=A0 =C2=A0 vector(split(&quot;fo=
o bar baz&quot;)); // even better once vector supports ranges TS, or if you=
 have your own STL/vector you can modify today<br></div><div><br></div><div=
>And of course, this proposal is impossible to land for C++17 at this point=
, so there&#39;s approximately zero reasons to not target the C++20 timefra=
me&#39;s expected language and library features.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Moreover, the move-construction of t=
he elements may be fast, but it&#39;s not=20
<br>free, even for nothrow-move-constructible types. It&#39;s definitely mo=
re complex=20
<br>than simply moving one std::vector into another.<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b885cf70-b39f-4c7c-b35f-719cdbebe6bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b885cf70-b39f-4c7c-b35f-719cdbebe6bf=
%40isocpp.org</a>.<br />

------=_Part_1756_2112698777.1482627174688--

------=_Part_1755_740632924.1482627174687--

.

------=_Part_606_2095915703.1482633096160
Content-Type: multipart/alternative;
 boundary="----=_Part_607_88454975.1482633096161"

------=_Part_607_88454975.1482633096161
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 24, 2016 at 7:52:54 PM UTC-5, Sean Middleditch wrote:
>
> On Saturday, December 24, 2016 at 1:39:38 PM UTC-8, Thiago Macieira wrote=
:
>>
>> Em s=C3=A1bado, 24 de dezembro de 2016, =C3=A0s 11:09:02 BRST, Nicol Bol=
as=20
>> escreveu:=20
>> > std::vector sv(std::split(some_string, "\n"));=20
>> >=20
>> > This assumes `vector` is upgraded to be constructible from ranges. Not=
e=20
>> > that this also allows you to use `list`, `deque`, or even `set`, rathe=
r=20
>> > than being forced into using `vector`.=20
>> >=20
>> > This will also be no less efficient than having `split` return a=20
>> `vector`.=20
>>
>> How?=20
>>
>> If std::split returned something other than std::vector<std::string>,=20
>> then=20
>> that object would have allocated memory that std::vector can't reuse and=
=20
>> would=20
>> have to allocate again. So there's an extra memory allocation.=20
>>
>
> There is absolutely zero reason for the type 'vector' to be anywhere near=
=20
> the string split or join interfaces. Let's look at split for example:
>
> The split function can return a "generator" type range that calculates th=
e=20
> splits on demand, requires no heap allocation itself, and can be unpacked=
=20
> efficiently into any container or only be partially consumed or passed in=
to=20
> a mutator or whatever. Right now today that would be done by having split=
=20
> return an Input_iterator, but with the facilities provided by the Ranges =
TS=20
> that would turn into a Input_range or even a type-erased generator.
>
> In today's C++17:
>
>     auto split(string_view source, string_view separator) ->=20
> string_split_iterator; // return an Input_iterator
>
>     vector(split("foo bar baz", " ").as_iterator(),=20
> string_split_iterator()); // not the most elegant syntax, but can be made=
=20
> to work without changing vector
>
> and it can be taken a bit further with slightly more sophisticated librar=
y=20
> bits to add real ranges and generators (aka "input ranges") with C++20 or=
=20
> Ranges TS:
>
>     auto split(string_view source, string_view separator) ->=20
> generator<string_view>; // type-erased "generator" with SBO to avoid heap=
=20
> allocations
>     auto split(string_view source, string_view separator) ->=20
> string_split_generator; // without type-erasure, if you prefer it ever so=
=20
> slightly faster
>
>     vector(split("foo bar baz")); // even better once vector supports=20
> ranges TS, or if you have your own STL/vector you can modify today
>
> And of course, this proposal is impossible to land for C++17 at this=20
> point, so there's approximately zero reasons to not target the C++20=20
> timeframe's expected language and library features.
>

The main reason I would prefer a range to a generator is that we would=20
likely not give containers generator-based constructors and insertion=20
interfaces, while we would almost certainly give expand the existing=20
dual-iterator constructors/insertion functions with Range-TS-style ranges.

Then again, I would hope that whatever `generator` type we come up with=20
would also fit the definition of an InputRange. Or at the very least, we=20
could have some kind of generic generator-to-range adapter.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7c8dd6be-c8ab-4697-9705-c45d4c59c28c%40isocpp.or=
g.

------=_Part_607_88454975.1482633096161
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 24, 2016 at 7:52:54 PM UTC-5, Sean M=
iddleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Saturday, December 24, 2016 at 1:39:38 PM UTC-8, Thiago Macieira wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Em s=C3=A1bado, 24 de dezembro d=
e 2016, =C3=A0s 11:09:02 BRST, Nicol Bolas escreveu:
<br>&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>&gt;=20
<br>&gt; This assumes `vector` is upgraded to be constructible from ranges.=
 Note
<br>&gt; that this also allows you to use `list`, `deque`, or even `set`, r=
ather
<br>&gt; than being forced into using `vector`.
<br>&gt;=20
<br>&gt; This will also be no less efficient than having `split` return a `=
vector`.
<br>
<br>How?
<br>
<br>If std::split returned something other than std::vector&lt;std::string&=
gt;, then=20
<br>that object would have allocated memory that std::vector can&#39;t reus=
e and would=20
<br>have to allocate again. So there&#39;s an extra memory allocation.
<br></blockquote><div><br></div><div>There is absolutely zero reason for th=
e type &#39;vector&#39; to be anywhere near the string split or join interf=
aces. Let&#39;s look at split for example:</div><div><br></div><div>The spl=
it function can return a &quot;generator&quot; type range that calculates t=
he splits on demand, requires no heap allocation itself, and can be unpacke=
d efficiently into any container or only be partially consumed or passed in=
to a mutator or whatever. Right now today that would be done by having spli=
t return an Input_iterator, but with the facilities provided by the Ranges =
TS that would turn into a Input_range or even a type-erased generator.</div=
><div><br></div><div>In today&#39;s C++17:</div><div><br></div><div>=C2=A0 =
=C2=A0 auto split(string_view source, string_view separator) -&gt; string_s=
plit_iterator; // return an Input_iterator<br></div><div><br></div><div>=C2=
=A0 =C2=A0 vector(split(&quot;foo bar baz&quot;, &quot; &quot;).as_iterator=
(), string_split_iterator()); // not the most elegant syntax, but can be ma=
de to work without changing vector<br></div><div><br></div><div>and it can =
be taken a bit further with slightly more sophisticated library bits to add=
 real ranges and generators (aka &quot;input ranges&quot;) with C++20 or Ra=
nges TS:</div><div><br></div><div>=C2=A0 =C2=A0 auto split(string_view sour=
ce, string_view separator) -&gt; generator&lt;string_view&gt;; // type-eras=
ed &quot;generator&quot; with SBO to avoid heap allocations</div><div>=C2=
=A0 =C2=A0 auto split(string_view source, string_view separator) -&gt; stri=
ng_split_generator; // without type-erasure, if you prefer it ever so sligh=
tly faster<br></div><div><br></div><div>=C2=A0 =C2=A0 vector(split(&quot;fo=
o bar baz&quot;)); // even better once vector supports ranges TS, or if you=
 have your own STL/vector you can modify today<br></div><div><br></div><div=
>And of course, this proposal is impossible to land for C++17 at this point=
, so there&#39;s approximately zero reasons to not target the C++20 timefra=
me&#39;s expected language and library features.</div></div></blockquote><d=
iv><br>The main reason I would prefer a range to a generator is that we wou=
ld likely not give containers generator-based constructors and insertion in=
terfaces, while we would almost certainly give expand the existing dual-ite=
rator constructors/insertion functions with Range-TS-style ranges.<br><br>T=
hen again, I would hope that whatever `generator` type we come up with woul=
d also fit the definition of an InputRange. Or at the very least, we could =
have some kind of generic generator-to-range adapter.</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7c8dd6be-c8ab-4697-9705-c45d4c59c28c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7c8dd6be-c8ab-4697-9705-c45d4c59c28c=
%40isocpp.org</a>.<br />

------=_Part_607_88454975.1482633096161--

------=_Part_606_2095915703.1482633096160--

.

------=_Part_480_759541459.1482633359162
Content-Type: multipart/alternative;
 boundary="----=_Part_481_477216909.1482633359163"

------=_Part_481_477216909.1482633359163
Content-Type: text/plain; charset=UTF-8

On Saturday, December 24, 2016 at 7:19:04 PM UTC-5, richard...@outlook.com
wrote:
>
> How about using an output iterator instead?
>
> template <class OutputIt>
> OutputIt split(string_view str, string_view delim, OutputIt out);
>
> example:
> std::vector<std::string> result;
> split("foo bar moo", " ", std::back_inserter(result));
>
>
And what if you want to iterate over each split, doing arbitrary
processing? Wouldn't it make sense to do this:

for(auto sv : split("foo bar moo", " "))
{
}

Your way can't do that. I much prefer returning a proper range; we have
lots of facilities that can work directly with ranges, and we'll only be
getting more in the future.

--
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/321f8bfd-8eae-46e5-8677-0134b91da41a%40isocpp.org.

------=_Part_481_477216909.1482633359163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 24, 2016 at 7:19:04 PM UTC-5, richar=
d...@outlook.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">How about using an output iterator instead?=C2=A0<div><br></div><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><spa=
n style=3D"color:#008">template</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">OutputIt</spa=
n><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#606">OutputIt</span><span style=3D"color:#000"> sp=
lit</span><span style=3D"color:#660">(</span><span style=3D"color:#000">str=
ing_view str</span><span style=3D"color:#660">,</span><span style=3D"color:=
#000"> string_view delim</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">OutputIt</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">out</span><span styl=
e=3D"color:#660">);</span><span style=3D"color:#000"><br><br>example</span>=
<span style=3D"color:#660">:</span><span style=3D"color:#000"><br>std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">vector</spa=
n><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#008">string</sp=
an><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> result=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>sp=
lit</span><span style=3D"color:#660">(</span><span style=3D"color:#080">&qu=
ot;foo bar moo&quot;</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#080">&quot; &quot;</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">back_inserter</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">result</spa=
n><span style=3D"color:#660">));</span></div></code></div><div><br></div></=
div></blockquote><div><br>And what if you want to iterate over each split, =
doing arbitrary processing? Wouldn&#39;t it make sense to do this:<br><br><=
div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word=
;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> sv </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> split</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">&quot;foo bar moo&quot;</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">&quot; &quot;</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div><=
/code></div><br>Your way can&#39;t do that. I much prefer returning a prope=
r range; we have lots of facilities that can work directly with ranges, and=
 we&#39;ll only be getting more in the future.<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/321f8bfd-8eae-46e5-8677-0134b91da41a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/321f8bfd-8eae-46e5-8677-0134b91da41a=
%40isocpp.org</a>.<br />

------=_Part_481_477216909.1482633359163--

------=_Part_480_759541459.1482633359162--

.

On Fri, Dec 23, 2016 at 10:33:39AM -0800, Nicol Bolas wrote:
> On Friday, December 23, 2016 at 1:17:03 PM UTC-5, lnal...@gmail.com wrote=
:
> >
> > Hello,
> > For a long time I found it misses a simple solution to implode/explode =
a=20
> > string in a collection.
> > There=E2=80=99s solution in boost with split/join but it=E2=80=99s pret=
ty heavy just to=20
> > paste some string.
> > I suggest adding on 'basic_string' and 'basic_stringview' an 'explode'=
=20
> > method
> > And on 'basic_string' a static 'implode' method.
> >
>=20
> Um... maybe you should explain what "implode" and "explode" are supposed =
to *actually=20
> do*. I have seen many versions of both of these methods, and I've never=
=20
> heard them referred to with those names. Google suggests that it's a PHP=
=20
> thing, which is yet another reason *not* to use these names.
>=20
> Typically, it's "split" and "concatenate". Though tokenize is sometimes=
=20
> also used.

I think "concatenate" already is provided by the standard library under the
name "std::accumulate".

/MF

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161225083947.GA1808%40noemi.

.

------=_Part_749_2053911664.1482679202448
Content-Type: multipart/alternative;
 boundary="----=_Part_750_228742239.1482679202449"

------=_Part_750_228742239.1482679202449
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, December 25, 2016 at 3:39:52 AM UTC-5, Magnus Fromreide wrote:
>
> On Fri, Dec 23, 2016 at 10:33:39AM -0800, Nicol Bolas wrote:=20
> > On Friday, December 23, 2016 at 1:17:03 PM UTC-5, lnal...@gmail.com=20
> wrote:=20
> > >=20
> > > Hello,=20
> > > For a long time I found it misses a simple solution to implode/explod=
e=20
> a=20
> > > string in a collection.=20
> > > There=E2=80=99s solution in boost with split/join but it=E2=80=99s pr=
etty heavy just=20
> to=20
> > > paste some string.=20
> > > I suggest adding on 'basic_string' and 'basic_stringview' an 'explode=
'=20
> > > method=20
> > > And on 'basic_string' a static 'implode' method.=20
> > >=20
> >=20
> > Um... maybe you should explain what "implode" and "explode" are suppose=
d=20
> to *actually=20
> > do*. I have seen many versions of both of these methods, and I've never=
=20
> > heard them referred to with those names. Google suggests that it's a PH=
P=20
> > thing, which is yet another reason *not* to use these names.=20
> >=20
> > Typically, it's "split" and "concatenate". Though tokenize is sometimes=
=20
> > also used.=20
>
> I think "concatenate" already is provided by the standard library under=
=20
> the=20
> name "std::accumulate".=20
>

String concatenation functions usually allow you to supply a string that=20
goes between the combined elements. `accumulate` can't do that. Or at=20
least, not without making the call exceedingly obtuse:

accumulate(begin, end, std::string(),
  [middle](const string_view &accum, const string_view &s2)=20
  {
    if(accum.empty())
      return std::string(s2);
    return std::string(accum) + middle + s2;
  }
)

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2b7440b6-43d5-488a-94ee-7151a2b515d9%40isocpp.or=
g.

------=_Part_750_228742239.1482679202449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, December 25, 2016 at 3:39:52 AM UTC-5, Magnus F=
romreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Dec 23,=
 2016 at 10:33:39AM -0800, Nicol Bolas wrote:
<br>&gt; On Friday, December 23, 2016 at 1:17:03 PM UTC-5, <a>lnal...@gmail=
..com</a> wrote:
<br>&gt; &gt;
<br>&gt; &gt; Hello,
<br>&gt; &gt; For a long time I found it misses a simple solution to implod=
e/explode a=20
<br>&gt; &gt; string in a collection.
<br>&gt; &gt; There=E2=80=99s solution in boost with split/join but it=E2=
=80=99s pretty heavy just to=20
<br>&gt; &gt; paste some string.
<br>&gt; &gt; I suggest adding on &#39;basic_string&#39; and &#39;basic_str=
ingview&#39; an &#39;explode&#39;=20
<br>&gt; &gt; method
<br>&gt; &gt; And on &#39;basic_string&#39; a static &#39;implode&#39; meth=
od.
<br>&gt; &gt;
<br>&gt;=20
<br>&gt; Um... maybe you should explain what &quot;implode&quot; and &quot;=
explode&quot; are supposed to *actually=20
<br>&gt; do*. I have seen many versions of both of these methods, and I&#39=
;ve never=20
<br>&gt; heard them referred to with those names. Google suggests that it&#=
39;s a PHP=20
<br>&gt; thing, which is yet another reason *not* to use these names.
<br>&gt;=20
<br>&gt; Typically, it&#39;s &quot;split&quot; and &quot;concatenate&quot;.=
 Though tokenize is sometimes=20
<br>&gt; also used.
<br>
<br>I think &quot;concatenate&quot; already is provided by the standard lib=
rary under the
<br>name &quot;std::accumulate&quot;.
<br></blockquote><div><br>String concatenation functions usually allow you =
to supply a string that goes between the combined elements. `accumulate` ca=
n&#39;t do that. Or at least, not without making the call exceedingly obtus=
e:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-color:=
 rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap:=
 break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">accumulate</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">begin<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">end</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">string</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mi=
ddle</span><span style=3D"color: #660;" class=3D"styled-by-prettify">](</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> string_view </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">accum</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> string_view </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">s2</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> <br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">accum</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">empty</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">s2</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
string</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">accum</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> middle </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> s2</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div></div><br></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b7440b6-43d5-488a-94ee-7151a2b515d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b7440b6-43d5-488a-94ee-7151a2b515d9=
%40isocpp.org</a>.<br />

------=_Part_750_228742239.1482679202449--

------=_Part_749_2053911664.1482679202448--

.

------=_Part_797_849164152.1482745689738
Content-Type: multipart/alternative;
 boundary="----=_Part_798_2007890877.1482745689738"

------=_Part_798_2007890877.1482745689738
Content-Type: text/plain; charset=UTF-8

Hello ,

Nicol I was seduced by your proposal, as it looks pretty simple to use, and
it's my goal in this proposal.

So I've started an implementation in order to have a Proof Of Concept (POC)
However I met some restriction, as I haven't a C++17 compiler supporting
range (only VS2017RC or older GCC/Clang on Linux which doesn't support C++
17) and I've never written an iterator and I don't know well range (sorry,
I do my best, but together we should be able to find the best option).

Moreover I've started to implement a tokenizer (inspired by the boost one)
available here
https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/testcpp17_2.cpp

My understanding of your proposal is to have a split function returning a
range that is in fact a magic container for 2 iterators coming from string
tokenizer.

I understood that this code should be efficient
string MyStr("my,csv,line")
vector<string_view>  MyResult(split(MyStr, ","));
But I fear the result of the underlaying derefenrencing of the string
tokenizer was a string and not a string_view causing a significant overhead.
So a workaround for that may be
vector<string_view> MyResult(split(string_view(MyStr), ","));
but it's a bit heavier than
auto MyResult=MyStr.splitsv(" ");
You argue, "Having a `split` function that can only be used with the
standard library string types is pathetic", if for the same price with can
handle any string type I agree. But, when I try to implement my demo
tokenizer to have it working with string & string_view, I already met an
issue on the dereference operator to extract the substring.
string_type operator *()
{
  //return string_type(it,next_it); // This one may not work with
string_view as there's no constructor taking 2 string_view iterator.
  return tok.src.substr(it - tok.src.begin(), next_it - it);
}
I initially try to construct the substring with 2 iterators, but
string_view doesn't have such a constructor so I've used substr(). But
there's no guarantee that others string class (or char*) implemented any of
theses options.
So I fear that having a split function running on any non-std string class
is quite hypothetical. However they can always pass through
char*=>string_view .

After this first try of POC, my feeling is that split function returning
range will be a bit complex to implement and induce object (tokenizer,
range) that are overhead when the purpose is to be stored in a vector.
In the other hand, more dedicated method like splitsv could be optimized to
reserve the vector with an initial parsing of the input string.

Then perhaps you can propose a better proof of concept than mine (an entire
one with range) (we can put it on my github if you wish)

At the same time I've worked on the other alternative with method (and
perhaps having both is the best option)

I've simulated with inheritance, you can see it here
https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/testcpp17_1.cpp

Regarding fonctor version we can imagine having a splitf but we have to
define how the called function will be.
Unary with always string_view ? (There's no risk the SV was invalid )

binary with iterator + length ?
Or CharT* + length ? More C oriented but perhaps easier to use .

Thanks to everyone for your feedback and contribution.

 Laurent


--
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/5cc2d49c-4f7a-407f-9bae-c12e9c06a0e0%40isocpp.org.

------=_Part_798_2007890877.1482745689738
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello ,</div><div><br></div><div>Nicol I was seduced =
by your proposal, as it looks pretty simple to use, and it&#39;s my goal in=
 this proposal.</div><div><br></div><div>So I&#39;ve started an implementat=
ion in order to have a Proof Of Concept (POC)</div><div>However I met some =
restriction, as I haven&#39;t a C++17 compiler supporting range (only VS201=
7RC or older GCC/Clang on Linux which doesn&#39;t support C++ 17) and I&#39=
;ve never written an iterator and I don&#39;t know well range (sorry, I do =
my best, but together we should be able to find the best option).<br></div>=
<div><br></div><div>Moreover I&#39;ve started to implement a tokenizer (ins=
pired by the boost one) available here</div><div><a href=3D"https://github.=
com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/testcpp17_2.cpp=
">https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_=
2/testcpp17_2.cpp</a><br></div><div><br></div><div>My understanding of your=
 proposal is to have a split function returning a range that is in fact a m=
agic container for 2 iterators coming from string tokenizer.</div><div><br>=
</div><div>I understood that this code should be efficient</div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">MyStr</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">&quot;my,csv,line&quot;</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>vector</span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">&lt;string_view&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">MyResult</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">split</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">MyStr</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;,&quot=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span=
></div></code></div><div>But I fear the result of the underlaying derefenre=
ncing of the string tokenizer was a string and not a string_view causing a =
significant overhead.<br></div><div>So a workaround for that may be<br></di=
v><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">vecto=
r</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;strin=
g_view&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">MyResult<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">split</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">string_view</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">MyStr</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">&quot;,&quot;</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">));</span></div></code></div></div><div>but it&#39;s a bit he=
avier than=C2=A0<br></div><div><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">MyResult</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #606;" class=3D"styled-by-prettify">MyStr=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">splitsv</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">&quot; &quot;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
</div><div>You argue, &quot;Having a `split` function that can only be used=
 with the standard library string types is pathetic&quot;, if for the same =
price with can handle any string type I agree. But, when I try to implement=
 my demo tokenizer to have it working with string &amp; string_view, I alre=
ady met an issue on the dereference operator to extract the substring.<br><=
/div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">string_=
type </span><span style=3D"color: #008;" class=3D"styled-by-prettify">opera=
tor</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*()</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//return string_type(it,next_it); //=
 This one may not work with string_view as there&#39;s no constructor takin=
g 2 string_view iterator.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> tok</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">src=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">substr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">it </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> tok</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">src</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">begi=
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> next_it </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">-</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> it</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><div>I initially try to co=
nstruct the substring with 2 iterators, but string_view doesn&#39;t have su=
ch a constructor so I&#39;ve used substr(). But there&#39;s no guarantee th=
at others string class (or char*) implemented any of theses options.=C2=A0<=
/div><div>So I fear that having a split function running on any non-std str=
ing class is quite hypothetical. However they can always pass through char*=
=3D&gt;string_view .<br></div><div><br></div><div>After this first try of P=
OC, my feeling is that split function returning range will be a bit complex=
 to implement and induce object (tokenizer, range) that are overhead when t=
he purpose is to be stored in a vector.</div><div>In the other hand, more d=
edicated method like splitsv could be optimized to reserve the vector with =
an initial parsing of the input string.<br></div><div><br></div><div>Then p=
erhaps you can propose a better proof of concept than mine (an entire one w=
ith range) (we can put it on my github if you wish)</div><div><br></div><di=
v>At the same time I&#39;ve worked on the other alternative with method (an=
d perhaps having both is the best option)=C2=A0</div><div><br></div><div>I&=
#39;ve simulated with inheritance, you can see it here<br></div><div><a hre=
f=3D"https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp=
17_1/testcpp17_1.cpp">https://github.com/laurent-n/cpp17_implode_explode/bl=
ob/master/testcpp17_1/testcpp17_1.cpp</a><br></div><div><br></div><div>Rega=
rding fonctor version we can imagine having a splitf but we have to define =
how the called function will be.</div><div>Unary with always string_view ? =
(There&#39;s no risk the SV was invalid )<br></div><div><br></div><div>bina=
ry with iterator + length ?=C2=A0</div><div>Or CharT* + length ? More C ori=
ented but perhaps easier to use .<br></div><div><br></div><div><div>Thanks =
to everyone for your feedback and contribution.</div><div><br></div><div>=
=C2=A0Laurent</div></div><div><br></div><div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cc2d49c-4f7a-407f-9bae-c12e9c06a0e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cc2d49c-4f7a-407f-9bae-c12e9c06a0e0=
%40isocpp.org</a>.<br />

------=_Part_798_2007890877.1482745689738--

------=_Part_797_849164152.1482745689738--

.

------=_Part_1202_1790190213.1482909399823
Content-Type: multipart/alternative;
 boundary="----=_Part_1203_152307372.1482909399823"

------=_Part_1203_152307372.1482909399823
Content-Type: text/plain; charset=UTF-8

Hello,

I've summarized our discussion in a formal proposal here
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_proposal.html

Please provide feedback to amend it and contribute to select the best
options.

Thanks,
  Laurent

--
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/bac1bae1-dc8d-4a57-b699-2d9c1fb22050%40isocpp.org.

------=_Part_1203_152307372.1482909399823
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I&#39;ve summarized our discussi=
on in a formal proposal here</div><div><a href=3D"http://htmlpreview.github=
..io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp=
17_1/formal_proposal.html">http://htmlpreview.github.io/?https://github.com=
/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_proposal.ht=
ml</a><br></div><div><br></div><div>Please provide feedback to amend it and=
 contribute to select the best options.</div><div><br></div><div>Thanks,</d=
iv><div>=C2=A0 Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bac1bae1-dc8d-4a57-b699-2d9c1fb22050%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bac1bae1-dc8d-4a57-b699-2d9c1fb22050=
%40isocpp.org</a>.<br />

------=_Part_1203_152307372.1482909399823--

------=_Part_1202_1790190213.1482909399823--

.

------=_Part_1112_1528433714.1482915614947
Content-Type: multipart/alternative;
 boundary="----=_Part_1113_50635096.1482915614947"

------=_Part_1113_50635096.1482915614947
Content-Type: text/plain; charset=UTF-8

Op woensdag 28 december 2016 08:16:40 UTC+1 schreef lnal...@gmail.com:
>
> I've summarized our discussion in a formal proposal here
>
> http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_proposal.html
>
> Should the separator argument be first or last?
As it's usually much shorter then the other argument having it first might
make it easier to read.

--
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/2c491335-ce45-4069-80f9-7e8d6f863eb6%40isocpp.org.

------=_Part_1113_50635096.1482915614947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op woensdag 28 december 2016 08:16:40 UTC+1 schreef lnal..=
..@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>I&#39;ve summarized our discussion in a formal proposal here</div><div>=
<a href=3D"http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17=
_implode_explode/blob/master/testcpp17_1/formal_proposal.html" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.com=
%2Flaurent-n%2Fcpp17_implode_explode%2Fblob%2Fmaster%2Ftestcpp17_1%2Fformal=
_proposal.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFpDT2sBqGr11VGsi_Hhj=
BKWnP-8Q&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.co=
m%2Flaurent-n%2Fcpp17_implode_explode%2Fblob%2Fmaster%2Ftestcpp17_1%2Fforma=
l_proposal.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFpDT2sBqGr11VGsi_Hh=
jBKWnP-8Q&#39;;return true;">http://htmlpreview.github.io/?<wbr>https://git=
hub.com/laurent-n/<wbr>cpp17_implode_explode/blob/<wbr>master/testcpp17_1/f=
ormal_<wbr>proposal.html</a><br></div><div><br></div></div></blockquote><di=
v>Should the separator argument be first or last?</div><div>As it&#39;s usu=
ally much shorter then the other argument having it first might make it eas=
ier to read.=C2=A0</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c491335-ce45-4069-80f9-7e8d6f863eb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c491335-ce45-4069-80f9-7e8d6f863eb6=
%40isocpp.org</a>.<br />

------=_Part_1113_50635096.1482915614947--

------=_Part_1112_1528433714.1482915614947--

.

--f403045ea47a84cb0e0544b51c33
Content-Type: text/plain; charset=UTF-8

Hello Olaf,

I suppose you are talking about static join ?

Yes, it could make sense
it's the case in PHP , C#, Java
But not in Go, Rust, boost::algorithm::join

Python has a different logic as the separator is the "caller" object (like
2nd join option)

Having separator as 2nd parameters would allow have it optional with "".
However optional second parameter may cause conflict with the 2nd join
method if this one is kept too.

Both options satisfy me, perhaps others may have advice.

Laurent

2016-12-28 10:00 GMT+01:00 Olaf van der Spek <olafvdspek@gmail.com>:

> Op woensdag 28 december 2016 08:16:40 UTC+1 schreef lnal...@gmail.com:
>>
>> I've summarized our discussion in a formal proposal here
>> http://htmlpreview.github.io/?https://github.com/laurent-n/c
>> pp17_implode_explode/blob/master/testcpp17_1/formal_proposal.html
>>
>> Should the separator argument be first or last?
> As it's usually much shorter then the other argument having it first might
> make it easier to read.
>

--
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/CA%2BfBOqMD8sGvnLqd7ZaNDwo45T0EDnNNX0Nod-rx%2BAaq2kHiRg%40mail.gmail.com.

--f403045ea47a84cb0e0544b51c33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:13px;margin:0px;padding:0px;border:0px">Hello Olaf,</div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:13px;margin:0px;padding:0=
px;border:0px"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:13px;margin:0px;padding:0px;border:0px">I suppose you are talk=
ing about static join ?</div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:13px;margin:0px;padding:0px;border:0px"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:13px;margin:0px;padd=
ing:0px;border:0px">Yes, it could make sense=C2=A0</div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:13px;margin:0px;padding:0px;bor=
der:0px">it&#39;s the case in PHP , C#, Java</div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:13px;margin:0px;padding:0px;border:0p=
x">But not in Go, Rust, boost::algorithm::join</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:13px;margin:0px;padding:0px;border:=
0px"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:13px;margin:0px;padding:0px;border:0px">Python has a different logic as =
the separator is the &quot;caller&quot; object (like 2nd join option)</div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:13px;margin:=
0px;padding:0px;border:0px"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:13px;margin:0px;padding:0px;border:0px">Having se=
parator as 2nd parameters would allow have it optional with &quot;&quot;. H=
owever optional second parameter may cause conflict with the 2nd join metho=
d if this one is kept too.</div><div style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:13px;margin:0px;padding:0px;border:0px"><br></div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:13px;margin:0px;p=
adding:0px;border:0px">Both options satisfy me, perhaps others may have adv=
ice.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:13=
px;margin:0px;padding:0px;border:0px"><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:13px;margin:0px;padding:0px;border:0px"=
>Laurent</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">2016-12-28 10:00 GMT+01:00 Olaf van der Spek <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</=
a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Op woensd=
ag 28 december 2016 08:16:40 UTC+1 schreef <a href=3D"mailto:lnal...@gmail.=
com" target=3D"_blank">lnal...@gmail.com</a>:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>I&#39;ve summarized our discussion in a for=
mal proposal here</div><div><a href=3D"http://htmlpreview.github.io/?https:=
//github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal=
_proposal.html" rel=3D"nofollow" target=3D"_blank">http://htmlpreview.githu=
b.io/?<wbr>https://github.com/laurent-n/c<wbr>pp17_implode_explode/blob/mas=
t<wbr>er/testcpp17_1/formal_proposal<wbr>.html</a><br></div><div><br></div>=
</div></blockquote><div>Should the separator argument be first or last?</di=
v><div>As it&#39;s usually much shorter then the other argument having it f=
irst might make it easier to read.=C2=A0</div></div></blockquote></div><br>=
</div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMD8sGvnLqd7ZaNDwo45T0EDnNNX0=
Nod-rx%2BAaq2kHiRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMD8s=
GvnLqd7ZaNDwo45T0EDnNNX0Nod-rx%2BAaq2kHiRg%40mail.gmail.com</a>.<br />

--f403045ea47a84cb0e0544b51c33--

.

On 2016-12-24 14:09, Nicol Bolas wrote:
> std::vector sv(std::split(some_string, "\n"));

On that note, PLEASE provide an overload taking a regex as the separator!

Ideally, we should be able to split on:

1. Characters (separator type is string::char_type)
2. Fixed strings
3. Regular expressions
4. Lists of characters (a la `strsep`)

....although (4) may be rare enough that it isn't worth a separate
function (which would have to be named differently anyway to distinguish
it from (2)); the function of (4) can always be accomplished via (3).
The others can all be overloads.

--
Matthew

--
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/5863F30F.9010704%40gmail.com.

.

On 28 December 2016 at 19:14, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-12-24 14:09, Nicol Bolas wrote:
>> std::vector sv(std::split(some_string, "\n"));
>
> On that note, PLEASE provide an overload taking a regex as the separator!

Why? You can already fairly easily walk sequences via regex_iterators.

--
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/CAFk2RUbQ0rc3dHhLMttx0m5O6R%2BHRnYg5JHHJbmo7ALQ9yd7eQ%40mail.gmail.com.

.

------=_Part_1388_369811925.1482946042826
Content-Type: multipart/alternative;
 boundary="----=_Part_1389_446518441.1482946042827"

------=_Part_1389_446518441.1482946042827
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 28, 2016 at 12:18:04 PM UTC-5, Ville Voutilainen
wrote:
>
> On 28 December 2016 at 19:14, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> > On 2016-12-24 14:09, Nicol Bolas wrote:
> >> std::vector sv(std::split(some_string, "\n"));
> >
> > On that note, PLEASE provide an overload taking a regex as the
> separator!
>
> Why? You can already fairly easily walk sequences via regex_iterators.
>

Walking matches with `regex_iterators` is walking over matches; splitting
it is getting sequences of the parts of the string that don't *match*. Oh,
you can certainly use former to generate the data for the latter. But the
two operations are not the same.

Considering that such an implementation wouldn't be difficult using
existing regex library support, nor would it impose much of a burden on
`split`'s API, I don't really see the problem.

--
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/565aa1b6-03dd-4b12-9e99-ab806c10d8e6%40isocpp.org.

------=_Part_1389_446518441.1482946042827
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 28, 2016 at 12:18:04 PM UTC-5, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Dece=
mber 2016 at 19:14, Matthew Woehlke &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"gPm2z9CjCQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt; wrote:
<br>&gt; On 2016-12-24 14:09, Nicol Bolas wrote:
<br>&gt;&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>&gt;
<br>&gt; On that note, PLEASE provide an overload taking a regex as the sep=
arator!
<br>
<br>Why? You can already fairly easily walk sequences via regex_iterators.
<br></blockquote><div><br>Walking matches with `regex_iterators` is walking=
 over matches; splitting it is getting sequences of the parts of the string=
 that don&#39;t <i>match</i>. Oh, you can certainly use former to generate =
the data for the latter. But the two operations are not the same.<br><br>Co=
nsidering that such an implementation wouldn&#39;t be difficult using exist=
ing regex library support, nor would it impose much of a burden on `split`&=
#39;s API, I don&#39;t really see the problem.<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/565aa1b6-03dd-4b12-9e99-ab806c10d8e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/565aa1b6-03dd-4b12-9e99-ab806c10d8e6=
%40isocpp.org</a>.<br />

------=_Part_1389_446518441.1482946042827--

------=_Part_1388_369811925.1482946042826--

.

------=_Part_401_853710647.1482946153284
Content-Type: multipart/alternative;
 boundary="----=_Part_402_1072043797.1482946153284"

------=_Part_402_1072043797.1482946153284
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 28, 2016 at 12:14:58 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-12-24 14:09, Nicol Bolas wrote:
> > std::vector sv(std::split(some_string, "\n"));
>
> On that note, PLEASE provide an overload taking a regex as the separator!
>

> Ideally, we should be able to split on:
>
> 1. Characters (separator type is string::char_type)
> 2. Fixed strings
> 3. Regular expressions
> 4. Lists of characters (a la `strsep`)
>

....although (4) may be rare enough that it isn't worth a separate
> function (which would have to be named differently anyway to distinguish
> it from (2)); the function of (4) can always be accomplished via (3).
> The others can all be overloads.
>

I agree that #4 is best done via regexes. But I also think that #1 should
be considered a subset of #2. That we don't really need a character-based
overload at all; just use "" instead of '' when passing your "character".

--
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/1990a1ca-4c94-46ae-ac67-ca2cb9265823%40isocpp.org.

------=_Part_402_1072043797.1482946153284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 28, 2016 at 12:14:58 PM UTC-5, Matt=
hew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-12-2=
4 14:09, Nicol Bolas wrote:
<br>&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));
<br>
<br>On that note, PLEASE provide an overload taking a regex as the separato=
r!
<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Ideally, we should be able to split on:
<br>
<br>1. Characters (separator type is string::char_type)
<br>2. Fixed strings
<br>3. Regular expressions
<br>4. Lists of characters (a la `strsep`)
<br>
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">...although=
 (4) may be rare enough that it isn&#39;t worth a separate
<br>function (which would have to be named differently anyway to distinguis=
h
<br>it from (2)); the function of (4) can always be accomplished via (3).
<br>The others can all be overloads.
<br></blockquote><div><br>I agree that #4 is best done via regexes. But I a=
lso think that #1 should be considered a subset of #2. That we don&#39;t re=
ally need a character-based overload at all; just use &quot;&quot; instead =
of &#39;&#39; when passing your &quot;character&quot;.</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1990a1ca-4c94-46ae-ac67-ca2cb9265823%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1990a1ca-4c94-46ae-ac67-ca2cb9265823=
%40isocpp.org</a>.<br />

------=_Part_402_1072043797.1482946153284--

------=_Part_401_853710647.1482946153284--

.

On 28 December 2016 at 19:27, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Why? You can already fairly easily walk sequences via regex_iterators.
> Walking matches with `regex_iterators` is walking over matches; splitting it
> is getting sequences of the parts of the string that don't match. Oh, you

Yes, and regex_iterator provides everything you need for splitting a
string with a regex and getting
the sequences that don't match. I fail to see why adding such a split
overload is such a PLEASE
when a regex-split is trivially easy to write.

--
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/CAFk2RUYhjaJHiOQJi_r8LT65P%3Da34BuFTJqVpnSVDDzC0QntoA%40mail.gmail.com.

.

On 2016-12-28 12:18, Ville Voutilainen wrote:
> On 28 December 2016 at 19:14, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2016-12-24 14:09, Nicol Bolas wrote:
>>> std::vector sv(std::split(some_string, "\n"));
>>
>> On that note, PLEASE provide an overload taking a regex as the separator!
>
> Why? You can already fairly easily walk sequences via regex_iterators.

Please show how to accomplish the following code:

  for (auto tok : split(some_input, regex{"\s+"})

(Example: "a b   c\td\n  \te" -> "a", "b", "c", "d", "e")

If you can achieve this as cleanly as the above using current features,
then I have to seriously wonder why we need a `split` that works on
constant separators, either.

--
Matthew

--
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/5863F69A.10800%40gmail.com.

.

On 2016-12-28 04:00, Olaf van der Spek wrote:
> Op woensdag 28 december 2016 08:16:40 UTC+1 schreef lnal...@gmail.com:
>> Should the separator argument be first or last?
> As it's usually much shorter then the other argument having it first might
> make it easier to read.

I think people will tend to expect that the string to be split is the
first argument and the separator is the second. This is consistent with
how UFC would work if the function were a class member: you would expect
that `a.split(b)` means "split `a` by `b`", not the other way around.
With UFC, `a.split(b)` is equivalent to `split(a, b)`, so the first
argument should be the input string.

--
Matthew

--
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/5863F887.7090701%40gmail.com.

.

On 2016-12-28 12:38, Matthew Woehlke wrote:
> On 2016-12-28 04:00, Olaf van der Spek wrote:
>> Op woensdag 28 december 2016 08:16:40 UTC+1 schreef lnal...@gmail.com:
>>> Should the separator argument be first or last?
>> As it's usually much shorter then the other argument having it first might
>> make it easier to read.
>
> I think people will tend to expect that the string to be split is the
> first argument and the separator is the second. This is consistent with
> how UFC would work if the function were a class member: you would expect
> that `a.split(b)` means "split `a` by `b`", not the other way around.
> With UFC, `a.split(b)` is equivalent to `split(a, b)`, so the first
> argument should be the input string.

....this is also consistent with `strtok` and friends.

--
Matthew

--
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/5863F8DC.1080904%40gmail.com.

.

On 28 December 2016 at 19:30, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> On that note, PLEASE provide an overload taking a regex as the separator!
>>
>> Why? You can already fairly easily walk sequences via regex_iterators.
>
> Please show how to accomplish the following code:
>
>   for (auto tok : split(some_input, regex{"\s+"})
>
> (Example: "a b   c\td\n  \te" -> "a", "b", "c", "d", "e")
>
> If you can achieve this as cleanly as the above using current features,
> then I have to seriously wonder why we need a `split` that works on
> constant separators, either.


I can't make a regex-split as pretty as that, no. And the reason we
need a split that works on constant
separators is that it's faster both in compile-time and in run-time to
provide such a split without using
a regex.

--
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/CAFk2RUZDspEEG-6fHscHPzG%3DK9Xy2541%2BwykEaNwB5aFdetVTA%40mail.gmail.com.

.

On 2016-12-28 12:29, Nicol Bolas wrote:
> On Wednesday, December 28, 2016 at 12:14:58 PM UTC-5, Matthew Woehlke wrote:
>> Ideally, we should be able to split on:
>>
>> 1. Characters (separator type is string::char_type)
>> 2. Fixed strings
>> 3. Regular expressions
>> 4. Lists of characters (a la `strsep`)
>>
>> ...although (4) may be rare enough that it isn't worth a separate
>> function (which would have to be named differently anyway to distinguish
>> it from (2)); the function of (4) can always be accomplished via (3).
>> The others can all be overloads.
>
> I agree that #4 is best done via regexes. But I also think that #1 should
> be considered a subset of #2. That we don't really need a character-based
> overload at all; just use "" instead of '' when passing your "character".

We don't *need* it, no, but potentially the operation can be performed
non-trivially faster if the separator is a single character. Considering
that many uses will likely be using a single character separator, I
think it's at least worth considering.

--
Matthew

--
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/5863FA5C.2010708%40gmail.com.

.

2016-12-28 18:46 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
>> I agree that #4 is best done via regexes. But I also think that #1 should
>> be considered a subset of #2. That we don't really need a character-based
>> overload at all; just use "" instead of '' when passing your "character".
>
> We don't *need* it, no, but potentially the operation can be performed
> non-trivially faster if the separator is a single character. Considering
> that many uses will likely be using a single character separator, I
> think it's at least worth considering.

Isn't that detectable at compile-time, even without using a separate
interface (in most cases)?


--
Olaf

--
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/CAA7U3HOfmo4_%2BPKTpDNP%3DL%2BuPmc%3DdXDNwwxQ1_aqbBD-3LiVuw%40mail.gmail.com.

.

On 2016-12-28 12:44, Ville Voutilainen wrote:
> On 28 December 2016 at 19:30, Matthew Woehlke <mwoehlke.floss@gmail.com> =
wrote:
>> Please show how to accomplish the following code:
>>
>>   for (auto tok : split(some_input, regex{"\s+"})
>>
>> (Example: "a b   c\td\n  \te" -> "a", "b", "c", "d", "e")
>>
>> If you can achieve this as cleanly as the above using current features,
>> then I have to seriously wonder why we need a `split` that works on
>> constant separators, either.
>=20
>=20
> I can't make a regex-split as pretty as that, no.

Isn't that exactly why we need it? There are other ways to iterate over
tokens in a string with fixed separators; if they're awkward enough to
warrant a `split` function, why would the same not be true for regular
expression separators?

> And the reason we need a split that works on constant separators is
> that it's faster both in compile-time and in run-time to provide such
> a split without using a regex.

I'm not proposing that the only *implementation* of `split` would use
regular expressions under the hood. I am, in fact, proposing at least
three *different* implementations, depending on whether the separator is
a) a single character, b) a fixed string, or c) a regular expression.
These each have a different trade-off of function vs. performance.

(Per elsewhere, the potential fourth implementation =E2=80=94 where the
separator is a single character of a *set* of characters =E2=80=94 is proba=
bly
insufficiently interesting.)

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5863FF5E.7050402%40gmail.com.

.

--001a113fbf2c3184390544bbfdb0
Content-Type: text/plain; charset=UTF-8

2016-12-28 18:30 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> >>> std::vector sv(std::split(some_string, "\n"));
> >>
> >> On that note, PLEASE provide an overload taking a regex as the
> separator!
> >
> > Why? You can already fairly easily walk sequences via regex_iterators.
>
> Please show how to accomplish the following code:
>
>   for (auto tok : split(some_input, regex{"\s+"})
>
> (Example: "a b   c\td\n  \te" -> "a", "b", "c", "d", "e")
>
> If you can achieve this as cleanly as the above using current features,
> then I have to seriously wonder why we need a `split` that works on
> constant separators, either.
>
> Hello,
My knowledge on regexp is pretty poor.
However I have the feeling that this request makes sense but should be
implemented as part of regex class/lib and perhaps with the same set of
method than the one we imagine here (splits,sv,f) then it could be possible
to write :
for (auto tok : regex{"\s+"}.splitsv(some_input) )

I also fear adding a regexp dependency on string class.

If the selected option is the split function, then yes an overload based on
separator type could make sense.
Or adding an regex_split algorithm as part of regex library.

  Laurent

--
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/CA%2BfBOqOr%2BS7B0j7i8eHoFr7mMHM_YDs5EaQu3S5py4-HD15CZg%40mail.gmail.com.

--001a113fbf2c3184390544bbfdb0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2016=
-12-28 18:30 GMT+01:00 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a=
>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;&gt;=
&gt; std::vector sv(std::split(some_string, &quot;\n&quot;));<br>
&gt;&gt;<br>
&gt;&gt; On that note, PLEASE provide an overload taking a regex as the sep=
arator!<br>
&gt;<br>
&gt; Why? You can already fairly easily walk sequences via regex_iterators.=
<br>
<br>
Please show how to accomplish the following code:<br>
<br>
=C2=A0 for (auto tok : split(some_input, regex{&quot;\s+&quot;})<br>
<br>
(Example: &quot;a b=C2=A0 =C2=A0c\td\n=C2=A0 \te&quot; -&gt; &quot;a&quot;,=
 &quot;b&quot;, &quot;c&quot;, &quot;d&quot;, &quot;e&quot;)<br>
<br>
If you can achieve this as cleanly as the above using current features,<br>
then I have to seriously wonder why we need a `split` that works on<br>
constant separators, either.<br><br>
<span class=3D"gmail-HOEnZb"><font color=3D"#888888"></font></span></blockq=
uote></div>Hello,</div><div class=3D"gmail_extra">My knowledge on regexp is=
 pretty poor.</div><div class=3D"gmail_extra">However I have the feeling th=
at this request makes sense but should be implemented as part of regex clas=
s/lib and perhaps with the same set of method than the one we imagine here =
(splits,sv,f) then it could be possible to write :</div><div class=3D"gmail=
_extra">for (auto tok : regex{&quot;\s+&quot;}.splitsv(some_input) )</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I also fear =
adding a regexp dependency on string class.</div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra">If the selected option is the split f=
unction, then yes an overload based on separator type could make sense.=C2=
=A0</div><div class=3D"gmail_extra">Or adding an regex_split algorithm as p=
art of regex library.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">=C2=A0 Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqOr%2BS7B0j7i8eHoFr7mMHM_YDs5=
EaQu3S5py4-HD15CZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqOr%2=
BS7B0j7i8eHoFr7mMHM_YDs5EaQu3S5py4-HD15CZg%40mail.gmail.com</a>.<br />

--001a113fbf2c3184390544bbfdb0--

.

------=_Part_1409_970316674.1482950425230
Content-Type: multipart/alternative;
 boundary="----=_Part_1410_529746214.1482950425230"

------=_Part_1410_529746214.1482950425230
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 28, 2016 at 1:18:03 PM UTC-5, Laurent Navarro wrote:
>
> 2016-12-28 18:30 GMT+01:00 Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>>:
>
>> >>> std::vector sv(std::split(some_string, "\n"));
>> >>
>> >> On that note, PLEASE provide an overload taking a regex as the
>> separator!
>> >
>> > Why? You can already fairly easily walk sequences via regex_iterators.
>>
>> Please show how to accomplish the following code:
>>
>>   for (auto tok : split(some_input, regex{"\s+"})
>>
>> (Example: "a b   c\td\n  \te" -> "a", "b", "c", "d", "e")
>>
>> If you can achieve this as cleanly as the above using current features,
>> then I have to seriously wonder why we need a `split` that works on
>> constant separators, either.
>>
>> Hello,
> My knowledge on regexp is pretty poor.
> However I have the feeling that this request makes sense but should be
> implemented as part of regex class/lib and perhaps with the same set of
> method than the one we imagine here (splits,sv,f) then it could be possible
> to write :
> for (auto tok : regex{"\s+"}.splitsv(some_input) )
>

No, it should not be a member function of `regex`.


> I also fear adding a regexp dependency on string class.
>

> If the selected option is the split function, then yes an overload based
> on separator type could make sense.
> Or adding an regex_split algorithm as part of regex library.
>

Why does it need to be named `regex_split`? Just put the regex-based
`split` overload in the `<regex>` header, while the other overloads are in
the `<string>` header.

--
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/970b9a8c-6405-4561-8844-30ffe3be3eff%40isocpp.org.

------=_Part_1410_529746214.1482950425230
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 28, 2016 at 1:18:03 PM UTC-5, Laure=
nt Navarro wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">2016-12-28 18:30 GMT+01:00 Matthew Woeh=
lke <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"mH5a6BanCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">mwoehlk...@gmail.com</a>&gt;</span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">&gt;&gt;&gt; std::vector sv(std::spli=
t(some_string, &quot;\n&quot;));<br>
&gt;&gt;<br>
&gt;&gt; On that note, PLEASE provide an overload taking a regex as the sep=
arator!<br>
&gt;<br>
&gt; Why? You can already fairly easily walk sequences via regex_iterators.=
<br>
<br>
Please show how to accomplish the following code:<br>
<br>
=C2=A0 for (auto tok : split(some_input, regex{&quot;\s+&quot;})<br>
<br>
(Example: &quot;a b=C2=A0 =C2=A0c\td\n=C2=A0 \te&quot; -&gt; &quot;a&quot;,=
 &quot;b&quot;, &quot;c&quot;, &quot;d&quot;, &quot;e&quot;)<br>
<br>
If you can achieve this as cleanly as the above using current features,<br>
then I have to seriously wonder why we need a `split` that works on<br>
constant separators, either.<br><br>
<span><font color=3D"#888888"></font></span></blockquote></div>Hello,</div>=
<div>My knowledge on regexp is pretty poor.</div><div>However I have the fe=
eling that this request makes sense but should be implemented as part of re=
gex class/lib and perhaps with the same set of method than the one we imagi=
ne here (splits,sv,f) then it could be possible to write :</div><div>for (a=
uto tok : regex{&quot;\s+&quot;}.splitsv(some_<wbr>input) )</div></div></bl=
ockquote><div><br>No, it should not be a member function of `regex`.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><div>I also fear adding a regexp dependency on string class.</div></=
div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>If the selected option is the split function, then =
yes an overload based on separator type could make sense.=C2=A0</div><div>O=
r adding an regex_split algorithm as part of regex library.</div></div></bl=
ockquote><div><br>Why does it need to be named `regex_split`? Just put the =
regex-based `split` overload in the `&lt;regex&gt;` header, while the other=
 overloads are in the `&lt;string&gt;` header.</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/970b9a8c-6405-4561-8844-30ffe3be3eff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/970b9a8c-6405-4561-8844-30ffe3be3eff=
%40isocpp.org</a>.<br />

------=_Part_1410_529746214.1482950425230--

------=_Part_1409_970316674.1482950425230--

.

Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 19:18:02 BRST, Ville Vouti=
lainen=20
escreveu:
> On 28 December 2016 at 19:14, Matthew Woehlke <mwoehlke.floss@gmail.com>=
=20
wrote:
> > On 2016-12-24 14:09, Nicol Bolas wrote:
> >> std::vector sv(std::split(some_string, "\n"));
> >=20
> > On that note, PLEASE provide an overload taking a regex as the separato=
r!
>=20
> Why? You can already fairly easily walk sequences via regex_iterators.

Because it's a common operation.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/741493214.nQG4L5Dj9S%40tjmaciei-mobl1.

.

Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 18:47:54 BRST, Olaf van de=
r Spek=20
escreveu:
> 2016-12-28 18:46 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> >> I agree that #4 is best done via regexes. But I also think that #1 sho=
uld
> >> be considered a subset of #2. That we don't really need a character-ba=
sed
> >> overload at all; just use "" instead of '' when passing your "characte=
r".
> >=20
> > We don't *need* it, no, but potentially the operation can be performed
> > non-trivially faster if the separator is a single character. Considerin=
g
> > that many uses will likely be using a single character separator, I
> > think it's at least worth considering.
>=20
> Isn't that detectable at compile-time, even without using a separate
> interface (in most cases)?

Not always.

Finding a single character in a string is a trivially fast operation and ca=
n=20
be easily made SIMD, like I have for QString.

Finding a string in a string isn't that easy. There are many techniques, so=
me=20
with benefits over others. Now, it's true that the code can easily determin=
e=20
even at runtime that the length is 1 and shunt the continuation to the 1-
character search. In fact, as a QoI, I'd recommend implementations do it.

But just like we have strchr/memchr and strstr/memmem (the latter is a GNU=
=20
extension), we ought to have the overload for a single character for=20
performance reasons.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1555042.cFJhh3qa4I%40tjmaciei-mobl1.

.

2016-12-29 4:33 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
>> > We don't *need* it, no, but potentially the operation can be performed
>> > non-trivially faster if the separator is a single character. Considering
>> > that many uses will likely be using a single character separator, I
>> > think it's at least worth considering.
>>
>> Isn't that detectable at compile-time, even without using a separate
>> interface (in most cases)?
>
> Not always.
>
> Finding a single character in a string is a trivially fast operation and can
> be easily made SIMD, like I have for QString.
>
> Finding a string in a string isn't that easy. There are many techniques, some
> with benefits over others. Now, it's true that the code can easily determine
> even at runtime that the length is 1 and shunt the continuation to the 1-
> character search. In fact, as a QoI, I'd recommend implementations do it.
>
> But just like we have strchr/memchr and strstr/memmem (the latter is a GNU
> extension), we ought to have the overload for a single character for
> performance reasons.

Why exactly, as it's easily detectable either at compile-time or at run-time?

--
Olaf

--
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/CAA7U3HPaUe3WOOv3GbsV7kmcSrYB1F9JitUC9DObmyzGvk7eHg%40mail.gmail.com.

.

------=_Part_1347_651532167.1483009956944
Content-Type: multipart/alternative;
 boundary="----=_Part_1348_1709710893.1483009956944"

------=_Part_1348_1709710893.1483009956944
Content-Type: text/plain; charset=UTF-8

Hello,

I've updated the formal proposal here with the discussion we got.
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_proposal.html
I've added these paragraphs
* split by single char
* split by regexp
* string_join function
* Processing optimization
Your advice on them is welcome.

Several point depends on the conclusion of the selected option between
string::split methods and range string_split function.
As written before string_split function looks good but we need a POC to
validate the concept and specify it.
As my knowledge on range is very low help is welcome to move forward on
this proposal.

I've just started with the underlaying tokenizer here if it can help (but
I'm not sure if it's needed or not )
https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/testcpp17_2.cpp

Thanks to everyone for this debate.
  Laurent

--
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/21c8ff92-e20c-4b97-92e6-5933e3ed0287%40isocpp.org.

------=_Part_1348_1709710893.1483009956944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I&#39;ve updated the formal prop=
osal here with the discussion we got.</div><div><a href=3D"http://htmlprevi=
ew.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/maste=
r/testcpp17_1/formal_proposal.html">http://htmlpreview.github.io/?https://g=
ithub.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_pr=
oposal.html</a><br></div><div><div>I&#39;ve added these paragraphs</div><di=
v>* split by single char</div><div>* split by regexp</div><div>* string_joi=
n function</div><div>* Processing optimization</div></div><div>Your advice =
on them is welcome.</div><div><br></div><div>Several point depends on the c=
onclusion of the selected option between string::split methods and range st=
ring_split function.</div><div>As written before string_split function look=
s good but we need a POC to validate the concept and specify it.</div><div>=
As my knowledge on range is very low help is welcome to move forward on thi=
s proposal.</div><div><br></div><div>I&#39;ve just started with the underla=
ying tokenizer here if it can help (but I&#39;m not sure if it&#39;s needed=
 or not )=C2=A0</div><div><a href=3D"https://github.com/laurent-n/cpp17_imp=
lode_explode/blob/master/testcpp17_2/testcpp17_2.cpp">https://github.com/la=
urent-n/cpp17_implode_explode/blob/master/testcpp17_2/testcpp17_2.cpp</a><b=
r></div><div><br></div><div>Thanks to everyone for this debate.</div><div>=
=C2=A0 Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21c8ff92-e20c-4b97-92e6-5933e3ed0287%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21c8ff92-e20c-4b97-92e6-5933e3ed0287=
%40isocpp.org</a>.<br />

------=_Part_1348_1709710893.1483009956944--

------=_Part_1347_651532167.1483009956944--

.

Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 09:42:02 BRST, Olaf van de=
r Spek=20
escreveu:
> 2016-12-29 4:33 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> >> Isn't that detectable at compile-time, even without using a separate
> >> interface (in most cases)?
> >=20
> > Not always.
[cut]
>=20
> Why exactly, as it's easily detectable either at compile-time or at
> run-time?

Read again: it's not *always* detectable. And if I know in my code that it =
is=20
a single character, why should I spend a handful of CPU cycles to confirm w=
hat=20
I already knew so it would call the function I know it has?

If the implementation has to implement the character find, why not expose i=
t?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2974151.VEujuMErXY%40tjmaciei-mobl1.

.

------=_Part_1440_2029066967.1483020743012
Content-Type: multipart/alternative;
 boundary="----=_Part_1441_620268805.1483020743012"

------=_Part_1441_620268805.1483020743012
Content-Type: text/plain; charset=UTF-8



Am Donnerstag, 29. Dezember 2016 12:12:37 UTC+1 schrieb lnal...@gmail.com:
>
> Hello,
>
> I've updated the formal proposal here with the discussion we got.
>
> http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_proposal.html
> I've added these paragraphs
> * split by single char
> * split by regexp
> * string_join function
> * Processing optimization
> Your advice on them is welcome.
>
> Several point depends on the conclusion of the selected option between
> string::split methods and range string_split function.
> As written before string_split function looks good but we need a POC to
> validate the concept and specify it.
> As my knowledge on range is very low help is welcome to move forward on
> this proposal.
>
> I've just started with the underlaying tokenizer here if it can help (but
> I'm not sure if it's needed or not )
>
> https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/testcpp17_2.cpp
>
> Thanks to everyone for this debate.
>   Laurent
>

FWIW,

There is/was a proposal for a std::split function here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3593.html

I don't know the status of the proposal, but I think it already covers all
the requirements mentioned in this thread (with some minor modifications to
split strings using "tokenizers" and "delimiters").

(Sorry, if it was discussed before...)

--
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/bfd536c2-89c9-495a-8851-aa3c9224e8ba%40isocpp.org.

------=_Part_1441_620268805.1483020743012
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Am Donnerstag, 29. Dezember 2016 12:12:37 UTC+1 sc=
hrieb lnal...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Hello,<div><br></div><div>I&#39;ve updated the formal proposal h=
ere with the discussion we got.</div><div><a href=3D"http://htmlpreview.git=
hub.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master/test=
cpp17_1/formal_proposal.html" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhtmlprevi=
ew.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Flaurent-n%2Fcpp17_implode_expl=
ode%2Fblob%2Fmaster%2Ftestcpp17_1%2Fformal_proposal.html\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFpDT2sBqGr11VGsi_HhjBKWnP-8Q&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhtmlprev=
iew.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Flaurent-n%2Fcpp17_implode_exp=
lode%2Fblob%2Fmaster%2Ftestcpp17_1%2Fformal_proposal.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFpDT2sBqGr11VGsi_HhjBKWnP-8Q&#39;;return true;">http=
://htmlpreview.github.io/?<wbr>https://github.com/laurent-n/<wbr>cpp17_impl=
ode_explode/blob/<wbr>master/testcpp17_1/formal_<wbr>proposal.html</a><br><=
/div><div><div>I&#39;ve added these paragraphs</div><div>* split by single =
char</div><div>* split by regexp</div><div>* string_join function</div><div=
>* Processing optimization</div></div><div>Your advice on them is welcome.<=
/div><div><br></div><div>Several point depends on the conclusion of the sel=
ected option between string::split methods and range string_split function.=
</div><div>As written before string_split function looks good but we need a=
 POC to validate the concept and specify it.</div><div>As my knowledge on r=
ange is very low help is welcome to move forward on this proposal.</div><di=
v><br></div><div>I&#39;ve just started with the underlaying tokenizer here =
if it can help (but I&#39;m not sure if it&#39;s needed or not )=C2=A0</div=
><div><a href=3D"https://github.com/laurent-n/cpp17_implode_explode/blob/ma=
ster/testcpp17_2/testcpp17_2.cpp" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgit=
hub.com%2Flaurent-n%2Fcpp17_implode_explode%2Fblob%2Fmaster%2Ftestcpp17_2%2=
Ftestcpp17_2.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoyqvNSfDTPVV2sOvV=
QB4F2cuyxg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Flaurent-n%2Fcpp17_implode_explode=
%2Fblob%2Fmaster%2Ftestcpp17_2%2Ftestcpp17_2.cpp\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNFoyqvNSfDTPVV2sOvVQB4F2cuyxg&#39;;return true;">https://githu=
b.com/laurent-n/<wbr>cpp17_implode_explode/blob/<wbr>master/testcpp17_2/tes=
tcpp17_<wbr>2.cpp</a><br></div><div><br></div><div>Thanks to everyone for t=
his debate.</div><div>=C2=A0 Laurent</div></div></blockquote><div><br></div=
><div>FWIW,</div><div><br></div><div>There is/was a proposal for a std::spl=
it function here:</div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2013/n3593.html</div><div><br></div><div>I don&#39;t know the status of=
 the proposal, but I think it already covers all the requirements mentioned=
 in this thread (with some minor modifications to split strings using &quot=
;tokenizers&quot; and &quot;delimiters&quot;).</div><div><br></div><div>(So=
rry, if it was discussed before...)</div><div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bfd536c2-89c9-495a-8851-aa3c9224e8ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bfd536c2-89c9-495a-8851-aa3c9224e8ba=
%40isocpp.org</a>.<br />

------=_Part_1441_620268805.1483020743012--

------=_Part_1440_2029066967.1483020743012--

.

------=_Part_1247_680942446.1483105337699
Content-Type: multipart/alternative;
 boundary="----=_Part_1248_559488950.1483105337699"

------=_Part_1248_559488950.1483105337699
Content-Type: text/plain; charset=UTF-8

Hello,

@Alexander
Regarding proposal N3593 it seems it wasn't accepted (perhaps too early
regarding the range concept & string_view availability it was depending on)

I've written a prototype for a range returning string_split using range_v3
from Eric Niebler on Gcc 4.8
Available here
https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/string_split.cpp
*Warning I've never written range nor iterator earlier so no guarantee it
was the best code to do that.*

The idea is to have a tokenizer with its underlying iterator integrated in
a string_tokenizer_range instantiated by the string_split function.
I was able to have the 'for' working fine
for(auto i:string_split(str2,' '))
But I wasn't able to do that work, but I suppose on C++ 17 it would
probably work.
std::vector<string> vi3=string_split(str2,' ');
I wasn't able to make it work with a char* parameter.

I've the feeling it will be required to define a new set of 3 classes + a
function overload for each kind of separator (char, string, regex)

The range approach looks modern but in the implementation it sounds to me
complex, generating several intermediate objects for a reduced benefit
regarding the methods option.

I'm more adept of the KISS and this option doesn't match the Simple in its
implementation (but perhaps a range expert may provide us a better/simpler
prototype)
Having split's method sounds me having sense as in fact this algorithm
function will work only for basic_string and basic_string_view.

At the view of these last thoughts, do you consider having a string_split
function is the best option or splits,sv,c methods sounds a good option ?

@all it would be great if someone can submit a splitsv version with regex
as separator (you can provide it as non generic classic function I will
adapt it as generic method)

Laurent

--
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/ca40f4bb-3b01-4905-967b-70e78200ec83%40isocpp.org.

------=_Part_1248_559488950.1483105337699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>@Alexander</div><div>Regarding p=
roposal N3593 it seems it wasn&#39;t accepted (perhaps too early regarding =
the range concept &amp; string_view availability it was depending on)</div>=
<div><br></div><div>I&#39;ve written a prototype for a range returning stri=
ng_split using range_v3 from Eric Niebler on Gcc 4.8</div><div>Available he=
re=C2=A0<a href=3D"https://github.com/laurent-n/cpp17_implode_explode/blob/=
master/testcpp17_2/string_split.cpp">https://github.com/laurent-n/cpp17_imp=
lode_explode/blob/master/testcpp17_2/string_split.cpp</a></div><div><b>Warn=
ing I&#39;ve never written range nor iterator earlier so no guarantee it wa=
s the best code to do that.</b></div><div><br></div><div>The idea is to hav=
e a tokenizer with its underlying iterator integrated in a string_tokenizer=
_range instantiated by the string_split function.</div><div>I was able to h=
ave the &#39;for&#39; working fine<div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">string_split</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">str2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">&#39; &#39;</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">))</span></div></code></div></div><d=
iv>But I wasn&#39;t able to do that work, but I suppose on C++ 17 it would =
probably work.</div><div><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ve=
ctor</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;st=
ring&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v=
i3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">string_split</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">str2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">&#39; &#39;</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span></div></code></div>I wasn&#=
39;t able to make it work with a char* parameter.<br><br></div><div>I&#39;v=
e the feeling it will be required to define a new set of 3 classes + a func=
tion overload for each kind of separator (char, string, regex)</div><div><b=
r></div><div>The range approach looks modern but in the implementation it s=
ounds to me complex, generating several intermediate objects for a reduced =
benefit regarding the methods option.</div><div><br></div><div>I&#39;m more=
 adept of the KISS and this option doesn&#39;t match the Simple in its impl=
ementation (but perhaps a range expert may provide us a better/simpler prot=
otype)</div><div>Having split&#39;s method sounds me having sense as in fac=
t this algorithm function will work only=C2=A0for basic_string and basic_st=
ring_view.</div><div><br></div><div>At the view of these last thoughts, do =
you consider having a string_split function is the best option or splits,sv=
,c methods sounds a good option ?</div><div><br></div><div>@all it would be=
 great if someone can submit a splitsv version with regex as separator (you=
 can provide it as non generic classic function I will adapt it as generic =
method)</div><div><br></div><div>Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ca40f4bb-3b01-4905-967b-70e78200ec83%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ca40f4bb-3b01-4905-967b-70e78200ec83=
%40isocpp.org</a>.<br />

------=_Part_1248_559488950.1483105337699--

------=_Part_1247_680942446.1483105337699--

.

--001a1143c944e81f8e0544e2af23
Content-Type: text/plain; charset=UTF-8

2016-12-30 14:42 GMT+01:00 <lnaltidev@gmail.com>:

> Hello,
>
> @Alexander
> Regarding proposal N3593 it seems it wasn't accepted (perhaps too early
> regarding the range concept & string_view availability it was depending on)
>
> I've written a prototype for a range returning string_split using range_v3
> from Eric Niebler on Gcc 4.8
> Available here https://github.com/laurent-n/cpp17_implode_
> explode/blob/master/testcpp17_2/string_split.cpp
> *Warning I've never written range nor iterator earlier so no guarantee it
> was the best code to do that.*
>
> The idea is to have a tokenizer with its underlying iterator integrated in
> a string_tokenizer_range instantiated by the string_split function.
>
I was able to have the 'for' working fine
> for(auto i:string_split(str2,' '))
> But I wasn't able to do that work, but I suppose on C++ 17 it would
> probably work.
> std::vector<string> vi3=string_split(str2,' ');
> I wasn't able to make it work with a char* parameter.
>
> I've the feeling it will be required to define a new set of 3 classes + a
> function overload for each kind of separator (char, string, regex)
>
> The range approach looks modern but in the implementation it sounds to me
> complex, generating several intermediate objects for a reduced benefit
> regarding the methods option.
>
> I'm more adept of the KISS and this option doesn't match the Simple in its
> implementation (but perhaps a range expert may provide us a better/simpler
> prototype)
> Having split's method sounds me having sense as in fact this algorithm
> function will work only for basic_string and basic_string_view.
>
> At the view of these last thoughts, do you consider having a string_split
> function is the best option or splits,sv,c methods sounds a good option ?
>

Hi Laurent,

Yes, returning such a string_tokenizer_range is nice.

I think a single string_split function returning such a range is sufficient.
Making the iterator and range classes templatized on the delimiter and
string types avoids the need to rewrite them for every delimiter (if the
delimiters share a common interface).

Here is proof-of-concept version of such a function:
https://gist.github.com/mrbolz/8ca3cc390c60ceb71f74f1cda4f68606
And some tests:
https://gist.github.com/mrbolz/f86fcf71030b9f976fb5f6e2746a0b70

The implementation closely follows N3593 and is basically the same as
yours: The Split() function takes a string and a delimiter object and
returns a range object. (There is also a ForEach() function with a much
simpler implementation.) It works (i.e. it should work :-)) for all string
types which are explicitly convertible to std::string_view.

I have no experience with range_v3 yet... But there is:
https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/split.hpp
Haven't looked at this closely, but it seems to do exactly what we need?!
Probably we don't need such a string_split function at all once we have
better support for ranges?! :-)


> @all it would be great if someone can submit a splitsv version with regex
> as separator (you can provide it as non generic classic function I will
> adapt it as generic method)
>
> Laurent
>
> --
> 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/ca40f4bb-3b01-4905-
> 967b-70e78200ec83%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ca40f4bb-3b01-4905-967b-70e78200ec83%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAHt48kvy2Qi646t27%2B7vD-HoQoLiAN71DHv%3DPM4i5aAp6mjUvw%40mail.gmail.com.

--001a1143c944e81f8e0544e2af23
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2016=
-12-30 14:42 GMT+01:00  <span dir=3D"ltr">&lt;<a href=3D"mailto:lnaltidev@g=
mail.com" target=3D"_blank">lnaltidev@gmail.com</a>&gt;</span>:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hello,<div><br><=
/div><div>@Alexander</div><div>Regarding proposal N3593 it seems it wasn&#3=
9;t accepted (perhaps too early regarding the range concept &amp; string_vi=
ew availability it was depending on)</div><div><br></div><div>I&#39;ve writ=
ten a prototype for a range returning string_split using range_v3 from Eric=
 Niebler on Gcc 4.8</div><div>Available here=C2=A0<a href=3D"https://github=
..com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/string_split.c=
pp" target=3D"_blank">https://github.com/<wbr>laurent-n/cpp17_implode_<wbr>=
explode/blob/master/testcpp17_<wbr>2/string_split.cpp</a></div><div><b>Warn=
ing I&#39;ve never written range nor iterator earlier so no guarantee it wa=
s the best code to do that.</b></div><div><br></div><div>The idea is to hav=
e a tokenizer with its underlying iterator integrated in a string_tokenizer=
_range instantiated by the string_split function.</div></div></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I wa=
s able to have the &#39;for&#39; working fine<div class=3D"gmail-m_-3536181=
003450578314prettyprint" style=3D"background-color:rgb(250,250,250);border-=
color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-=
word"><code class=3D"gmail-m_-3536181003450578314prettyprint"><div class=3D=
"gmail-m_-3536181003450578314subprettyprint"><span style=3D"color:rgb(0,0,1=
36)" class=3D"gmail-m_-3536181003450578314styled-by-prettify">for</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314styl=
ed-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m=
_-3536181003450578314styled-by-prettify">auto</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-3536181003450578314styled-by-prettify"> i</span=
><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314=
styled-by-prettify">:</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-3536181003450578314styled-by-prettify">string_split</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314styled-by-pr=
ettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-35361810=
03450578314styled-by-prettify">str2</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-3536181003450578314styled-by-prettify">,</span><span =
style=3D"color:rgb(0,136,0)" class=3D"gmail-m_-3536181003450578314styled-by=
-prettify">&#39; &#39;</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_-3536181003450578314styled-by-prettify">))</span></div></code></div=
></div><div>But I wasn&#39;t able to do that work, but I suppose on C++ 17 =
it would probably work.</div><div><div class=3D"gmail-m_-353618100345057831=
4prettyprint" style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
 class=3D"gmail-m_-3536181003450578314prettyprint"><div class=3D"gmail-m_-3=
536181003450578314subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D=
"gmail-m_-3536181003450578314styled-by-prettify">std</span><span style=3D"c=
olor:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314styled-by-prettif=
y">::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-353618100345=
0578314styled-by-prettify">vector</span><span style=3D"color:rgb(0,136,0)" =
class=3D"gmail-m_-3536181003450578314styled-by-prettify">&lt;string&gt;</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-3536181003450578314st=
yled-by-prettify"> vi3</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_-3536181003450578314styled-by-prettify">=3D</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-3536181003450578314styled-by-prettify">st=
ring_split</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-353=
6181003450578314styled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)=
" class=3D"gmail-m_-3536181003450578314styled-by-prettify">str2</span><span=
 style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314styled=
-by-prettify">,</span><span style=3D"color:rgb(0,136,0)" class=3D"gmail-m_-=
3536181003450578314styled-by-prettify">&#39; &#39;</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-3536181003450578314styled-by-prettify"=
>);</span></div></code></div>I wasn&#39;t able to make it work with a char*=
 parameter.<br><br></div><div>I&#39;ve the feeling it will be required to d=
efine a new set of 3 classes + a function overload for each kind of separat=
or (char, string, regex)</div><div><br></div><div>The range approach looks =
modern but in the implementation it sounds to me complex, generating severa=
l intermediate objects for a reduced benefit regarding the methods option.<=
/div><div><br></div><div>I&#39;m more adept of the KISS and this option doe=
sn&#39;t match the Simple in its implementation (but perhaps a range expert=
 may provide us a better/simpler prototype)</div><div>Having split&#39;s me=
thod sounds me having sense as in fact this algorithm function will work on=
ly=C2=A0for basic_string and basic_string_view.</div><div><br></div><div>At=
 the view of these last thoughts, do you consider having a string_split fun=
ction is the best option or splits,sv,c methods sounds a good option ?</div=
></div></blockquote><div><br></div><div>Hi Laurent,<br></div><div><br></div=
><div>Yes, returning such a string_tokenizer_range is nice.</div><div><br><=
/div><div>I think a single string_split function returning such a range is =
sufficient.</div><div>Making the iterator and range classes templatized on =
the delimiter and string types avoids the need to rewrite them for every de=
limiter (if the delimiters share a common interface).</div><div><br></div><=
div>Here is proof-of-concept version of such a function:</div><div><a href=
=3D"https://gist.github.com/mrbolz/8ca3cc390c60ceb71f74f1cda4f68606">https:=
//gist.github.com/mrbolz/8ca3cc390c60ceb71f74f1cda4f68606</a></div><div>And=
 some tests:</div><div><a href=3D"https://gist.github.com/mrbolz/f86fcf7103=
0b9f976fb5f6e2746a0b70">https://gist.github.com/mrbolz/f86fcf71030b9f976fb5=
f6e2746a0b70</a><br></div><div><br></div><div>The implementation closely fo=
llows N3593 and is basically the same as yours: The Split() function takes =
a string and a delimiter object and returns a range object. (There is also =
a ForEach() function with a much simpler implementation.) It works (i.e. it=
 should work :-)) for all string types which are explicitly convertible to =
std::string_view.</div><div><br></div><div>I have no experience with range_=
v3 yet... But there is:</div><div><a href=3D"https://github.com/ericniebler=
/range-v3/blob/master/include/range/v3/view/split.hpp">https://github.com/e=
ricniebler/range-v3/blob/master/include/range/v3/view/split.hpp</a><br></di=
v><div>Haven&#39;t looked at this closely, but it seems to do exactly what =
we need?! Probably we don&#39;t need such a string_split function at all on=
ce we have better support for ranges?! :-)</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>=
@all it would be great if someone can submit a splitsv version with regex a=
s separator (you can provide it as non generic classic function I will adap=
t it as generic method)</div><div><br></div><div>Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<span class=3D"gmail-"=
><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ca40f4bb-3b01-4905-967b-70e78200ec83%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ca40=
f4bb-3b01-4905-<wbr>967b-70e78200ec83%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHt48kvy2Qi646t27%2B7vD-HoQoLiAN71DH=
v%3DPM4i5aAp6mjUvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHt48kvy2Qi6=
46t27%2B7vD-HoQoLiAN71DHv%3DPM4i5aAp6mjUvw%40mail.gmail.com</a>.<br />

--001a1143c944e81f8e0544e2af23--

.

------=_Part_7167_1963839752.1483117668109
Content-Type: multipart/alternative;
 boundary="----=_Part_7168_1696061487.1483117668109"

------=_Part_7168_1696061487.1483117668109
Content-Type: text/plain; charset=UTF-8

On Friday, December 30, 2016 at 8:42:17 AM UTC-5, lnal...@gmail.com wrote:
>
> Hello,
>
> @Alexander
> Regarding proposal N3593 it seems it wasn't accepted (perhaps too early
> regarding the range concept & string_view availability it was depending on)
>
> I've written a prototype for a range returning string_split using range_v3
> from Eric Niebler on Gcc 4.8
> Available here
> https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_2/string_split.cpp
> *Warning I've never written range nor iterator earlier so no guarantee it
> was the best code to do that.*
>
> The idea is to have a tokenizer with its underlying iterator integrated in
> a string_tokenizer_range instantiated by the string_split function.
> I was able to have the 'for' working fine
> for(auto i:string_split(str2,' '))
> But I wasn't able to do that work, but I suppose on C++ 17 it would
> probably work.
> std::vector<string> vi3=string_split(str2,' ');
> I wasn't able to make it work with a char* parameter.
>

That is due to the lack of a range-based constructor for `vector`. We won't
see that until ranges become standard in C++. But we should design new
features to work with other new features, so long as those other new
features are actually going to show up.

You can always fudge it a bit by getting a pair of iterators from the range
and then applying them to the iterator-range `vector` constructor.

I've the feeling it will be required to define a new set of 3 classes + a
> function overload for each kind of separator (char, string, regex)
>
> The range approach looks modern but in the implementation it sounds to me
> complex, generating several intermediate objects for a reduced benefit
> regarding the methods option.
>
> I'm more adept of the KISS and this option doesn't match the Simple in its
> implementation (but perhaps a range expert may provide us a better/simpler
> prototype)
>

Unless the implementation is severely overburdened, I don't agree (and
having 3 range classes and 3 overloads doesn't count as "seriously
overburdened"). Utilities are used far more often than they are written. We
should optimize for simplicity of use, not of implementation.

Having split's method sounds me having sense as in fact this algorithm
> function will work only for basic_string and basic_string_view.
>

Why should it be limited to those two types? Indeed, why should you even
care about `basic_string`? It should be able to work with *anything* which
is convertible to a `basic_string_view`.

At the view of these last thoughts, do you consider having a string_split
> function is the best option or splits,sv,c methods sounds a good option ?
>
> @all it would be great if someone can submit a splitsv version with regex
> as separator (you can provide it as non generic classic function I will
> adapt it as generic method)
>

That's pretty trivial, since `regex` does all the work for you. All you're
writing is a nice, thin wrapper around `regex_token_iterator`.

But if you insist
<https://gist.github.com/NicolBolas/f326fab93f237c2e1c2fb58b10442f18>. Note
that I have not tested this code significantly. I tried a couple of regex
splits with it, and it seems to work.

--
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/f02c6730-d7a5-460c-a536-2b35175a9427%40isocpp.org.

------=_Part_7168_1696061487.1483117668109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 30, 2016 at 8:42:17 AM UTC-5, lnal...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Hello,<div><br></div><div>@Alexander</div><div>Regarding proposal N3593 =
it seems it wasn&#39;t accepted (perhaps too early regarding the range conc=
ept &amp; string_view availability it was depending on)</div><div><br></div=
><div>I&#39;ve written a prototype for a range returning string_split using=
 range_v3 from Eric Niebler on Gcc 4.8</div><div>Available here=C2=A0<a hre=
f=3D"https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp=
17_2/string_split.cpp" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fl=
aurent-n%2Fcpp17_implode_explode%2Fblob%2Fmaster%2Ftestcpp17_2%2Fstring_spl=
it.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGsN11kVBT9vS8u9eY0KWbRJz7phg=
&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Flaurent-n%2Fcpp17_implode_explode%2Fblob%2F=
master%2Ftestcpp17_2%2Fstring_split.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNGsN11kVBT9vS8u9eY0KWbRJz7phg&#39;;return true;">https://github.com/<wb=
r>laurent-n/cpp17_implode_<wbr>explode/blob/master/testcpp17_<wbr>2/string_=
split.cpp</a></div><div><b>Warning I&#39;ve never written range nor iterato=
r earlier so no guarantee it was the best code to do that.</b></div><div><b=
r></div><div>The idea is to have a tokenizer with its underlying iterator i=
ntegrated in a string_tokenizer_range instantiated by the string_split func=
tion.</div><div>I was able to have the &#39;for&#39; working fine<div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">for</span><span style=3D"color:#660">(</span><span style=3D=
"color:#008">auto</span><span style=3D"color:#000"> i</span><span style=3D"=
color:#660">:</span><span style=3D"color:#000">string_split</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">str2</span><span style=
=3D"color:#660">,</span><span style=3D"color:#080">&#39; &#39;</span><span =
style=3D"color:#660">))</span></div></code></div></div><div>But I wasn&#39;=
t able to do that work, but I suppose on C++ 17 it would probably work.</di=
v><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187=
,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><=
div><span style=3D"color:#000">std</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">vector</span><span style=3D"color:#080">&lt;st=
ring&gt;</span><span style=3D"color:#000"> vi3</span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000">string_split</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000">str2</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#080">&#39; &#39;</span><span style=
=3D"color:#660">);</span></div></code></div>I wasn&#39;t able to make it wo=
rk with a char* parameter.<br></div></div></blockquote><div><br>That is due=
 to the lack of a range-based constructor for `vector`. We won&#39;t see th=
at until ranges become standard in C++. But we should design new features t=
o work with other new features, so long as those other new features are act=
ually going to show up.<br><br>You can always fudge it a bit by getting a p=
air of iterators from the range and then applying them to the iterator-rang=
e `vector` constructor.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div></div><div>I&#39;ve the feeling it will be req=
uired to define a new set of 3 classes + a function overload for each kind =
of separator (char, string, regex)</div><div><br></div><div>The range appro=
ach looks modern but in the implementation it sounds to me complex, generat=
ing several intermediate objects for a reduced benefit regarding the method=
s option.</div><div><br></div><div>I&#39;m more adept of the KISS and this =
option doesn&#39;t match the Simple in its implementation (but perhaps a ra=
nge expert may provide us a better/simpler prototype)</div></div></blockquo=
te><div><br>Unless the implementation is severely overburdened, I don&#39;t=
 agree (and having 3 range classes and 3 overloads doesn&#39;t count as &qu=
ot;seriously overburdened&quot;). Utilities are used far more often than th=
ey are written. We should optimize for simplicity of use, not of implementa=
tion.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>Having split&#39;s method sounds me having sense as in fact this=
 algorithm function will work only=C2=A0for basic_string and basic_string_v=
iew.</div></div></blockquote><div><br>Why should it be limited to those two=
 types? Indeed, why should you even care about `basic_string`? It should be=
 able to work with <i>anything</i> which is convertible to a `basic_string_=
view`.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><div>At the view of these last thoughts, do you conside=
r having a string_split function is the best option or splits,sv,c methods =
sounds a good option ?</div><div><br></div><div>@all it would be great if s=
omeone can submit a splitsv version with regex as separator (you can provid=
e it as non generic classic function I will adapt it as generic method)</di=
v></div></blockquote><div><br>That&#39;s pretty trivial, since `regex` does=
 all the work for you. All you&#39;re writing is a nice, thin wrapper aroun=
d `regex_token_iterator`.<br><br><a href=3D"https://gist.github.com/NicolBo=
las/f326fab93f237c2e1c2fb58b10442f18">But if you insist</a>. Note that I ha=
ve not tested this code significantly. I tried a couple of regex splits wit=
h it, and it seems to work.<br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f02c6730-d7a5-460c-a536-2b35175a9427%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f02c6730-d7a5-460c-a536-2b35175a9427=
%40isocpp.org</a>.<br />

------=_Part_7168_1696061487.1483117668109--

------=_Part_7167_1963839752.1483117668109--

.

------=_Part_1822_1931168928.1483291623900
Content-Type: multipart/alternative;
 boundary="----=_Part_1823_315792088.1483291623900"

------=_Part_1823_315792088.1483291623900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

First of all, I would like to wish you a happy new year 2017.
This year will be for our community an important year with the release of a=
=20
major release of our favorite language (perhaps with a split/join feature=
=20
in it ;-) ).

Thanks to Nicol & Alexander to have provided me their prototype [3]&[4] on=
=20
the proposal.
It allowed me to enrich my prototype of basic_string_view methods [2] on=20
the proposal with regex version

It's also allowed me to highlight a major problem that was sense in prior=
=20
discussion related to temporary objects passed to string_split, I had=20
highlighted it our 3 implementations (partially on Nicol's one with regex=
=20
but appear on the adapted version with a string separator [see 4], I think=
=20
the tokenizer make a copy).

I've written my notes here.
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_ex=
plode/blob/master/testcpp17_1/formal_proposal.html#TempObject

I've also done a comparison between these two approaches on the proposal,=
=20
and my conclusion is that , as smart appear the function option there are=
=20
not so many benefits but there's a lot of extra complexity and even=20
resource consumption except for 1 case=20
for(s :string_split(str,","))

What is your opinion on that ? Do you share my analysis ?

I have updated the proposal document :
Added =C2=A7
* Temporary object issues
* Solutions Comparison
* split by splitter object
* Parameter order
* Reference to Nicol & Alexander prototype, and N3593 Proposal
Created a new implementation method implementation prototype on GCC6.2

Thanks again for your contribution, I'm sure we will be able to find the=20
best option, with argument and implementation prototype that can't be=20
rejected be the committee

  Laurent

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ba5f1ab1-0447-4f22-b83c-e26672d8fba3%40isocpp.or=
g.

------=_Part_1823_315792088.1483291623900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello,</div><div><br></div><div>First of all, I =
would like to wish you a happy new year 2017.</div><div>This year will be f=
or our community an important year with the release of a major release of o=
ur favorite language (perhaps with a split/join feature in it ;-) ).<br></d=
iv><div><br></div><div>Thanks to Nicol &amp; Alexander to have provided me =
their prototype [3]&amp;[4] on the proposal.<br></div><div>It allowed me to=
 enrich my prototype of basic_string_view methods [2] on the proposal with =
regex version<br></div><div><br></div><div>It&#39;s also allowed me to high=
light a major problem that was sense in prior discussion related to tempora=
ry objects passed to string_split, I had highlighted it our 3 implementatio=
ns (partially on Nicol&#39;s one with regex but appear on the adapted versi=
on with a string separator [see 4], I think the tokenizer make a copy).</di=
v><div><br></div><div>I&#39;ve written my notes here.</div><div><a href=3D"=
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_ex=
plode/blob/master/testcpp17_1/formal_proposal.html#TempObject">http://htmlp=
review.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/m=
aster/testcpp17_1/formal_proposal.html#TempObject</a></div><div><br></div><=
div>I&#39;ve also done a comparison between these two approaches on the pro=
posal, and my conclusion is that , as smart appear the function option ther=
e are not so many benefits but there&#39;s a lot of extra complexity and ev=
en resource consumption except for 1 case=C2=A0<div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">s </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">string_split</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">str</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&quot;,&quot;</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">))</span></div></c=
ode></div><br>What is your opinion on that ? Do you share my analysis ?<br>=
</div><div><br></div><div>I have updated the proposal document :</div><div>=
Added =C2=A7<br></div><div>* Temporary object issues</div><div>* Solutions =
Comparison</div><div>* split by splitter object</div><div>* Parameter order=
</div><div>* Reference to Nicol &amp; Alexander prototype, and N3593 Propos=
al</div><div>Created a new implementation method implementation prototype o=
n GCC6.2</div></div><div><br></div><div>Thanks again for your contribution,=
 I&#39;m sure we will be able to find the best option, with argument and im=
plementation prototype that can&#39;t be rejected be the committee</div><di=
v><br></div><div>=C2=A0 Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba5f1ab1-0447-4f22-b83c-e26672d8fba3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba5f1ab1-0447-4f22-b83c-e26672d8fba3=
%40isocpp.org</a>.<br />

------=_Part_1823_315792088.1483291623900--

------=_Part_1822_1931168928.1483291623900--

.

On 2016-12-28 12:47, Olaf van der Spek wrote:
> 2016-12-28 18:46 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
>>> I agree that #4 is best done via regexes. But I also think that #1 should
>>> be considered a subset of #2. That we don't really need a character-based
>>> overload at all; just use "" instead of '' when passing your "character".
>>
>> We don't *need* it, no, but potentially the operation can be performed
>> non-trivially faster if the separator is a single character. Considering
>> that many uses will likely be using a single character separator, I
>> think it's at least worth considering.
>
> Isn't that detectable at compile-time, even without using a separate
> interface (in most cases)?

Um... how? Particularly if the separator is itself not known at compile
time, how would the compiler know *at compile time* that the separator
is a single character? (Even from a known string literal, I'm not sure
how you would implement such an optimization... at least without some
really deep compiler voodoo, given that we don't (yet) have constexpr
parameters...)

Given:

  i = split(input1, ";");
  j = split(input2, sep); // 'sep' is known to have strlen(sep) == 1

Please explain how the compiler will optimize these to calling an
optimized version of `split`. Checking if `sep[1] == 0` at run-time is
not permitted.

--
Matthew

--
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/586D2FFC.2010302%40gmail.com.

.

2017-01-04 18:25 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> On 2016-12-28 12:47, Olaf van der Spek wrote:
>> 2016-12-28 18:46 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
>>>> I agree that #4 is best done via regexes. But I also think that #1 should
>>>> be considered a subset of #2. That we don't really need a character-based
>>>> overload at all; just use "" instead of '' when passing your "character".
>>>
>>> We don't *need* it, no, but potentially the operation can be performed
>>> non-trivially faster if the separator is a single character. Considering
>>> that many uses will likely be using a single character separator, I
>>> think it's at least worth considering.
>>
>> Isn't that detectable at compile-time, even without using a separate
>> interface (in most cases)?
>
> Um... how?

In most cases.. ;)

> Particularly if the separator is itself not known at compile
> time, how would the compiler know *at compile time* that the separator
> is a single character? (Even from a known string literal, I'm not sure
> how you would implement such an optimization... at least without some
> really deep compiler voodoo, given that we don't (yet) have constexpr
> parameters...)

Constant propagation, partial inlining? I'm not sure what the right
term is but compilers might be smarter then you think.

> Given:
>
>   i = split(input1, ";");
>   j = split(input2, sep); // 'sep' is known to have strlen(sep) == 1
>
> Please explain how the compiler will optimize these to calling an
> optimized version of `split`. Checking if `sep[1] == 0` at run-time is
> not permitted.

Why not?
The split algo is way more expensive then a simple size() == 1 check isn't it?


--
Olaf

--
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/CAA7U3HO90JRxbbwWESABSefY15vVFMczRXUU6iqXi4rSh-WBeg%40mail.gmail.com.

.

--001a11401be00f80520545490122
Content-Type: text/plain; charset=UTF-8

Hello,

The advantage of the runtime optimization is, it happens even if the
developer specifies "," instead of ',' and I agree to say it's a low-cost
evaluation to select the right code.

  Laurent

2017-01-04 19:03 GMT+01:00 Olaf van der Spek <olafvdspek@gmail.com>:

> 2017-01-04 18:25 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> > On 2016-12-28 12:47, Olaf van der Spek wrote:
> >> 2016-12-28 18:46 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> >>>> I agree that #4 is best done via regexes. But I also think that #1
> should
> >>>> be considered a subset of #2. That we don't really need a
> character-based
> >>>> overload at all; just use "" instead of '' when passing your
> "character".
> >>>
> >>> We don't *need* it, no, but potentially the operation can be performed
> >>> non-trivially faster if the separator is a single character.
> Considering
> >>> that many uses will likely be using a single character separator, I
> >>> think it's at least worth considering.
> >>
> >> Isn't that detectable at compile-time, even without using a separate
> >> interface (in most cases)?
> >
> > Um... how?
>
> In most cases.. ;)
>
> > Particularly if the separator is itself not known at compile
> > time, how would the compiler know *at compile time* that the separator
> > is a single character? (Even from a known string literal, I'm not sure
> > how you would implement such an optimization... at least without some
> > really deep compiler voodoo, given that we don't (yet) have constexpr
> > parameters...)
>
> Constant propagation, partial inlining? I'm not sure what the right
> term is but compilers might be smarter then you think.
>
> > Given:
> >
> >   i = split(input1, ";");
> >   j = split(input2, sep); // 'sep' is known to have strlen(sep) == 1
> >
> > Please explain how the compiler will optimize these to calling an
> > optimized version of `split`. Checking if `sep[1] == 0` at run-time is
> > not permitted.
>
> Why not?
> The split algo is way more expensive then a simple size() == 1 check isn't
> it?
>
>
> --
> Olaf
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/JTKTThJ-7Ko/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAA7U3HO90JRxbbwWESABSefY15vVF
> MczRXUU6iqXi4rSh-WBeg%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMPthM32iYyYwh8Bi_f68WUp%3DrhYryPj5Ezs4xWPoF%3Dgw%40mail.gmail.com.

--001a11401be00f80520545490122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div>The advantage of the runti=
me optimization is, it happens even if the developer specifies &quot;,&quot=
; instead of &#39;,&#39; and I agree to say it&#39;s a low-cost evaluation =
to select the right code.<div><br></div><div>=C2=A0 Laurent=C2=A0</div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-01-04 19:0=
3 GMT+01:00 Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafv=
dspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2017-01-04 18:25 GMT+01:00 Matthew Woehlke &=
lt;<a href=3D"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>=
&gt;:<br>
&gt; On 2016-12-28 12:47, Olaf van der Spek wrote:<br>
&gt;&gt; 2016-12-28 18:46 GMT+01:00 Matthew Woehlke &lt;<a href=3D"mailto:m=
woehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;&gt; I agree that #4 is best done via regexes. But I also think=
 that #1 should<br>
&gt;&gt;&gt;&gt; be considered a subset of #2. That we don&#39;t really nee=
d a character-based<br>
&gt;&gt;&gt;&gt; overload at all; just use &quot;&quot; instead of &#39;&#3=
9; when passing your &quot;character&quot;.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; We don&#39;t *need* it, no, but potentially the operation can =
be performed<br>
&gt;&gt;&gt; non-trivially faster if the separator is a single character. C=
onsidering<br>
&gt;&gt;&gt; that many uses will likely be using a single character separat=
or, I<br>
&gt;&gt;&gt; think it&#39;s at least worth considering.<br>
&gt;&gt;<br>
&gt;&gt; Isn&#39;t that detectable at compile-time, even without using a se=
parate<br>
&gt;&gt; interface (in most cases)?<br>
&gt;<br>
&gt; Um... how?<br>
<br>
In most cases.. ;)<br>
<br>
&gt; Particularly if the separator is itself not known at compile<br>
&gt; time, how would the compiler know *at compile time* that the separator=
<br>
&gt; is a single character? (Even from a known string literal, I&#39;m not =
sure<br>
&gt; how you would implement such an optimization... at least without some<=
br>
&gt; really deep compiler voodoo, given that we don&#39;t (yet) have conste=
xpr<br>
&gt; parameters...)<br>
<br>
Constant propagation, partial inlining? I&#39;m not sure what the right<br>
term is but compilers might be smarter then you think.<br>
<br>
&gt; Given:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0i =3D split(input1, &quot;;&quot;);<br>
&gt;=C2=A0 =C2=A0j =3D split(input2, sep); // &#39;sep&#39; is known to hav=
e strlen(sep) =3D=3D 1<br>
&gt;<br>
&gt; Please explain how the compiler will optimize these to calling an<br>
&gt; optimized version of `split`. Checking if `sep[1] =3D=3D 0` at run-tim=
e is<br>
&gt; not permitted.<br>
<br>
Why not?<br>
The split algo is way more expensive then a simple size() =3D=3D 1 check is=
n&#39;t it?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Olaf<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/JTKTThJ-7Ko/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/JTKTThJ-7Ko/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7U3HO90JRxbbwWESABSefY15vVFMczRXUU=
6iqXi4rSh-WBeg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAA7=
U3HO90JRxbbwWESABSefY15vVF<wbr>MczRXUU6iqXi4rSh-WBeg%40mail.<wbr>gmail.com<=
/a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMPthM32iYyYwh8Bi_f68WUp%3Drh=
YryPj5Ezs4xWPoF%3Dgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMP=
thM32iYyYwh8Bi_f68WUp%3DrhYryPj5Ezs4xWPoF%3Dgw%40mail.gmail.com</a>.<br />

--001a11401be00f80520545490122--

.

On 2017-01-04 13:03, Olaf van der Spek wrote:
> 2017-01-04 18:25 GMT+01:00 Matthew Woehlke:
>> Particularly if the separator is itself not known at compile
>> time, how would the compiler know *at compile time* that the separator
>> is a single character? (Even from a known string literal, I'm not sure
>> how you would implement such an optimization... at least without some
>> really deep compiler voodoo, given that we don't (yet) have constexpr
>> parameters...)
>
> Constant propagation, partial inlining? I'm not sure what the right
> term is but compilers might be smarter then you think.

So you would require at least part of the library function to be
available in a header. Hmm...

>> Given:
>>
>>   i = split(input1, ";");
>>   j = split(input2, sep); // 'sep' is known to have strlen(sep) == 1
>>
>> Please explain how the compiler will optimize these to calling an
>> optimized version of `split`. Checking if `sep[1] == 0` at run-time is
>> not permitted.
>
> Why not?
> The split algo is way more expensive then a simple size() == 1 check isn't it?

Because *I don't need it*. If *I* know the separator is a single
character, why should I have to pay that cost, even if it is small?

I don't see where the cost of providing the overload is so high as to
justify its exclusion. (Note that I am assuming that the function is
available internally, as I would have Nasty Things to say about QoI
otherwise. IOW, I am assuming that the implementation cost is virtually
non-existent. Which... it is, because at worst the single character
overload can pass the separator to the string_view overload, even though
that is horrible QoI.)

There's a convenience issue also; if the separator is known to be a
single character, but is not known at compile time, I may be passing it
around as a `char`, `wchar_t`, etc. With an overload, I can split on
this trivially. Without, I have to first construct a string_view of the
character.

On 2017-01-04 13:32, Laurent Navarro wrote:
> The advantage of the runtime optimization is, it happens even if the
> developer specifies "," instead of ',' and I agree to say it's a low-cost
> evaluation to select the right code.

Well, sure, and I'm not suggesting to *not* have the run-time
optimization. But it's still code I can skip if I already know the
separator is a single character. (Again, the separator may not be a
string literal known at compile time.)

--
Matthew

--
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/586D416C.2000609%40gmail.com.

.

2017-01-04 19:39 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> On 2017-01-04 13:03, Olaf van der Spek wrote:
>> 2017-01-04 18:25 GMT+01:00 Matthew Woehlke:
>>> Particularly if the separator is itself not known at compile
>>> time, how would the compiler know *at compile time* that the separator
>>> is a single character? (Even from a known string literal, I'm not sure
>>> how you would implement such an optimization... at least without some
>>> really deep compiler voodoo, given that we don't (yet) have constexpr
>>> parameters...)
>>
>> Constant propagation, partial inlining? I'm not sure what the right
>> term is but compilers might be smarter then you think.
>
> So you would require at least part of the library function to be
> available in a header. Hmm...

No, I'm not.. Link-time-code-generation / whole program optimization..


>> Why not?
>> The split algo is way more expensive then a simple size() == 1 check isn't it?
>
> Because *I don't need it*. If *I* know the separator is a single
> character, why should I have to pay that cost, even if it is small?
>
> I don't see where the cost of providing the overload is so high as to
> justify its exclusion. (Note that I am assuming that the function is
> available internally, as I would have Nasty Things to say about QoI
> otherwise. IOW, I am assuming that the implementation cost is virtually
> non-existent. Which... it is, because at worst the single character
> overload can pass the separator to the string_view overload, even though
> that is horrible QoI.)

I'm not saying the cost is high, I'm merely wondering how big the
benefit of the extra overload is.


--
Olaf

--
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/CAA7U3HMgDpd41nwnPmNQDvg7f7zRgLD3p_PHwhPjccTJQ_qDfw%40mail.gmail.com.

.

--001a11443f0cb1f23105454c29be
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 4, 2017 at 6:42 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> 2017-01-04 19:39 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> >
> > So you would require at least part of the library function to be
> > available in a header. Hmm...
>
> No, I'm not.. Link-time-code-generation / whole program optimization..
>
>
Does anyone link statically against the stdlib? That seems to be the only
case in which LTO could serve any purpose.

--
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/CACGiwhHPTu91Za-SYD01xkpucbZCcC%2BZNf240pKwZEjjz2EJ1A%40mail.gmail.com.

--001a11443f0cb1f23105454c29be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 4, 2017 at 6:42 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">2017-=
01-04 19:39 GMT+01:00 Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@=
gmail.com">mwoehlke.floss@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; So you would require at least part of the library function to be<br>
&gt; available in a header. Hmm...<br>
<br>
</span>No, I&#39;m not.. Link-time-code-generation / whole program optimiza=
tion..<br>
<span class=3D""><br></span></blockquote><div><br></div><div>Does anyone li=
nk statically against the stdlib? That seems to be the only case in which L=
TO could serve any purpose.<br><br></div></div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHPTu91Za-SYD01xkpucbZCcC%2BZNf=
240pKwZEjjz2EJ1A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHPTu91Za=
-SYD01xkpucbZCcC%2BZNf240pKwZEjjz2EJ1A%40mail.gmail.com</a>.<br />

--001a11443f0cb1f23105454c29be--

.

------=_Part_3223_326477567.1483615884960
Content-Type: multipart/alternative;
 boundary="----=_Part_3224_1932410990.1483615884960"

------=_Part_3224_1932410990.1483615884960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Regarding the char overload debate, I've written down arguments on the=20
proposal, done an implementation, and then the committee will decide.

I've added a =C2=A7 on special values to specify how it's supposed to work =
with=20
empty string and an empty separator.

Regarding method vs function debate, I've completed with another test on=20
range-v3 and then selected the method option and let the function as an=20
alternate option, the committee has elements to make another choice.

I have integrated test from N3593 prototype in the updated prototype

I have filled the formal proposed text

Updated proposal here
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_ex=
plode/blob/master/testcpp17_1/formal_proposal.html

Please have a look and give feedback.
Thanks,
  Laurent

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f5700721-2c14-42df-87da-3e4b390969d0%40isocpp.or=
g.

------=_Part_3224_1932410990.1483615884960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>Regarding the char ov=
erload debate, I&#39;ve written down arguments on the proposal, done an imp=
lementation, and then the committee will decide.</div><div><br></div><div>I=
&#39;ve added a =C2=A7 on special values to specify how it&#39;s supposed t=
o work with empty string and an empty separator.</div><div><br></div><div>R=
egarding method vs function debate, I&#39;ve completed with another test on=
 range-v3 and then selected the method option and let the function as an al=
ternate option, the committee has elements to make another choice.</div><di=
v><br></div><div>I have integrated test from N3593 prototype in the updated=
 prototype</div><div><br></div><div>I have filled the formal proposed text<=
/div><div><br></div><div>Updated proposal here</div><div><a href=3D"http://=
htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_explode/b=
lob/master/testcpp17_1/formal_proposal.html">http://htmlpreview.github.io/?=
https://github.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/=
formal_proposal.html</a></div><div><br></div><div>Please have a look and gi=
ve feedback.</div><div>Thanks,</div><div>=C2=A0 Laurent</div><div><br></div=
></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f5700721-2c14-42df-87da-3e4b390969d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f5700721-2c14-42df-87da-3e4b390969d0=
%40isocpp.org</a>.<br />

------=_Part_3224_1932410990.1483615884960--

------=_Part_3223_326477567.1483615884960--

.

Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 22:18:22 PST, D. B. escreveu=
:
> Does anyone link statically against the stdlib? That seems to be the only
> case in which LTO could serve any purpose.

To link statically against the stdlib, you need to link statically against =
ALL=20
your C++ libraries. That's very unlikely.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4866626.aZilGVUeCn%40tjmaciei-mobl1.

.

Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van der S=
pek=20
escreveu:
> I'm not saying the cost is high, I'm merely wondering how big the
> benefit of the extra overload is.

Assuming said function exists (which it should, as I've already said and ca=
n=20
prove with actual code, that such a function is much faster to implement wi=
th=20
SIMD than the longer-string counterpart), the benefit is that the main func=
tion=20
need not be inline and depend on the optimiser figuring out that the consta=
nt=20
string you passed is actually single-character.

It avoids unnecessary overhead of creating a string only to un-create it.

std::vector<std::string> my_split(std::string_view input, char sep)
{
 std::string_view needle(&sep, &sep + 1);
 return split(input, needle);
}

With the stdlib implementation something like:

inline RangeReturnOfSomeKind=20
split(std::string_view haystack, std::string_view needle)
{
 if (needle.size() =3D=3D 1)
  return outofline_split(haystack, needle[0]);
 return outofline_split(haystack, needle);
}

The point is: the single-character function exists. Why not expose it?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1919089.f79W4dt2XZ%40tjmaciei-mobl1.

.

Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van der S=
pek=20
escreveu:
> No, I'm not.. Link-time-code-generation / whole program optimization..

That doesn't apply to non-static libraries.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2149331.tDAzXVpRPH%40tjmaciei-mobl1.

.

2017-01-05 18:01 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van der=
 Spek
> escreveu:
>> No, I'm not.. Link-time-code-generation / whole program optimization..
>
> That doesn't apply to non-static libraries.

Right, my bad.
Wouldn't at least some of the functions be templates though?


--=20
Olaf

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7U3HN2dGxZOMrW1_6z71UJ110jXqV9EmPEFd1DRFGURz2=
dog%40mail.gmail.com.

.

--001a11423f4476d1b705455ca518
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 5, 2017 at 5:54 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> 2017-01-05 18:01 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van d=
er Spek
> > escreveu:
> >> No, I'm not.. Link-time-code-generation / whole program optimization..
> >
> > That doesn't apply to non-static libraries.
>
> Right, my bad.
> Wouldn't at least some of the functions be templates though?
>

Well, sure, but that wasn't the point:

> So you would require at least part of the library function to be
> > available in a header. Hmm...
>
> No, I'm not.. Link-time-code-generation / whole program optimization..
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CACGiwhGmhmzaOxNtAGGY%3DZqC7qGiSWvKyQAUsPcKf5hFf=
%2BL06Q%40mail.gmail.com.

--001a11423f4476d1b705455ca518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 5:54 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><sp=
an class=3D"gmail-">2017-01-05 18:01 GMT+01:00 Thiago Macieira &lt;<a href=
=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt;:<br>
&gt; Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van =
der Spek<br>
&gt; escreveu:<br>
&gt;&gt; No, I&#39;m not.. Link-time-code-generation / whole program optimi=
zation..<br>
&gt;<br>
&gt; That doesn&#39;t apply to non-static libraries.<br>
<br>
</span>Right, my bad.<br>
Wouldn&#39;t at least some of the functions be templates though?<br></block=
quote><div><br></div><div>Well, sure, but that wasn&#39;t the point:<br><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-im"=
>&gt; So you would require at least part of the library function to be</spa=
n><br><span class=3D"gmail-im">
&gt; available in a header. Hmm...</span><br><span class=3D"gmail-im">
</span><br><span class=3D"gmail-im">
</span>No, I&#39;m not.. Link-time-code-generation / whole program optimiza=
tion.. <br></blockquote></div></div></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGmhmzaOxNtAGGY%3DZqC7qGiSWvKyQ=
AUsPcKf5hFf%2BL06Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGmhmza=
OxNtAGGY%3DZqC7qGiSWvKyQAUsPcKf5hFf%2BL06Q%40mail.gmail.com</a>.<br />

--001a11423f4476d1b705455ca518--

.

--001a11401f92b0d5b605455d178d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

I've already created it in the proposal
vector<basic_string_view> splitsv(const typename
basic_string_view::value_type Separator) const

I've just updated the =C2=A7 split by single char and =C2=A7split by regexp=
 that
contains argument exchanged here
both =C2=A7 are integrated to prototype and the proposed text =C2=A7

you can review here
http://htmlpreview.github.io/?https://github.com/laurent-n/cpp17_implode_ex=
plode/blob/master/testcpp17_1/formal_proposal.html

If committee consider there's too much overload they can decide to drop it
but they have argument on the proposal.

Laurent

2017-01-05 18:08 GMT+01:00 Thiago Macieira <thiago@macieira.org>:

> Em quarta-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van der=
 Spek
> escreveu:
> > I'm not saying the cost is high, I'm merely wondering how big the
> > benefit of the extra overload is.
>
> Assuming said function exists (which it should, as I've already said and
> can
> prove with actual code, that such a function is much faster to implement
> with
> SIMD than the longer-string counterpart), the benefit is that the main
> function
> need not be inline and depend on the optimiser figuring out that the
> constant
> string you passed is actually single-character.
>
> It avoids unnecessary overhead of creating a string only to un-create it.
>
> std::vector<std::string> my_split(std::string_view input, char sep)
> {
>         std::string_view needle(&sep, &sep + 1);
>         return split(input, needle);
> }
>
> With the stdlib implementation something like:
>
> inline RangeReturnOfSomeKind
> split(std::string_view haystack, std::string_view needle)
> {
>         if (needle.size() =3D=3D 1)
>                 return outofline_split(haystack, needle[0]);
>         return outofline_split(haystack, needle);
> }
>
> The point is: the single-character function exists. Why not expose it?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/JTKTThJ-7Ko/unsubscribe.
> To unsubscribe from this group and all its topics, 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/1919089.f79W4dt2XZ%40tjmaciei-mobl1.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BfBOqO55xNALdOax7_V9tYw2wrhx0R4B%2BYKWPdJEfp=
L_MXwMw%40mail.gmail.com.

--001a11401f92b0d5b605455d178d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I&#39;ve already created it in t=
he proposal=C2=A0</div><div>vector&lt;basic_string_view&gt; splitsv(const t=
ypename basic_string_view::value_type Separator) const<br></div><div><br></=
div><div>I&#39;ve just updated the =C2=A7=C2=A0split by single char and =C2=
=A7split by regexp that contains argument exchanged here</div><div>both =C2=
=A7 are integrated to prototype and the proposed text =C2=A7</div><div><br>=
</div><div>you can review here=C2=A0</div><div><a href=3D"http://htmlprevie=
w.github.io/?https://github.com/laurent-n/cpp17_implode_explode/blob/master=
/testcpp17_1/formal_proposal.html">http://htmlpreview.github.io/?https://gi=
thub.com/laurent-n/cpp17_implode_explode/blob/master/testcpp17_1/formal_pro=
posal.html</a><br></div><div><br></div><div class=3D"gmail_extra">If commit=
tee consider there&#39;s too much overload they can decide to drop it but t=
hey have argument on the proposal.</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Laurent</div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2017-01-05 18:08 GMT+01:00 Thiago Macieira <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thi=
ago@macieira.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Em quart=
a-feira, 4 de janeiro de 2017, =C3=A0s 19:42:49 PST, Olaf van der Spek<br>
escreveu:<br>
&gt; I&#39;m not saying the cost is high, I&#39;m merely wondering how big =
the<br>
&gt; benefit of the extra overload is.<br>
<br>
Assuming said function exists (which it should, as I&#39;ve already said an=
d can<br>
prove with actual code, that such a function is much faster to implement wi=
th<br>
SIMD than the longer-string counterpart), the benefit is that the main func=
tion<br>
need not be inline and depend on the optimiser figuring out that the consta=
nt<br>
string you passed is actually single-character.<br>
<br>
It avoids unnecessary overhead of creating a string only to un-create it.<b=
r>
<br>
std::vector&lt;std::string&gt; my_split(std::string_view input, char sep)<b=
r>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::string_view needle(&amp;sep, &amp;sep + 1)=
;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return split(input, needle);<br>
}<br>
<br>
With the stdlib implementation something like:<br>
<br>
inline RangeReturnOfSomeKind<br>
split(std::string_view haystack, std::string_view needle)<br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (needle.size() =3D=3D 1)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return outofline_sp=
lit(haystack, needle[0]);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return outofline_split(haystack, needle);<br>
}<br>
<br>
The point is: the single-character function exists. Why not expose it?<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/JTKTThJ-7Ko/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/JTKTThJ-7Ko/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1919089.f79W4dt2XZ%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/1919089.f79W4dt2XZ%<wbr>40tjmaciei-mobl1</=
a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqO55xNALdOax7_V9tYw2wrhx0R4B%=
2BYKWPdJEfpL_MXwMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqO55x=
NALdOax7_V9tYw2wrhx0R4B%2BYKWPdJEfpL_MXwMw%40mail.gmail.com</a>.<br />

--001a11401f92b0d5b605455d178d--

.

------=_Part_91_2087639506.1483899007204
Content-Type: multipart/alternative;
 boundary="----=_Part_92_395039263.1483899007204"

------=_Part_92_395039263.1483899007204
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Hello,

=20

I've updated the proposal here :

https://laurent-n.github.io/cpp17_implode_explode/testcpp17_1/formal_propos=
al.html

=20

I've updated several small stuff and added =C2=A7 (in yellow) :
* Unify name for split methods with a simplified implementation [6]
* Alternate option : split as non-member function : string_split (separated=
=20
from the range returned question)
* comparison with range-v3::split

Please give me your feedback

  Laurent

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6735c7fa-686e-4b2a-8fb7-4465d35dded2%40isocpp.or=
g.

------=_Part_92_395039263.1483899007204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello,</p>
<p>=C2=A0</p>
<p>I&#39;ve updated the proposal here :</p>
<p><a href=3D"https://laurent-n.github.io/cpp17_implode_explode/testcpp17_1=
/formal_proposal.html">https://laurent-n.github.io/cpp17_implode_explode/te=
stcpp17_1/formal_proposal.html</a></p>
<p>=C2=A0</p>
<p>I&#39;ve updated several small stuff and added =C2=A7 (in yellow)=C2=A0:=
<br>* Unify name=20
for split methods with a simplified implementation [6]<br>* Alternate optio=
n :=20
split as non-member function : string_split (separated from the range retur=
ned=20
question)<br>* comparison with range-v3::split<br><br>Please give me your=
=20
feedback</p>
<p>=C2=A0 Laurent</p></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6735c7fa-686e-4b2a-8fb7-4465d35dded2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6735c7fa-686e-4b2a-8fb7-4465d35dded2=
%40isocpp.org</a>.<br />

------=_Part_92_395039263.1483899007204--

------=_Part_91_2087639506.1483899007204--

.

------=_Part_873_815216735.1485022881788
Content-Type: multipart/alternative;
 boundary="----=_Part_874_1228826315.1485022881788"

------=_Part_874_1228826315.1485022881788
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

following some private discussion I've updated the proposal here :
https://laurent-n.github.io/cpp17_implode_explode/testcpp17_1/formal_propos=
al.html

Main change are (tagged in yellow on doc):
* =C2=A73.3 Added a new section with proposals for string level=20
tolower(),toupper() and an icompare() method
* Added the official doc number
* =C2=A73.1.10 added some remarks on non-member approach
* numbered all =C2=A7

Your advice is welcome

Thanks,
  Laurent

PS : you can also just say you agree with this proposal (you can specify=20
which alternate option you prefer) it will give us more weight in the=20
submission process.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bef2f0da-d80b-4539-9833-71a166b1acb2%40isocpp.or=
g.

------=_Part_874_1228826315.1485022881788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>following some private discussio=
n I&#39;ve updated the proposal here :</div><div><a href=3D"https://laurent=
-n.github.io/cpp17_implode_explode/testcpp17_1/formal_proposal.html">https:=
//laurent-n.github.io/cpp17_implode_explode/testcpp17_1/formal_proposal.htm=
l</a><br></div><div><br></div><div>Main change are (tagged in yellow on doc=
):</div><div>* =C2=A73.3 Added a new section with proposals for string leve=
l tolower(),toupper() and an icompare() method</div><div>* Added the offici=
al doc number</div><div>* =C2=A73.1.10 added some remarks on non-member app=
roach</div><div>* numbered all =C2=A7</div><div><br></div><div>Your advice =
is welcome</div><div><br></div><div>Thanks,</div><div>=C2=A0 Laurent</div><=
div><br></div><div>PS : you can also just say you agree with this proposal =
(you can specify which alternate option you prefer) it will give us more we=
ight in the submission process.</div><div><br></div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bef2f0da-d80b-4539-9833-71a166b1acb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bef2f0da-d80b-4539-9833-71a166b1acb2=
%40isocpp.org</a>.<br />

------=_Part_874_1228826315.1485022881788--

------=_Part_873_815216735.1485022881788--

.

------=_Part_2003_461814836.1485283428119
Content-Type: multipart/alternative;
 boundary="----=_Part_2004_1237146643.1485283428119"

------=_Part_2004_1237146643.1485283428119
Content-Type: text/plain; charset=UTF-8

C++ already provides a qualifier for member functions of temporary objects:

// t.cpp#include <iostream>
struct test{
  void split() & { std::cout << "lvalue object\n"; }
  void split() && { std::cout << "rvalue object\n"; }
};
int main(){
  test t;
  t.split(); // lvalue
  test().split(); // rvalue
}


Have you thought about only having two "overloads" of split, instead of two
functions splitsv and splits?
This would reduce the amount of knowledge necessary to write proper
(working) code. You can still force one or the other method.

Cheers,
Jakob

--
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/d8dc5331-cad5-4c54-850c-416258f30847%40isocpp.org.

------=_Part_2004_1237146643.1485283428119
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">C++ already provides a qualifier for member functions of t=
emporary objects:<div><br></div><div><pre class=3D"lang-cpp prettyprint pre=
ttyprinted" style=3D"padding: 5px; width: auto; max-height: 600px; overflow=
: auto; font-family: Consolas, Menlo, Monaco, &quot;Lucida Console&quot;, &=
quot;Liberation Mono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bitstream V=
era Sans Mono&quot;, &quot;Courier New&quot;, monospace, sans-serif; backgr=
ound-color: rgb(239, 240, 241); color: rgb(57, 51, 24); word-wrap: normal;"=
><code style=3D"font-family: Consolas, Menlo, Monaco, &quot;Lucida Console&=
quot;, &quot;Liberation Mono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bit=
stream Vera Sans Mono&quot;, &quot;Courier New&quot;, monospace, sans-serif=
; white-space: inherit;"><span class=3D"com" style=3D"color: rgb(133, 140, =
147);">// t.cpp</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);"=
>
</span><span class=3D"com" style=3D"color: rgb(133, 140, 147);">#include</s=
pan><span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> </span><span cla=
ss=3D"str" style=3D"color: rgb(125, 39, 39);">&lt;iostream&gt;</span><span =
class=3D"pln" style=3D"color: rgb(48, 51, 54);">

</span><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">struct</span>=
<span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> test</span><span cla=
ss=3D"pun" style=3D"color: rgb(48, 51, 54);">{</span><span class=3D"pln" st=
yle=3D"color: rgb(48, 51, 54);">
  </span><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">void</span>=
<span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> split</span><span cl=
ass=3D"pun" style=3D"color: rgb(48, 51, 54);">()</span><span class=3D"pln" =
style=3D"color: rgb(48, 51, 54);"> </span><span class=3D"pun" style=3D"colo=
r: rgb(48, 51, 54);">&amp; {</span><span class=3D"pln" style=3D"color: rgb(=
48, 51, 54);"> std</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54=
);">::</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">cout </s=
pan><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">&lt;&lt;</span><s=
pan class=3D"pln" style=3D"color: rgb(48, 51, 54);"> </span><span class=3D"=
str" style=3D"color: rgb(125, 39, 39);">&quot;lvalue object\n&quot;</span><=
span class=3D"pun" style=3D"color: rgb(48, 51, 54);">;</span><span class=3D=
"pln" style=3D"color: rgb(48, 51, 54);"> </span><span class=3D"pun" style=
=3D"color: rgb(48, 51, 54);">}</span><span class=3D"pln" style=3D"color: rg=
b(48, 51, 54);">
  </span><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">void</span>=
<span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> split()<span class=
=3D"pln" style=3D"white-space: inherit;"> </span><span class=3D"pun" style=
=3D"white-space: inherit;">&amp;&amp; {</span><span class=3D"pln" style=3D"=
white-space: inherit;"> std</span><span class=3D"pun" style=3D"white-space:=
 inherit;">::</span><span class=3D"pln" style=3D"white-space: inherit;">cou=
t </span><span class=3D"pun" style=3D"white-space: inherit;">&lt;&lt;</span=
><span class=3D"pln" style=3D"white-space: inherit;"> </span><span class=3D=
"str" style=3D"white-space: inherit; color: rgb(125, 39, 39);">&quot;rvalue=
 object\n&quot;</span><span class=3D"pun" style=3D"white-space: inherit;">;=
</span><span class=3D"pln" style=3D"white-space: inherit;"> </span><span cl=
ass=3D"pun" style=3D"white-space: inherit;">}</span><br></span><span class=
=3D"pun" style=3D"color: rgb(48, 51, 54);">};</span><span class=3D"pln" sty=
le=3D"color: rgb(48, 51, 54);">

</span><span class=3D"typ" style=3D"color: rgb(43, 145, 175);">int</span><s=
pan class=3D"pln" style=3D"color: rgb(48, 51, 54);"> main</span><span class=
=3D"pun" style=3D"color: rgb(48, 51, 54);">(){</span><span class=3D"pln" st=
yle=3D"color: rgb(48, 51, 54);">
  test t</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">;</spa=
n><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">
  t</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">.split();<s=
pan class=3D"pln" style=3D"white-space: inherit;"> </span><span class=3D"co=
m" style=3D"white-space: inherit; color: rgb(133, 140, 147);">// lvalue</sp=
an><br></span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">  test<=
/span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">().split();<spa=
n class=3D"pln" style=3D"white-space: inherit;"> </span><span class=3D"com"=
 style=3D"white-space: inherit; color: rgb(133, 140, 147);">// rvalue</span=
><br></span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">}</span><=
/code></pre></div><div><br></div><div>Have you thought about only having tw=
o &quot;overloads&quot; of split, instead of two functions splitsv and spli=
ts?</div><div>This would reduce the amount of knowledge necessary to write =
proper (working) code. You can still force one or the other method.</div><d=
iv><br></div><div>Cheers,</div><div>Jakob</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d8dc5331-cad5-4c54-850c-416258f30847%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d8dc5331-cad5-4c54-850c-416258f30847=
%40isocpp.org</a>.<br />

------=_Part_2004_1237146643.1485283428119--

------=_Part_2003_461814836.1485283428119--

.

--94eb2c1a1e1a1c0f470546eec310
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Yes I've already thinked about avoiding s/sv suffix in =C2=A73.1.5

Your proposal is a smart solution, I've added it as alternative in =C2=A73.=
1.5
in yellow.
Please review and let me know if you want add precision.
Having a varying return type (not just specifier) could be consider as non
conventional, I let this point (and several others ones) at the
appreciation of the committee

Thanks for your contribution
  Laurent


2017-01-24 19:43 GMT+01:00 Jakob Riedle <jakob.riedle@gmail.com>:

> C++ already provides a qualifier for member functions of temporary object=
s:
>
> // t.cpp#include <iostream>
> struct test{
>   void split() & { std::cout << "lvalue object\n"; }
>   void split() && { std::cout << "rvalue object\n"; }
> };
> int main(){
>   test t;
>   t.split(); // lvalue
>   test().split(); // rvalue
> }
>
>
> Have you thought about only having two "overloads" of split, instead of
> two functions splitsv and splits?
> This would reduce the amount of knowledge necessary to write proper
> (working) code. You can still force one or the other method.
>
> Cheers,
> Jakob
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BfBOqMkpJ0Q0c17xO0M8WeYCncqAjeDBqkkfG_jWocf5=
-g8eA%40mail.gmail.com.

--94eb2c1a1e1a1c0f470546eec310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>Yes I&#39;ve already thinked abo=
ut avoiding s/sv suffix in =C2=A73.1.5</div><div><br></div><div>Your propos=
al is a smart solution, I&#39;ve added it as alternative in =C2=A73.1.5 in =
yellow.</div><div>Please review and let me know if you want add precision.<=
/div><div>Having a varying return type (not just specifier) could be consid=
er as non conventional, I let this point (and several others ones) at the a=
ppreciation of the committee=C2=A0</div><div><br></div><div>Thanks for your=
 contribution</div><div>=C2=A0 Laurent</div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-01-24 19:43 GMT+01:00 =
Jakob Riedle <span dir=3D"ltr">&lt;<a href=3D"mailto:jakob.riedle@gmail.com=
" target=3D"_blank">jakob.riedle@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">C++ already provides a qualifier for mem=
ber functions of temporary objects:<div><br></div><div><pre class=3D"m_6827=
721735054066054lang-cpp m_6827721735054066054prettyprint m_6827721735054066=
054prettyprinted" style=3D"padding:5px;width:auto;max-height:600px;overflow=
:auto;font-family:Consolas,Menlo,Monaco,&quot;Lucida Console&quot;,&quot;Li=
beration Mono&quot;,&quot;DejaVu Sans Mono&quot;,&quot;Bitstream Vera Sans =
Mono&quot;,&quot;Courier New&quot;,monospace,sans-serif;background-color:rg=
b(239,240,241);color:rgb(57,51,24);word-wrap:normal"><code style=3D"font-fa=
mily:Consolas,Menlo,Monaco,&quot;Lucida Console&quot;,&quot;Liberation Mono=
&quot;,&quot;DejaVu Sans Mono&quot;,&quot;Bitstream Vera Sans Mono&quot;,&q=
uot;Courier New&quot;,monospace,sans-serif;white-space:inherit"><span class=
=3D"m_6827721735054066054com" style=3D"color:rgb(133,140,147)">// t.cpp</sp=
an><span class=3D"m_6827721735054066054pln" style=3D"color:rgb(48,51,54)">
</span><span class=3D"m_6827721735054066054com" style=3D"color:rgb(133,140,=
147)">#include</span><span class=3D"m_6827721735054066054pln" style=3D"colo=
r:rgb(48,51,54)"> </span><span class=3D"m_6827721735054066054str" style=3D"=
color:rgb(125,39,39)">&lt;iostream&gt;</span><span class=3D"m_6827721735054=
066054pln" style=3D"color:rgb(48,51,54)">

</span><span class=3D"m_6827721735054066054kwd" style=3D"color:rgb(16,16,14=
8)">struct</span><span class=3D"m_6827721735054066054pln" style=3D"color:rg=
b(48,51,54)"> test</span><span class=3D"m_6827721735054066054pun" style=3D"=
color:rgb(48,51,54)">{</span><span class=3D"m_6827721735054066054pln" style=
=3D"color:rgb(48,51,54)">
  </span><span class=3D"m_6827721735054066054kwd" style=3D"color:rgb(16,16,=
148)">void</span><span class=3D"m_6827721735054066054pln" style=3D"color:rg=
b(48,51,54)"> split</span><span class=3D"m_6827721735054066054pun" style=3D=
"color:rgb(48,51,54)">()</span><span class=3D"m_6827721735054066054pln" sty=
le=3D"color:rgb(48,51,54)"> </span><span class=3D"m_6827721735054066054pun"=
 style=3D"color:rgb(48,51,54)">&amp; {</span><span class=3D"m_6827721735054=
066054pln" style=3D"color:rgb(48,51,54)"> std</span><span class=3D"m_682772=
1735054066054pun" style=3D"color:rgb(48,51,54)">::</span><span class=3D"m_6=
827721735054066054pln" style=3D"color:rgb(48,51,54)">cout </span><span clas=
s=3D"m_6827721735054066054pun" style=3D"color:rgb(48,51,54)">&lt;&lt;</span=
><span class=3D"m_6827721735054066054pln" style=3D"color:rgb(48,51,54)"> </=
span><span class=3D"m_6827721735054066054str" style=3D"color:rgb(125,39,39)=
">&quot;lvalue object\n&quot;</span><span class=3D"m_6827721735054066054pun=
" style=3D"color:rgb(48,51,54)">;</span><span class=3D"m_682772173505406605=
4pln" style=3D"color:rgb(48,51,54)"> </span><span class=3D"m_68277217350540=
66054pun" style=3D"color:rgb(48,51,54)">}</span><span class=3D"m_6827721735=
054066054pln" style=3D"color:rgb(48,51,54)">
  </span><span class=3D"m_6827721735054066054kwd" style=3D"color:rgb(16,16,=
148)">void</span><span class=3D"m_6827721735054066054pln" style=3D"color:rg=
b(48,51,54)"> split()<span class=3D"m_6827721735054066054pln" style=3D"whit=
e-space:inherit"> </span><span class=3D"m_6827721735054066054pun" style=3D"=
white-space:inherit">&amp;&amp; {</span><span class=3D"m_682772173505406605=
4pln" style=3D"white-space:inherit"> std</span><span class=3D"m_68277217350=
54066054pun" style=3D"white-space:inherit">::</span><span class=3D"m_682772=
1735054066054pln" style=3D"white-space:inherit">cout </span><span class=3D"=
m_6827721735054066054pun" style=3D"white-space:inherit">&lt;&lt;</span><spa=
n class=3D"m_6827721735054066054pln" style=3D"white-space:inherit"> </span>=
<span class=3D"m_6827721735054066054str" style=3D"white-space:inherit;color=
:rgb(125,39,39)">&quot;rvalue object\n&quot;</span><span class=3D"m_6827721=
735054066054pun" style=3D"white-space:inherit">;</span><span class=3D"m_682=
7721735054066054pln" style=3D"white-space:inherit"> </span><span class=3D"m=
_6827721735054066054pun" style=3D"white-space:inherit">}</span><br></span><=
span class=3D"m_6827721735054066054pun" style=3D"color:rgb(48,51,54)">};</s=
pan><span class=3D"m_6827721735054066054pln" style=3D"color:rgb(48,51,54)">

</span><span class=3D"m_6827721735054066054typ" style=3D"color:rgb(43,145,1=
75)">int</span><span class=3D"m_6827721735054066054pln" style=3D"color:rgb(=
48,51,54)"> main</span><span class=3D"m_6827721735054066054pun" style=3D"co=
lor:rgb(48,51,54)">(){</span><span class=3D"m_6827721735054066054pln" style=
=3D"color:rgb(48,51,54)">
  test t</span><span class=3D"m_6827721735054066054pun" style=3D"color:rgb(=
48,51,54)">;</span><span class=3D"m_6827721735054066054pln" style=3D"color:=
rgb(48,51,54)">
  t</span><span class=3D"m_6827721735054066054pun" style=3D"color:rgb(48,51=
,54)">.split();<span class=3D"m_6827721735054066054pln" style=3D"white-spac=
e:inherit"> </span><span class=3D"m_6827721735054066054com" style=3D"white-=
space:inherit;color:rgb(133,140,147)">// lvalue</span><br></span><span clas=
s=3D"m_6827721735054066054pln" style=3D"color:rgb(48,51,54)">  test</span><=
span class=3D"m_6827721735054066054pun" style=3D"color:rgb(48,51,54)">().sp=
lit();<span class=3D"m_6827721735054066054pln" style=3D"white-space:inherit=
"> </span><span class=3D"m_6827721735054066054com" style=3D"white-space:inh=
erit;color:rgb(133,140,147)">// rvalue</span><br></span><span class=3D"m_68=
27721735054066054pun" style=3D"color:rgb(48,51,54)">}</span></code></pre></=
div><div><br></div><div>Have you thought about only having two &quot;overlo=
ads&quot; of split, instead of two functions splitsv and splits?</div><div>=
This would reduce the amount of knowledge necessary to write proper (workin=
g) code. You can still force one or the other method.</div><div><br></div><=
div>Cheers,</div><div>Jakob</div></div></blockquote></div><br></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMkpJ0Q0c17xO0M8WeYCncqAjeDBq=
kkfG_jWocf5-g8eA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfBOqMkpJ0Q=
0c17xO0M8WeYCncqAjeDBqkkfG_jWocf5-g8eA%40mail.gmail.com</a>.<br />

--94eb2c1a1e1a1c0f470546eec310--

.

Le 21/01/2017 =C3=A0 19:21, lnaltidev@gmail.com a =C3=A9crit :
> Hello,
>
> following some private discussion I've updated the proposal here :
> https://laurent-n.github.io/cpp17_implode_explode/testcpp17_1/formal_prop=
osal.html
>
> Main change are (tagged in yellow on doc):
> * =C2=A73.3 Added a new section with proposals for string level=20
> tolower(),toupper() and an icompare() method
> * Added the official doc number
> * =C2=A73.1.10 added some remarks on non-member approach
> * numbered all =C2=A7
>

Hi,

I understand that we could want functions at the user level, but ...

.... I'm wondering if split shouldn't return a type providing
* a range interface,
* a monadic interface, ...

for (s : str.split(sep)) { fct(s)};

str.split(sep).transform(fct);


Vicente

P.S. make use of functional notation if you prefer.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d884fc70-bd53-303c-7575-ff313f96adca%40wanadoo.f=
r.

.

------=_Part_59_1304628310.1485392403179
Content-Type: multipart/alternative;
 boundary="----=_Part_60_1793086159.1485392403179"

------=_Part_60_1793086159.1485392403179
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, January 25, 2017 at 6:50:07 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 21/01/2017 =C3=A0 19:21, lnal...@gmail.com <javascript:> a =C3=A9crit =
:=20
> > Hello,=20
> >=20
> > following some private discussion I've updated the proposal here :=20
> >=20
> https://laurent-n.github.io/cpp17_implode_explode/testcpp17_1/formal_prop=
osal.html=20
> >=20
> > Main change are (tagged in yellow on doc):=20
> > * =C2=A73.3 Added a new section with proposals for string level=20
> > tolower(),toupper() and an icompare() method=20
> > * Added the official doc number=20
> > * =C2=A73.1.10 added some remarks on non-member approach=20
> > * numbered all =C2=A7=20
> >=20
>
> Hi,=20
>
> I understand that we could want functions at the user level, but ...=20
>
> ... I'm wondering if split shouldn't return a type providing=20
> * a range interface,=20
> * a monadic interface, ...=20
>
> for (s : str.split(sep)) { fct(s)};=20
>
> str.split(sep).transform(fct);
>

Ranges are becoming the standard way to do this. Piping from one range to=
=20
another will be done via `str.split(sep) | transform(fct)`, not via a=20
direct function call like that.

So a range interface is all that's needed.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f2f9d305-68c2-4d4d-99f0-db0fe56f2f27%40isocpp.or=
g.

------=_Part_60_1793086159.1485392403179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, January 25, 2017 at 6:50:07 PM UTC-5=
, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">Le 21/01/2017 =C3=A0 19:21, <a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"gdRbOVB_AgAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">lnal...@gmail.com</a> a =C3=A9crit :
<br>&gt; Hello,
<br>&gt;
<br>&gt; following some private discussion I&#39;ve updated the proposal he=
re :
<br>&gt; <a href=3D"https://laurent-n.github.io/cpp17_implode_explode/testc=
pp17_1/formal_proposal.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaurent-=
n.github.io%2Fcpp17_implode_explode%2Ftestcpp17_1%2Fformal_proposal.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE0inpMwHrrP3eKQGjl9To0BpbSZw&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Flaurent-n.github.io%2Fcpp17_implode_explode%2Ftestcpp17_1%2Fforma=
l_proposal.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE0inpMwHrrP3eKQGjl9=
To0BpbSZw&#39;;return true;">https://laurent-n.github.io/<wbr>cpp17_implode=
_explode/<wbr>testcpp17_1/formal_proposal.<wbr>html</a>
<br>&gt;
<br>&gt; Main change are (tagged in yellow on doc):
<br>&gt; * =C2=A73.3 Added a new section with proposals for string level=20
<br>&gt; tolower(),toupper() and an icompare() method
<br>&gt; * Added the official doc number
<br>&gt; * =C2=A73.1.10 added some remarks on non-member approach
<br>&gt; * numbered all =C2=A7
<br>&gt;
<br>
<br>Hi,
<br>
<br>I understand that we could want functions at the user level, but ...
<br>
<br>... I&#39;m wondering if split shouldn&#39;t return a type providing
<br>* a range interface,
<br>* a monadic interface, ...
<br>
<br>for (s : str.split(sep)) { fct(s)};
<br>
<br>str.split(sep).transform(fct);<br></blockquote><div><br>Ranges are beco=
ming the standard way to do this. Piping from one range to another will be =
done via `str.split(sep) | transform(fct)`, not via a direct function call =
like that.<br><br>So a range interface is all that&#39;s needed.<br></div><=
/div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f2f9d305-68c2-4d4d-99f0-db0fe56f2f27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2f9d305-68c2-4d4d-99f0-db0fe56f2f27=
%40isocpp.org</a>.<br />

------=_Part_60_1793086159.1485392403179--

------=_Part_59_1304628310.1485392403179--

.

------=_Part_17547_915116741.1525028162458
Content-Type: multipart/alternative;
 boundary="----=_Part_17548_1673914992.1525028162459"

------=_Part_17548_1673914992.1525028162459
Content-Type: text/plain; charset="UTF-8"

Hello,

here a new version of the proposal https://www.altidev.fr/ln/p0540r2.html

Main changes are :
    Removed case management features to focus to the main subject of the
proposal
    Added split by set of char
    Added some performance comparison
    Added comparisons with existing solutions

Let me know if you have any suggestion.

I'm looking for a presenter at the next Rapperswil (or any others meeting),
if there's any candidate please le me know.

Thanks
  Laurent

--
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/34316236-4e57-4084-8ff1-96a8ec6e6417%40isocpp.org.

------=_Part_17548_1673914992.1525028162459
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>here a new version of the propos=
al=C2=A0https://www.altidev.fr/ln/p0540r2.html</div><div><br></div><div>Mai=
n changes are :</div><div><div>=C2=A0 =C2=A0 Removed case management featur=
es to focus to the main subject of the proposal<br></div><div>=C2=A0 =C2=A0=
 Added split by set of char</div><div>=C2=A0 =C2=A0 Added some performance =
comparison</div><div>=C2=A0 =C2=A0 Added comparisons with existing solution=
s</div></div><div><br></div><div>Let me know if you have any suggestion.</d=
iv><div><br></div><div>I&#39;m looking for a presenter at the next Rappersw=
il (or any others meeting), if there&#39;s any candidate please le me know.=
</div><div><br></div><div>Thanks</div><div>=C2=A0 Laurent</div></div>

<p></p>

-- <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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34316236-4e57-4084-8ff1-96a8ec6e6417%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34316236-4e57-4084-8ff1-96a8ec6e6417=
%40isocpp.org</a>.<br />

------=_Part_17548_1673914992.1525028162459--

------=_Part_17547_915116741.1525028162458--

.