Topic: [RFC] Variadic Operators
Author: Manuel Freiberger <manuel.freiberger@gmail.com>
Date: Tue, 30 Jan 2018 12:45:48 -0800 (PST)
Raw View
------=_Part_15289_353415927.1517345148050
Content-Type: multipart/alternative;
boundary="----=_Part_15290_95545336.1517345148050"
------=_Part_15290_95545336.1517345148050
Content-Type: text/plain; charset="UTF-8"
Hi all,
I would like to gather some feedback on a proposal to make the binary C++
operators variadic.
I haven't seen such a proposal yet so pointers to related (also rejected
proposals) are highly
welcome.
* Why would such a thing be useful?
Naturally a binary operator only 'sees' its immediate neighboring
arguments. This can lead
to inefficient code in some circumstances. A prominent example is the
concatenation of long
strings with operator+():
std::string a = some_long_string();
std::string b = another_long_string();
std::string c = yet_another_long_string();
std::string z = a + b + c;
The creation of z is actually done in two steps similar to
std::string temp = a + b;
std::string z = std::move(temp) + c;
Although temp can be moved, it is unlikely that the memory allocated for (a
+ b) is sufficient
to also hold c. So memory needs to be allocated twice and in total 5
strings are copied (a and
b are copied twice, c once). The only chance is that the compiler is smart
enough to merge
the memory allocations into a single call and to eliminate the redundant
copy operations.
The solution is to use a variadic function like Abseil's StrCat() [1], for
example. Since the
function sees all strings at once, it can sum up their sizes, allocate the
final memory once
and copy one string after another to the output.
Another alternative is to change operator+() to return a proxy (aka
Expression Templates),
which stores references to the strings. When the proxy is assigned to the
string, it performs
the same operations as StrCat() above. While this approach is highly
flexible (one can combine
different kinds of operators just as in an AST), it involves quite some
code. One has to take
care that the references are consumed before the life-time of the objects
end, which can be
tricky if one of the strings is a temporary, for example.
* How would a variadic operator help?
A variadic operator+() would take two or more arguments. For the string
concatenation
use case, one could define a series of operator+(), each taking one more
argument
std::string operator+(const std::string& a, const std::string& b);
std::string operator+(const std::string& a, const std::string& b, const
std::string& c);
std::string operator+(const std::string& a, const std::string& b, const
std::string& c,
const std::string& d);
or simply use a variadic template function:
template <typename... T>
std::string operator+(const std::string& a, const std::string& b, T...
rest)
{
// compute the final size first
auto total_size = a.size() + b.size() + (rest.size() + ...);
if (total_size == 0)
return std::string();
// allocate enough space for the result
std::string result(total_size, '\0');
// and copy the input strings
auto iter = result.begin();
iter = std::copy(a.cbegin(), a.cend(), iter);
iter = std::copy(b.cbegin(), b.cend(), iter);
(void(iter = std::copy(rest.cbegin(), rest.cend(), iter)), ...);
return result;
}
Under the hood, the expression
std::string z = a + b + c;
would result in the operator call
std::string z = operator+(a, b, c);
This code is more efficient than a chain of calls to binary operator+(). It
is also a lot
easier to implement compared to an solution involving proxies/Expression
Templates. Note that
a proper implementation would constrain the elements of the parameter pack
to be of type
std::string (any maybe derived classes).
If a parameter pack is used in an operator definition, there must also be
two additional
parameters (so that the operator has at least two parameters). This is to
avoid that an
operator definition could be used both as unary and binary (or n-ary)
operator at the same
time. It also prevents the definition of an operator without parameters at
all (like the
conversion operators).
* How would that work in the compiler?
Right now the compiler parses a sequence of @-operators (with @ being one
of the binary
left-associative operators, e.g. + - * / % & | < > etc)
a @ b @ c @ d @ e
into an AST
operator@(operator@(operator@(operator@(a, b), c), d), e)
Now the new behavior: Before the compiler performs the name lookup, it
recursively takes the
arguments of the inner-most operator@() call and lifts them to the next
operator@(). For the
example above this would lead to the following additional expressions:
operator@(operator@(operator@(a, b, c), d), e)
operator@(operator@(a, b, c, d), e)
operator@(a, b, c, d, e)
Then the name lookup is performed for every expression in this sequence
starting with the
longest parameter chain. If no match is found, that expression is simply
ignored (much like
SFINAE). The lookup is also skipped if none of the parameters is of
class-or enumeration-type.
This is to avoid hijacking the built-in operators for fundamental types. An
error is emitted
only when the lookup for the binary operators fail.
Right-associative operators would behave similar but the parameters are
concatenated from the
right. So for this expression
a $ b $ c $ d
the compiler will try to find matching operators in the following order:
operator$(a, b, c, d)
operator$(a, operator$(b, c, d))
operator$(a, operator$(b, operator$(c, d)))
* What else could I do with variadic operators?
- Efficient vector math
template <typename... T>
Vector operator+(const Vector& a, const Vector& b, T... rest)
{
Vector r(a.size());
for (int i = 0; i < a.size(); ++i) // loop only once over
the elements
r[i] = a[i] + b[i] + (rest[i] + ...); // sum the components of
all vectors
return r;
}
- Locked streaming
struct locked_stream
{
template <typename T, typename... TRest>
locked_stream& operator<<(const T& t, const TRest&... rest)
{
std::lock_guard<std::mutex> lock(m_mutex); // acquire the lock
once
m_out << t;
(void(m_out << rest), ...); // and stream all
arguments
return *this;
}
std::mutex m_mutex;
std::ostream& m_out;
};
- Python-like comparison chains:
template <typename... T>
bool operator<(Number a, Number b, T... rest)
{
if constexpr (sizeof...(rest) == 0)
return int(a) < int(b);
else
return int(a) < int(b) && operator<(b, rest...);
}
if (Number(1) < Number(10) < Number(50) < Number(70)) // ... Number(1)
< Number(10) && Number(10) < Number(50)
std::cout << "ordered" << std::endl; // &&
Number(50) < Number(70)
Thoughts?
Kind regards,
Manuel
[1] https://abseil.io/tips/3
--
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/55b7acd5-4328-462c-945e-fbbe074fb30e%40isocpp.org.
------=_Part_15290_95545336.1517345148050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family: courier\ new, monospace;">Hi a=
ll,<br><br>I would like to gather some feedback on a proposal to make the b=
inary C++ operators variadic.<br>I haven't seen such a proposal yet so =
pointers to related (also rejected proposals) are highly<br>welcome.<br><br=
><br>* Why would such a thing be useful?<br><br>Naturally a binary operator=
only 'sees' its immediate neighboring arguments. This can lead<br>=
to inefficient code in some circumstances. A prominent example is the conca=
tenation of long<br>strings with operator+():<br><br>=C2=A0=C2=A0=C2=A0 std=
::string a =3D some_long_string();<br>=C2=A0=C2=A0=C2=A0 std::string b =3D =
another_long_string();<br>=C2=A0=C2=A0=C2=A0 std::string c =3D yet_another_=
long_string();<br>=C2=A0=C2=A0=C2=A0 std::string z =3D a + b + c;<br><br>Th=
e creation of z is actually done in two steps similar to<br><br>=C2=A0=C2=
=A0=C2=A0 std::string temp =3D a + b;<br>=C2=A0=C2=A0=C2=A0 std::string z =
=3D std::move(temp) + c;<br><br>Although temp can be moved, it is unlikely =
that the memory allocated for (a + b) is sufficient<br>to also hold c. So m=
emory needs to be allocated twice and in total 5 strings are copied (a and<=
br>b are copied twice, c once). The only chance is that the compiler is sma=
rt enough to merge<br>the memory allocations into a single call and to elim=
inate the redundant copy operations.<br><br>The solution is to use a variad=
ic function like Abseil's StrCat() [1], for example. Since the<br>funct=
ion sees all strings at once, it can sum up their sizes, allocate the final=
memory once<br>and copy one string after another to the output.<br><br>Ano=
ther alternative is to change operator+() to return a proxy (aka Expression=
Templates),<br>which stores references to the strings. When the proxy is a=
ssigned to the string, it performs<br>the same operations as StrCat() above=
.. While this approach is highly flexible (one can combine<br>different kind=
s of operators just as in an AST), it involves quite some code. One has to =
take<br>care that the references are consumed before the life-time of the o=
bjects end, which can be<br>tricky if one of the strings is a temporary, fo=
r example.<br><br><br>* How would a variadic operator help?<br><br>A variad=
ic operator+() would take two or more arguments. For the string concatenati=
on<br>use case, one could define a series of operator+(), each taking one m=
ore argument<br><br>=C2=A0=C2=A0=C2=A0 std::string operator+(const std::str=
ing& a, const std::string& b);<br>=C2=A0=C2=A0=C2=A0 std::string op=
erator+(const std::string& a, const std::string& b, const std::stri=
ng& c);<br>=C2=A0=C2=A0=C2=A0 std::string operator+(const std::string&a=
mp; a, const std::string& b, const std::string& c,<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const std::=
string& d);<br><br>or simply use a variadic template function:<br><br>=
=C2=A0=C2=A0=C2=A0 template <typename... T><br>=C2=A0=C2=A0=C2=A0 std=
::string operator+(const std::string& a, const std::string& b, T...=
rest)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 // compute the final size first<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 auto total_size =3D a.size() + b.size() + (rest.size() + ...);<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (total_size =3D=3D 0)<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std:=
:string();<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // allocate en=
ough space for the result<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std=
::string result(total_size, '\0');<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 // and copy the input strings<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 auto iter =3D result.begin();<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 iter =3D std::copy(a.cbegin(), a.cend(), iter);<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iter =3D std::copy(b.cbegin(), b=
..cend(), iter);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (void(iter =
=3D std::copy(rest.cbegin(), rest.cend(), iter)), ...);<br><br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return result;<br>=C2=A0=C2=A0=C2=A0 }<br><b=
r>Under the hood, the expression<br></span><span style=3D"font-family: cour=
ier\ new, monospace;"><span style=3D"font-family: courier\ new, monospace;"=
>=C2=A0=C2=A0=C2=A0 std::string z =3D a + b + c;<br>would result in the ope=
rator call<br>=C2=A0=C2=A0=C2=A0 std::string z =3D operator+(a, b, c);<br><=
br></span>This code is more efficient than a chain of calls to binary opera=
tor+(). It is also a lot<br>easier to implement compared to an solution inv=
olving proxies/Expression Templates. Note that<br>a proper implementation w=
ould constrain the elements of the parameter pack to be of type<br>std::str=
ing (any maybe derived classes).<br><br>If a parameter pack is used in an o=
perator definition, there must also be two additional<br>parameters (so tha=
t the operator has at least two parameters). This is to avoid that an<br>op=
erator definition could be used both as unary and binary (or n-ary) operato=
r at the same<br>time. It also prevents the definition of an operator witho=
ut parameters at all (like the<br>conversion operators).<br><br><br>* How w=
ould that work in the compiler?<br><br>Right now the compiler parses a sequ=
ence of @-operators (with @ being one of the binary<br>left-associative ope=
rators, e.g. + - * / % & | < > etc)<br>=C2=A0=C2=A0=C2=A0 a @ b @=
c @ d @ e<br>into an AST<br>=C2=A0=C2=A0=C2=A0 operator@(operator@(operato=
r@(operator@(a, b), c), d), e)<br><br>Now the new behavior: Before the comp=
iler performs the name lookup, it recursively takes the<br>arguments of the=
inner-most operator@() call and lifts them to the next operator@(). For th=
e<br>example above this would lead to the following additional expressions:=
<br></span><span style=3D"font-family: courier\ new, monospace;"><span styl=
e=3D"font-family: courier\ new, monospace;"><code class=3D"prettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0=C2=A0=C2=A0 o=
perator@(operator@(operator@(a, b, c), d), e)<br>=C2=A0=C2=A0=C2=A0 operato=
r@(operator@(a, b, c, d), e)<br>=C2=A0=C2=A0=C2=A0 operator@(a, b, c, d, e)=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><br></span=
></code></span></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"></span><br><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
/span><span style=3D"font-family: courier\ new, monospace;"><span style=3D"=
font-family: courier\ new, monospace;"><code class=3D"prettyprint"></code><=
/span></span><span style=3D"font-family: courier\ new, monospace;"><span st=
yle=3D"font-family: courier\ new, monospace;"></span></span><span style=3D"=
font-family: courier\ new, monospace;"><br>Then the name lookup is performe=
d for every expression in this sequence starting with the<br>longest parame=
ter chain. If no match is found, that expression is simply ignored (much li=
ke<br>SFINAE). The lookup is also skipped if none of the parameters is of c=
lass-or enumeration-type.<br>This is to avoid hijacking the built-in operat=
ors for fundamental types. An error is emitted<br>only when the lookup for =
the binary operators fail.<br><br>Right-associative operators would behave =
similar but the parameters are concatenated from the<br>right. So for this =
expression<br>=C2=A0=C2=A0=C2=A0 a $ b $ c $ d<br>the compiler will try to =
find matching operators in the following order:<br>=C2=A0=C2=A0=C2=A0 opera=
tor$(a, b, c, d)<br>=C2=A0=C2=A0=C2=A0 operator$(a, operator$(b, c, d))<br>=
=C2=A0=C2=A0=C2=A0 operator$(a, operator$(b, operator$(c, d)))<br><br><br>*=
What else could I do with variadic operators?<br><br>- Efficient vector ma=
th<br><br>=C2=A0=C2=A0=C2=A0 template <typename... T><br>=C2=A0=C2=A0=
=C2=A0 Vector operator+(const Vector& a, const Vector& b, T... rest=
)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vec=
tor r(a.size());<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i =
=3D 0; i < a.size(); ++i)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 // loop only once over the elements<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r[i] =3D a[i] + b[i] + (rest[i] + ...)=
;=C2=A0 // sum the components of all vectors<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 return r;<br>=C2=A0=C2=A0=C2=A0 }<br><br><br>- Locked strea=
ming<br><br>=C2=A0=C2=A0=C2=A0 struct locked_stream<br>=C2=A0=C2=A0=C2=A0 {=
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template <typename T, typ=
ename... TRest><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locked_str=
eam& operator<<(const T& t, const TRest&... rest)<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::lock_guard<std::mutex> lock=
(m_mutex);=C2=A0 // acquire the lock once<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 m_out << t;<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (void(m_out << re=
st), ...);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // and stream all arguments<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return *this;<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::mutex m_mutex;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::ostream& m_out;<br>=C2=A0=C2=A0=C2=A0 };<br><br><br>-=
Python-like comparison chains:<br><br>=C2=A0=C2=A0=C2=A0 template <type=
name... T><br>=C2=A0=C2=A0=C2=A0 bool operator<(Number a, Number b, T=
.... rest)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 if constexpr (sizeof...(rest) =3D=3D 0)<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return int(a) < int(b);<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return int(a) < int(b) &&=
amp; operator<(b, rest...);<br>=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=
=C2=A0 if (Number(1) < Number(10) < Number(50) < Number(70))=C2=A0=
// ... Number(1) < Number(10) && Number(10) < Number(50)<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "ordered=
" << std::endl;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
&& Number(50) < Number(70)<br><br><br>Thoughts?<br><br><br>Kind=
regards,<br>Manuel<br><br><br>[1] https://abseil.io/tips/3<br><br></span><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/55b7acd5-4328-462c-945e-fbbe074fb30e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55b7acd5-4328-462c-945e-fbbe074fb30e=
%40isocpp.org</a>.<br />
------=_Part_15290_95545336.1517345148050--
------=_Part_15289_353415927.1517345148050--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Wed, 31 Jan 2018 08:59:21 +0100
Raw View
--f403043897186e1d6f05640ddbf6
Content-Type: text/plain; charset="UTF-8"
I saw that problem when addition of large vectors need to be performed.
Solution is to emit light and semi classes that build tree of execution in
compile time.
Assignment operator will invoke execution of tree and at the end we will
have optimized code for our expression.
This additional class is part of internal implementation and it is not
visible for end user.
On Tue, Jan 30, 2018 at 9:45 PM, Manuel Freiberger <
manuel.freiberger@gmail.com> wrote:
> Hi all,
>
> I would like to gather some feedback on a proposal to make the binary C++
> operators variadic.
> I haven't seen such a proposal yet so pointers to related (also rejected
> proposals) are highly
> welcome.
>
>
> * Why would such a thing be useful?
>
> Naturally a binary operator only 'sees' its immediate neighboring
> arguments. This can lead
> to inefficient code in some circumstances. A prominent example is the
> concatenation of long
> strings with operator+():
>
> std::string a = some_long_string();
> std::string b = another_long_string();
> std::string c = yet_another_long_string();
> std::string z = a + b + c;
>
> The creation of z is actually done in two steps similar to
>
> std::string temp = a + b;
> std::string z = std::move(temp) + c;
>
> Although temp can be moved, it is unlikely that the memory allocated for
> (a + b) is sufficient
> to also hold c. So memory needs to be allocated twice and in total 5
> strings are copied (a and
> b are copied twice, c once). The only chance is that the compiler is smart
> enough to merge
> the memory allocations into a single call and to eliminate the redundant
> copy operations.
>
> The solution is to use a variadic function like Abseil's StrCat() [1], for
> example. Since the
> function sees all strings at once, it can sum up their sizes, allocate the
> final memory once
> and copy one string after another to the output.
>
> Another alternative is to change operator+() to return a proxy (aka
> Expression Templates),
> which stores references to the strings. When the proxy is assigned to the
> string, it performs
> the same operations as StrCat() above. While this approach is highly
> flexible (one can combine
> different kinds of operators just as in an AST), it involves quite some
> code. One has to take
> care that the references are consumed before the life-time of the objects
> end, which can be
> tricky if one of the strings is a temporary, for example.
>
>
> * How would a variadic operator help?
>
> A variadic operator+() would take two or more arguments. For the string
> concatenation
> use case, one could define a series of operator+(), each taking one more
> argument
>
> std::string operator+(const std::string& a, const std::string& b);
> std::string operator+(const std::string& a, const std::string& b,
> const std::string& c);
> std::string operator+(const std::string& a, const std::string& b,
> const std::string& c,
> const std::string& d);
>
> or simply use a variadic template function:
>
> template <typename... T>
> std::string operator+(const std::string& a, const std::string& b, T...
> rest)
> {
> // compute the final size first
> auto total_size = a.size() + b.size() + (rest.size() + ...);
> if (total_size == 0)
> return std::string();
>
> // allocate enough space for the result
> std::string result(total_size, '\0');
> // and copy the input strings
> auto iter = result.begin();
> iter = std::copy(a.cbegin(), a.cend(), iter);
> iter = std::copy(b.cbegin(), b.cend(), iter);
> (void(iter = std::copy(rest.cbegin(), rest.cend(), iter)), ...);
>
> return result;
> }
>
> Under the hood, the expression
> std::string z = a + b + c;
> would result in the operator call
> std::string z = operator+(a, b, c);
>
> This code is more efficient than a chain of calls to binary operator+().
> It is also a lot
> easier to implement compared to an solution involving proxies/Expression
> Templates. Note that
> a proper implementation would constrain the elements of the parameter pack
> to be of type
> std::string (any maybe derived classes).
>
> If a parameter pack is used in an operator definition, there must also be
> two additional
> parameters (so that the operator has at least two parameters). This is to
> avoid that an
> operator definition could be used both as unary and binary (or n-ary)
> operator at the same
> time. It also prevents the definition of an operator without parameters at
> all (like the
> conversion operators).
>
>
> * How would that work in the compiler?
>
> Right now the compiler parses a sequence of @-operators (with @ being one
> of the binary
> left-associative operators, e.g. + - * / % & | < > etc)
> a @ b @ c @ d @ e
> into an AST
> operator@(operator@(operator@(operator@(a, b), c), d), e)
>
> Now the new behavior: Before the compiler performs the name lookup, it
> recursively takes the
> arguments of the inner-most operator@() call and lifts them to the next
> operator@(). For the
> example above this would lead to the following additional expressions:
> operator@(operator@(operator@(a, b, c), d), e)
> operator@(operator@(a, b, c, d), e)
> operator@(a, b, c, d, e)
>
>
> Then the name lookup is performed for every expression in this sequence
> starting with the
> longest parameter chain. If no match is found, that expression is simply
> ignored (much like
> SFINAE). The lookup is also skipped if none of the parameters is of
> class-or enumeration-type.
> This is to avoid hijacking the built-in operators for fundamental types.
> An error is emitted
> only when the lookup for the binary operators fail.
>
> Right-associative operators would behave similar but the parameters are
> concatenated from the
> right. So for this expression
> a $ b $ c $ d
> the compiler will try to find matching operators in the following order:
> operator$(a, b, c, d)
> operator$(a, operator$(b, c, d))
> operator$(a, operator$(b, operator$(c, d)))
>
>
> * What else could I do with variadic operators?
>
> - Efficient vector math
>
> template <typename... T>
> Vector operator+(const Vector& a, const Vector& b, T... rest)
> {
> Vector r(a.size());
> for (int i = 0; i < a.size(); ++i) // loop only once over
> the elements
> r[i] = a[i] + b[i] + (rest[i] + ...); // sum the components
> of all vectors
> return r;
> }
>
>
> - Locked streaming
>
> struct locked_stream
> {
> template <typename T, typename... TRest>
> locked_stream& operator<<(const T& t, const TRest&... rest)
> {
> std::lock_guard<std::mutex> lock(m_mutex); // acquire the
> lock once
> m_out << t;
> (void(m_out << rest), ...); // and stream all
> arguments
> return *this;
> }
>
> std::mutex m_mutex;
> std::ostream& m_out;
> };
>
>
> - Python-like comparison chains:
>
> template <typename... T>
> bool operator<(Number a, Number b, T... rest)
> {
> if constexpr (sizeof...(rest) == 0)
> return int(a) < int(b);
> else
> return int(a) < int(b) && operator<(b, rest...);
> }
>
> if (Number(1) < Number(10) < Number(50) < Number(70)) // ...
> Number(1) < Number(10) && Number(10) < Number(50)
> std::cout << "ordered" << std::endl; // &&
> Number(50) < Number(70)
>
>
> Thoughts?
>
>
> Kind regards,
> Manuel
>
>
> [1] https://abseil.io/tips/3
>
> --
> 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/55b7acd5-4328-462c-
> 945e-fbbe074fb30e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/55b7acd5-4328-462c-945e-fbbe074fb30e%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/CAEfefmwnRMhb16YBHCpvSMSnnstKFG3BA%3Dt7-t-pRgvnHGVGnA%40mail.gmail.com.
--f403043897186e1d6f05640ddbf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I saw that problem when addition of large vectors nee=
d to be performed.</div><div>Solution is to emit light and semi classes=C2=
=A0that=C2=A0build tree of execution in compile time.</div><div>Assignment =
operator=C2=A0will invoke execution of tree and at the end we will have opt=
imized code for our expression.</div><div>This additional class is part of =
internal implementation and it is not visible for end user.</div><div><br><=
/div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Tue, Jan 30, 2018 at 9:45 PM, Manuel Freiberger =
<span dir=3D"ltr"><<a href=3D"mailto:manuel.freiberger@gmail.com" target=
=3D"_blank">manuel.freiberger@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span>Hi all,<br><br>I would like to =
gather some feedback on a proposal to make the binary C++ operators variadi=
c.<br>I haven't seen such a proposal yet so pointers to related (also r=
ejected proposals) are highly<br>welcome.<br><br><br>* Why would such a thi=
ng be useful?<br><br>Naturally a binary operator only 'sees' its im=
mediate neighboring arguments. This can lead<br>to inefficient code in some=
circumstances. A prominent example is the concatenation of long<br>strings=
with operator+():<br><br>=C2=A0=C2=A0=C2=A0 std::string a =3D some_long_st=
ring();<br>=C2=A0=C2=A0=C2=A0 std::string b =3D another_long_string();<br>=
=C2=A0=C2=A0=C2=A0 std::string c =3D yet_another_long_string();<br>=C2=A0=
=C2=A0=C2=A0 std::string z =3D a + b + c;<br><br>The creation of z is actua=
lly done in two steps similar to<br><br>=C2=A0=C2=A0=C2=A0 std::string temp=
=3D a + b;<br>=C2=A0=C2=A0=C2=A0 std::string z =3D std::move(temp) + c;<br=
><br>Although temp can be moved, it is unlikely that the memory allocated f=
or (a + b) is sufficient<br>to also hold c. So memory needs to be allocated=
twice and in total 5 strings are copied (a and<br>b are copied twice, c on=
ce). The only chance is that the compiler is smart enough to merge<br>the m=
emory allocations into a single call and to eliminate the redundant copy op=
erations.<br><br>The solution is to use a variadic function like Abseil'=
;s StrCat() [1], for example. Since the<br>function sees all strings at onc=
e, it can sum up their sizes, allocate the final memory once<br>and copy on=
e string after another to the output.<br><br>Another alternative is to chan=
ge operator+() to return a proxy (aka Expression Templates),<br>which store=
s references to the strings. When the proxy is assigned to the string, it p=
erforms<br>the same operations as StrCat() above. While this approach is hi=
ghly flexible (one can combine<br>different kinds of operators just as in a=
n AST), it involves quite some code. One has to take<br>care that the refer=
ences are consumed before the life-time of the objects end, which can be<br=
>tricky if one of the strings is a temporary, for example.<br><br><br>* How=
would a variadic operator help?<br><br>A variadic operator+() would take t=
wo or more arguments. For the string concatenation<br>use case, one could d=
efine a series of operator+(), each taking one more argument<br><br>=C2=A0=
=C2=A0=C2=A0 std::string operator+(const std::string& a, const std::str=
ing& b);<br>=C2=A0=C2=A0=C2=A0 std::string operator+(const std::string&=
amp; a, const std::string& b, const std::string& c);<br>=C2=A0=C2=
=A0=C2=A0 std::string operator+(const std::string& a, const std::string=
& b, const std::string& c,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const std::string& d);<br><br>o=
r simply use a variadic template function:<br><br>=C2=A0=C2=A0=C2=A0 templa=
te <typename... T><br>=C2=A0=C2=A0=C2=A0 std::string operator+(const =
std::string& a, const std::string& b, T... rest)<br>=C2=A0=C2=A0=C2=
=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // compute the final si=
ze first<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto total_size =3D =
a.size() + b.size() + (rest.size() + ...);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 if (total_size =3D=3D 0)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::string();<br><br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // allocate enough space for the result<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::string result(total_size,=
'\0');<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // and copy t=
he input strings<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto iter =
=3D result.begin();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iter =3D =
std::copy(a.cbegin(), a.cend(), iter);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 iter =3D std::copy(b.cbegin(), b.cend(), iter);<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (void(iter =3D std::copy(rest.cbegin(), rest=
..cend(), iter)), ...);<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn result;<br>=C2=A0=C2=A0=C2=A0 }<br><br>Under the hood, the expression<=
br></span><span><span>=C2=A0=C2=A0=C2=A0 std::string z =3D a + b + c;<br>wo=
uld result in the operator call<br>=C2=A0=C2=A0=C2=A0 std::string z =3D ope=
rator+(a, b, c);<br><br></span>This code is more efficient than a chain of =
calls to binary operator+(). It is also a lot<br>easier to implement compar=
ed to an solution involving proxies/Expression Templates. Note that<br>a pr=
oper implementation would constrain the elements of the parameter pack to b=
e of type<br>std::string (any maybe derived classes).<br><br>If a parameter=
pack is used in an operator definition, there must also be two additional<=
br>parameters (so that the operator has at least two parameters). This is t=
o avoid that an<br>operator definition could be used both as unary and bina=
ry (or n-ary) operator at the same<br>time. It also prevents the definition=
of an operator without parameters at all (like the<br>conversion operators=
).<br><br><br>* How would that work in the compiler?<br><br>Right now the c=
ompiler parses a sequence of @-operators (with @ being one of the binary<br=
>left-associative operators, e.g. + - * / % & | < > etc)<br>=C2=
=A0=C2=A0=C2=A0 a @ b @ c @ d @ e<br>into an AST<br>=C2=A0=C2=A0=C2=A0 oper=
ator@(operator@(operator@(<wbr>operator@(a, b), c), d), e)<br><br>Now the n=
ew behavior: Before the compiler performs the name lookup, it recursively t=
akes the<br>arguments of the inner-most operator@() call and lifts them to =
the next operator@(). For the<br>example above this would lead to the follo=
wing additional expressions:<br></span><span><span><code class=3D"m_-204773=
5977558017071prettyprint"><span class=3D"m_-2047735977558017071styled-by-pr=
ettify" style=3D"color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0 operator@(operator@(o=
perator@(<wbr>a, b, c), d), e)<br>=C2=A0=C2=A0=C2=A0 operator@(operator@(a,=
b, c, d), e)<br>=C2=A0=C2=A0=C2=A0 operator@(a, b, c, d, e)</span><span cl=
ass=3D"m_-2047735977558017071styled-by-prettify" style=3D"color:rgb(102,102=
,0)"><br></span></code></span></span><span class=3D"m_-2047735977558017071s=
tyled-by-prettify" style=3D"color:rgb(0,0,0)"></span><br><span class=3D"m_-=
2047735977558017071styled-by-prettify" style=3D"color:rgb(0,0,0)"></span><s=
pan><span><code class=3D"m_-2047735977558017071prettyprint"></code></span><=
/span><span><span></span></span><span><br>Then the name lookup is performed=
for every expression in this sequence starting with the<br>longest paramet=
er chain. If no match is found, that expression is simply ignored (much lik=
e<br>SFINAE). The lookup is also skipped if none of the parameters is of cl=
ass-or enumeration-type.<br>This is to avoid hijacking the built-in operato=
rs for fundamental types. An error is emitted<br>only when the lookup for t=
he binary operators fail.<br><br>Right-associative operators would behave s=
imilar but the parameters are concatenated from the<br>right. So for this e=
xpression<br>=C2=A0=C2=A0=C2=A0 a $ b $ c $ d<br>the compiler will try to f=
ind matching operators in the following order:<br>=C2=A0=C2=A0=C2=A0 operat=
or$(a, b, c, d)<br>=C2=A0=C2=A0=C2=A0 operator$(a, operator$(b, c, d))<br>=
=C2=A0=C2=A0=C2=A0 operator$(a, operator$(b, operator$(c, d)))<br><br><br>*=
What else could I do with variadic operators?<br><br>- Efficient vector ma=
th<br><br>=C2=A0=C2=A0=C2=A0 template <typename... T><br>=C2=A0=C2=A0=
=C2=A0 Vector operator+(const Vector& a, const Vector& b, T... rest=
)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vec=
tor r(a.size());<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i =
=3D 0; i < a.size(); ++i)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 // loop only once over the elements<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r[i] =3D a[i] + b[i] + (rest[i] + ...)=
;=C2=A0 // sum the components of all vectors<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 return r;<br>=C2=A0=C2=A0=C2=A0 }<br><br><br>- Locked strea=
ming<br><br>=C2=A0=C2=A0=C2=A0 struct locked_stream<br>=C2=A0=C2=A0=C2=A0 {=
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template <typename T, typ=
ename... TRest><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locked_str=
eam& operator<<(const T& t, const TRest&... rest)<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::lock_guard<std::mutex> lock=
(m_mutex);=C2=A0 // acquire the lock once<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 m_out << t;<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (void(m_out << re=
st), ...);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // and stream all arguments<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return *this;<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::mutex m_mutex;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::ostream& m_out;<br>=C2=A0=C2=A0=C2=A0 };<br><br><br>-=
Python-like comparison chains:<br><br>=C2=A0=C2=A0=C2=A0 template <type=
name... T><br>=C2=A0=C2=A0=C2=A0 bool operator<(Number a, Number b, T=
.... rest)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 if constexpr (sizeof...(rest) =3D=3D 0)<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return int(a) < int(b);<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return int(a) < int(b) &&=
amp; operator<(b, rest...);<br>=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=
=C2=A0 if (Number(1) < Number(10) < Number(50) < Number(70))=C2=A0=
// ... Number(1) < Number(10) && Number(10) < Number(50)<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout << "ordered=
" << std::endl;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
&& Number(50) < Number(70)<br><br><br>Thoughts?<br><br><br>Kind=
regards,<br>Manuel<br><br><br>[1] <a href=3D"https://abseil.io/tips/3" tar=
get=3D"_blank">https://abseil.io/tips/3</a><span class=3D"HOEnZb"><font col=
or=3D"#888888"><br><br></font></span></span></div><span class=3D"HOEnZb"><f=
ont color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>.<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/55b7acd5-4328-462c-945e-fbbe074fb30e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/55b7=
acd5-4328-462c-<wbr>945e-fbbe074fb30e%40isocpp.org</a><wbr>.<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" 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/CAEfefmwnRMhb16YBHCpvSMSnnstKFG3BA%3D=
t7-t-pRgvnHGVGnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwnRMhb16=
YBHCpvSMSnnstKFG3BA%3Dt7-t-pRgvnHGVGnA%40mail.gmail.com</a>.<br />
--f403043897186e1d6f05640ddbf6--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Wed, 31 Jan 2018 01:23:09 -0800 (PST)
Raw View
------=_Part_16704_1000926882.1517390589634
Content-Type: multipart/alternative;
boundary="----=_Part_16705_464617235.1517390589634"
------=_Part_16705_464617235.1517390589634
Content-Type: text/plain; charset="UTF-8"
On Wednesday, January 31, 2018 at 8:59:24 AM UTC+1, Dejan Milosavljevic
wrote:
>
> I saw that problem when addition of large vectors need to be performed.
> Solution is to emit light and semi classes that build tree of execution in
> compile time.
> Assignment operator will invoke execution of tree and at the end we will
> have optimized code for our expression.
> This additional class is part of internal implementation and it is not
> visible for end user.
>
It can be though, because of auto. Expression templates do not work well
with templates, and there was even something like an operator auto()
proposal to fix this IFRC.
> This code is more efficient than a chain of calls to binary operator+().
>> It is also a lot
>> easier to implement compared to an solution involving proxies/Expression
>> Templates. Note that
>> a proper implementation would constrain the elements of the parameter
>> pack to be of type
>> std::string (any maybe derived classes)
>>
>
That might be a bit problematic. So basically you want your variadic
template to behave like this:
std::string operator+(const std::string& a, const std::string& b,
const std::string&... rest);
Which doesn't make it a template anymore and so the name and the syntax
used to achieve this can get really confusing and also counter-intuitive:
What if someone really wants to get any parameter, like std::ostream and
the like?
But, why is this restriction even necessary? After all, there is no problem
with defining an `Foo operator+(const Foo &, int);` nowadays, so why
disallow it for variadic operators? I can always use SFINAE to restrict the
variadic if I want to.
--
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/4639feca-efc8-4388-bec1-c309899a7be6%40isocpp.org.
------=_Part_16705_464617235.1517390589634
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 31, 2018 at 8:59:24 AM UTC+1, Dejan =
Milosavljevic wrote:<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>I saw that problem when addition of large vectors need to be =
performed.</div><div>Solution is to emit light and semi classes=C2=A0that=
=C2=A0build tree of execution in compile time.</div><div>Assignment operato=
r=C2=A0will invoke execution of tree and at the end we will have optimized =
code for our expression.</div><div>This additional class is part of interna=
l implementation and it is not visible for end user.</div></div></blockquot=
e><div><br></div><div>It can be though, because of auto. Expression templat=
es do not work well with templates, and there was even something like an op=
erator auto() proposal to fix this IFRC.=C2=A0=C2=A0</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>This code is more e=
fficient than a chain of calls to binary operator+(). It is also a lot<br>e=
asier to implement compared to an solution involving proxies/Expression Tem=
plates. Note that<br>a proper implementation would constrain the elements o=
f the parameter pack to be of type<br>std::string (any maybe derived classe=
s)</span></div></blockquote></div></div></blockquote><div><br></div><div>Th=
at might be a bit problematic. So basically you want your variadic template=
to behave like this:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 std::st=
ring operator+(const std::string& a, const std::string& b, const st=
d::string&... rest);</div><div><br></div><div>Which doesn't make it=
a template anymore and so the name and the syntax used to achieve this can=
get really confusing and also counter-intuitive: What if someone really wa=
nts to get any parameter, like std::ostream and the like?</div><div><br></d=
iv><div>But, why is this restriction even necessary? After all, there is no=
problem with defining an `Foo operator+(const Foo &, int);` nowadays, =
so why disallow it for variadic operators? I can always use SFINAE to restr=
ict the variadic if I want to.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4639feca-efc8-4388-bec1-c309899a7be6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4639feca-efc8-4388-bec1-c309899a7be6=
%40isocpp.org</a>.<br />
------=_Part_16705_464617235.1517390589634--
------=_Part_16704_1000926882.1517390589634--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Wed, 31 Jan 2018 01:24:11 -0800 (PST)
Raw View
------=_Part_16626_927393765.1517390651525
Content-Type: multipart/alternative;
boundary="----=_Part_16627_531355875.1517390651526"
------=_Part_16627_531355875.1517390651526
Content-Type: text/plain; charset="UTF-8"
I meant: "Expression templates do not work well with **auto**", sorry.
On Wednesday, January 31, 2018 at 10:23:09 AM UTC+1, Nicolas Lesser wrote:
>
> On Wednesday, January 31, 2018 at 8:59:24 AM UTC+1, Dejan Milosavljevic
> wrote:
>>
>> I saw that problem when addition of large vectors need to be performed.
>> Solution is to emit light and semi classes that build tree of execution
>> in compile time.
>> Assignment operator will invoke execution of tree and at the end we will
>> have optimized code for our expression.
>> This additional class is part of internal implementation and it is not
>> visible for end user.
>>
>
> It can be though, because of auto. Expression templates do not work well
> with templates, and there was even something like an operator auto()
> proposal to fix this IFRC.
>
>
>> This code is more efficient than a chain of calls to binary operator+().
>>> It is also a lot
>>> easier to implement compared to an solution involving proxies/Expression
>>> Templates. Note that
>>> a proper implementation would constrain the elements of the parameter
>>> pack to be of type
>>> std::string (any maybe derived classes)
>>>
>>
> That might be a bit problematic. So basically you want your variadic
> template to behave like this:
>
> std::string operator+(const std::string& a, const std::string& b,
> const std::string&... rest);
>
> Which doesn't make it a template anymore and so the name and the syntax
> used to achieve this can get really confusing and also counter-intuitive:
> What if someone really wants to get any parameter, like std::ostream and
> the like?
>
> But, why is this restriction even necessary? After all, there is no
> problem with defining an `Foo operator+(const Foo &, int);` nowadays, so
> why disallow it for variadic operators? I can always use SFINAE to restrict
> the variadic if I want to.
>
--
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/40318d4b-1999-4456-83e9-0e3e01354b40%40isocpp.org.
------=_Part_16627_531355875.1517390651526
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I meant: "Expression templates do not work well with =
**auto**", sorry.<br><br>On Wednesday, January 31, 2018 at 10:23:09 AM=
UTC+1, Nicolas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Wednesday, January 31, 2018 at 8:59:24 AM UTC+1, Dejan M=
ilosavljevic wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I saw that problem when addition of large vectors need to be performe=
d.</div><div>Solution is to emit light and semi classes=C2=A0that=C2=A0buil=
d tree of execution in compile time.</div><div>Assignment operator=C2=A0wil=
l invoke execution of tree and at the end we will have optimized code for o=
ur expression.</div><div>This additional class is part of internal implemen=
tation and it is not visible for end user.</div></div></blockquote><div><br=
></div><div>It can be though, because of auto. Expression templates do not =
work well with templates, and there was even something like an operator aut=
o() proposal to fix this IFRC.=C2=A0=C2=A0</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div><div class=3D"gmail_quote"><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"><span>This code is more efficient than a=
chain of calls to binary operator+(). It is also a lot<br>easier to implem=
ent compared to an solution involving proxies/Expression Templates. Note th=
at<br>a proper implementation would constrain the elements of the parameter=
pack to be of type<br>std::string (any maybe derived classes)</span></div>=
</blockquote></div></div></blockquote><div><br></div><div>That might be a b=
it problematic. So basically you want your variadic template to behave like=
this:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 std::string operator+(=
const std::string& a, const std::string& b, const std::string&.=
... rest);</div><div><br></div><div>Which doesn't make it a template any=
more and so the name and the syntax used to achieve this can get really con=
fusing and also counter-intuitive: What if someone really wants to get any =
parameter, like std::ostream and the like?</div><div><br></div><div>But, wh=
y is this restriction even necessary? After all, there is no problem with d=
efining an `Foo operator+(const Foo &, int);` nowadays, so why disallow=
it for variadic operators? I can always use SFINAE to restrict the variadi=
c if I want to.</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/40318d4b-1999-4456-83e9-0e3e01354b40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40318d4b-1999-4456-83e9-0e3e01354b40=
%40isocpp.org</a>.<br />
------=_Part_16627_531355875.1517390651526--
------=_Part_16626_927393765.1517390651525--
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Wed, 31 Jan 2018 09:28:23 +0000
Raw View
--001a1141e458d901f205640f196e
Content-Type: text/plain; charset="UTF-8"
I'd like the author to explore interactions with the chained comparison
papers.
On Jan 31, 2018 09:24, "Nicolas Lesser" <blitzrakete@gmail.com> wrote:
> I meant: "Expression templates do not work well with **auto**", sorry.
>
> On Wednesday, January 31, 2018 at 10:23:09 AM UTC+1, Nicolas Lesser wrote:
>>
>> On Wednesday, January 31, 2018 at 8:59:24 AM UTC+1, Dejan Milosavljevic
>> wrote:
>>>
>>> I saw that problem when addition of large vectors need to be performed.
>>> Solution is to emit light and semi classes that build tree of execution
>>> in compile time.
>>> Assignment operator will invoke execution of tree and at the end we will
>>> have optimized code for our expression.
>>> This additional class is part of internal implementation and it is not
>>> visible for end user.
>>>
>>
>> It can be though, because of auto. Expression templates do not work well
>> with templates, and there was even something like an operator auto()
>> proposal to fix this IFRC.
>>
>>
>>> This code is more efficient than a chain of calls to binary operator+().
>>>> It is also a lot
>>>> easier to implement compared to an solution involving
>>>> proxies/Expression Templates. Note that
>>>> a proper implementation would constrain the elements of the parameter
>>>> pack to be of type
>>>> std::string (any maybe derived classes)
>>>>
>>>
>> That might be a bit problematic. So basically you want your variadic
>> template to behave like this:
>>
>> std::string operator+(const std::string& a, const std::string& b,
>> const std::string&... rest);
>>
>> Which doesn't make it a template anymore and so the name and the syntax
>> used to achieve this can get really confusing and also counter-intuitive:
>> What if someone really wants to get any parameter, like std::ostream and
>> the like?
>>
>> But, why is this restriction even necessary? After all, there is no
>> problem with defining an `Foo operator+(const Foo &, int);` nowadays, so
>> why disallow it for variadic operators? I can always use SFINAE to restrict
>> the variadic if I want to.
>>
> --
> 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/40318d4b-1999-4456-
> 83e9-0e3e01354b40%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40318d4b-1999-4456-83e9-0e3e01354b40%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/CAANG%3DkUSTZUNAPL0RSCaTuHTWm%2B%2BiLH3Luv6dXgNpzME%2BazMiA%40mail.gmail.com.
--001a1141e458d901f205640f196e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I'd like the author to explore interactions with the =
chained comparison papers.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Jan 31, 2018 09:24, "Nicolas Lesser" <<a h=
ref=3D"mailto:blitzrakete@gmail.com">blitzrakete@gmail.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I me=
ant: "Expression templates do not work well with **auto**", sorry=
..<br><br>On Wednesday, January 31, 2018 at 10:23:09 AM UTC+1, Nicolas Lesse=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesd=
ay, January 31, 2018 at 8:59:24 AM UTC+1, Dejan Milosavljevic wrote:<blockq=
uote 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>I saw that problem w=
hen addition of large vectors need to be performed.</div><div>Solution is t=
o emit light and semi classes=C2=A0that=C2=A0build tree of execution in com=
pile time.</div><div>Assignment operator=C2=A0will invoke execution of tree=
and at the end we will have optimized code for our expression.</div><div>T=
his additional class is part of internal implementation and it is not visib=
le for end user.</div></div></blockquote><div><br></div><div>It can be thou=
gh, because of auto. Expression templates do not work well with templates, =
and there was even something like an operator auto() proposal to fix this I=
FRC.=C2=A0=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span>This code is more efficient than a chain of calls to binary =
operator+(). It is also a lot<br>easier to implement compared to an solutio=
n involving proxies/Expression Templates. Note that<br>a proper implementat=
ion would constrain the elements of the parameter pack to be of type<br>std=
::string (any maybe derived classes)</span></div></blockquote></div></div><=
/blockquote><div><br></div><div>That might be a bit problematic. So basical=
ly you want your variadic template to behave like this:</div><div><br></div=
><div>=C2=A0 =C2=A0 =C2=A0 std::string operator+(const std::string& a, =
const std::string& b, const std::string&... rest);</div><div><br></=
div><div>Which doesn't make it a template anymore and so the name and t=
he syntax used to achieve this can get really confusing and also counter-in=
tuitive: What if someone really wants to get any parameter, like std::ostre=
am and the like?</div><div><br></div><div>But, why is this restriction even=
necessary? After all, there is no problem with defining an `Foo operator+(=
const Foo &, int);` nowadays, so why disallow it for variadic operators=
? I can always use SFINAE to restrict the variadic if I want to.</div></div=
></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>.<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40318d4b-1999-4456-83e9-0e3e01354b40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4031=
8d4b-1999-4456-<wbr>83e9-0e3e01354b40%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAANG%3DkUSTZUNAPL0RSCaTuHTWm%2B%2BiL=
H3Luv6dXgNpzME%2BazMiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3Dk=
USTZUNAPL0RSCaTuHTWm%2B%2BiLH3Luv6dXgNpzME%2BazMiA%40mail.gmail.com</a>.<br=
/>
--001a1141e458d901f205640f196e--
.
Author: Manuel Freiberger <manuel.freiberger@gmail.com>
Date: Wed, 31 Jan 2018 02:20:47 -0800 (PST)
Raw View
------=_Part_16585_1450160946.1517394047906
Content-Type: multipart/alternative;
boundary="----=_Part_16586_1107397256.1517394047906"
------=_Part_16586_1107397256.1517394047906
Content-Type: text/plain; charset="UTF-8"
Hi Dejan,
Thanks for the feedback. These semi classes is what I know as expression
templates. They are super flexible because you can capture the full AST
and I really enjoy them a lot. I used them in a larger project some 12
years ago. However, even something simple as string concatenation requires
quite some boilerplate to write. I tried to write an implementation
yesterday in modern C++ (so e.g. using tuples<> and foward_as_tuple()) but
was
not satisfied with the outcomde. Unfortunately expression templates are not
easy to get correct with i) auto and ii) r-value references.
With a variadic operator+ you could write simply:
std::string s = "ghi";
auto result = "abc" + std::string("def") + s;
With expression templates, auto would capture the AST. So you would either
have to manually specify the type
std::string result = ...
or force the evaluation, which is usually done with operator():
auto result = ("abc" + std::string("def") + s)();
This is how I see it:
1) If you want just a nice syntax, go with binary operator+.
2) If you want to efficiently evaluate a sequence of operator+ calls, go
with a variadic operator+.
3) If you want to efficiently evaluate a combination of operators, go with
expression templates.
Best regards,
Manuel
--
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/de9bda6f-8bfd-47fc-b25a-ca88c5ffe88f%40isocpp.org.
------=_Part_16586_1107397256.1517394047906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Dejan,<div><br></div><div>Thanks for the feedback. Thes=
e semi classes is what I know as expression templates. They are super flexi=
ble because you can capture the full AST</div><div>and I really enjoy them =
a lot. I used them in a larger project some 12 years ago. However, even som=
ething simple as string concatenation requires</div><div>quite some boilerp=
late to write. I tried to write an implementation yesterday in modern C++ (=
so e.g. using tuples<> and foward_as_tuple()) but was</div><div>not s=
atisfied with the outcomde. Unfortunately expression templates are not easy=
to get correct with i) auto and ii) r-value references.</div><div><br></di=
v><div>With a variadic operator+ you could write simply:</div><div>=C2=A0 =
=C2=A0 std::string s =3D "ghi";</div><div>=C2=A0 =C2=A0 auto resu=
lt =3D "abc" + std::string("def") + s;</div><div><br></=
div><div>With expression templates, auto would capture the AST. So you woul=
d either have to manually specify the type</div><div>=C2=A0 =C2=A0 std::str=
ing result =3D ...=C2=A0</div><div>or force the evaluation, which is usuall=
y done with operator():</div><div>=C2=A0 =C2=A0 auto result =3D ("abc&=
quot; + std::string("def") + s)();</div><div><br></div><div>This =
is how I see it:</div><div>1) If you want just a nice syntax, go with binar=
y operator+.</div><div>2) If you want to efficiently evaluate a sequence of=
operator+ calls, go with a variadic operator+.</div><div>3) If you want to=
efficiently evaluate a combination of operators, go with expression templa=
tes.</div><div><br></div><div>Best regards,</div><div>Manuel</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" 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/de9bda6f-8bfd-47fc-b25a-ca88c5ffe88f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de9bda6f-8bfd-47fc-b25a-ca88c5ffe88f=
%40isocpp.org</a>.<br />
------=_Part_16586_1107397256.1517394047906--
------=_Part_16585_1450160946.1517394047906--
.
Author: Manuel Freiberger <manuel.freiberger@gmail.com>
Date: Wed, 31 Jan 2018 02:27:14 -0800 (PST)
Raw View
------=_Part_16569_775625778.1517394434160
Content-Type: multipart/alternative;
boundary="----=_Part_16570_714505962.1517394434160"
------=_Part_16570_714505962.1517394434160
Content-Type: text/plain; charset="UTF-8"
Am Mittwoch, 31. Januar 2018 10:24:11 UTC+1 schrieb Nicolas Lesser:
>
> That might be a bit problematic. So basically you want your variadic
>> template to behave like this:
>>
>> std::string operator+(const std::string& a, const std::string& b,
>> const std::string&... rest);
>>
>> Which doesn't make it a template anymore and so the name and the syntax
>> used to achieve this can get really confusing and also counter-intuitive:
>> What if someone really wants to get any parameter, like std::ostream and
>> the like?
>>
>> But, why is this restriction even necessary? After all, there is no
>> problem with defining an `Foo operator+(const Foo &, int);` nowadays, so
>> why disallow it for variadic operators? I can always use SFINAE to restrict
>> the variadic if I want to.
>>
>
Sorry, my wording was not very clear in this case. The operator as written
is fine as it is. I would also not suggest a new syntax for constraining
the template.
For this we already have SFINAE and concepts.
Let me put it in another way:
If variadic operators were part of the standard and if variadic operator+
for string concatenation should go into STL, then we should think about
constraining the additional template parameters (e.g. every type should be
implicitly convertible to std::string or something similar). The constraints
are just to narrow down the overload set, so that e.g.
operator+(std::string, std::string, int)
does not match (except if you want to have an implicit int->string
conversion, of course).
Kind regards,
Manuel
--
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/4a49916f-1541-418c-ae81-dcebd458fe49%40isocpp.org.
------=_Part_16570_714505962.1517394434160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Am Mittwoch, 31. Januar 2018 10:24:11 UTC+1 schrieb Ni=
colas Lesser:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That might be=
a bit problematic. So basically you want your variadic template to behave =
like this:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 std::string operat=
or+(const std::string& a, const std::string& b, const std::string&a=
mp;... rest);</div><div><br></div><div>Which doesn't make it a template=
anymore and so the name and the syntax used to achieve this can get really=
confusing and also counter-intuitive: What if someone really wants to get =
any parameter, like std::ostream and the like?</div><div><br></div><div>But=
, why is this restriction even necessary? After all, there is no problem wi=
th defining an `Foo operator+(const Foo &, int);` nowadays, so why disa=
llow it for variadic operators? I can always use SFINAE to restrict the var=
iadic if I want to.</div></div></blockquote></div></blockquote><div><br></d=
iv><div>Sorry, my wording was not very clear in this case. The operator as =
written is fine as it is. I would also not suggest a new syntax for constra=
ining the template.</div><div>For this we already have SFINAE and concepts.=
</div><div><br></div><div>Let me put it in another way:<br></div><div>If va=
riadic operators were part of the standard and if variadic operator+ for st=
ring concatenation should go into STL, then we should think about</div><div=
>constraining the additional template parameters (e.g. every type should be=
implicitly convertible to std::string or something similar). The constrain=
ts</div><div>are just to narrow down the overload set, so that e.g.</div><d=
iv>=C2=A0 =C2=A0 operator+(std::string, std::string, int)</div><div>does no=
t match (except if you want to have an implicit int->string conversion, =
of course).</div><div><br></div><div>Kind regards,<br>Manuel</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4a49916f-1541-418c-ae81-dcebd458fe49%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a49916f-1541-418c-ae81-dcebd458fe49=
%40isocpp.org</a>.<br />
------=_Part_16570_714505962.1517394434160--
------=_Part_16569_775625778.1517394434160--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Wed, 31 Jan 2018 15:51:34 +0100
Raw View
--001a1141e01498a1010564139dd2
Content-Type: text/plain; charset="UTF-8"
> 2) If you want to efficiently evaluate a sequence of operator+ calls, go
with a variadic operator+.
Look at next example:
node_tree_string operator+( std::string const& left, std::string const&
right ){ ... }
node_tree_string:: node_tree_string( node_tree_string && *right* ){
/*Evaluate *right* */}
{
std::string s = "qwerty";
auto result5 = "abc" + std::string("def") + s;// Build expression tree
and evaluate.
s = "asdfgh"; // Try to make some side effect. We already have result.
std::cout << result5 << std::endl; // Already evaluated so no effect
from side effects!
}
Type of result5 is node_tree_string but already evaluated.
Pros:
Still efficient.
No changes in standard.
Cons:
Implementation is harder to maintain. One additional class. In case of
something more complex this can explode.
And thought:
If we can overload multiplication to perform arithmetic addition why not
we have overloading that can change associativity.
On Wed, Jan 31, 2018 at 11:27 AM, Manuel Freiberger <
manuel.freiberger@gmail.com> wrote:
>
> Am Mittwoch, 31. Januar 2018 10:24:11 UTC+1 schrieb Nicolas Lesser:
>>
>> That might be a bit problematic. So basically you want your variadic
>>> template to behave like this:
>>>
>>> std::string operator+(const std::string& a, const std::string& b,
>>> const std::string&... rest);
>>>
>>> Which doesn't make it a template anymore and so the name and the syntax
>>> used to achieve this can get really confusing and also counter-intuitive:
>>> What if someone really wants to get any parameter, like std::ostream and
>>> the like?
>>>
>>> But, why is this restriction even necessary? After all, there is no
>>> problem with defining an `Foo operator+(const Foo &, int);` nowadays, so
>>> why disallow it for variadic operators? I can always use SFINAE to restrict
>>> the variadic if I want to.
>>>
>>
> Sorry, my wording was not very clear in this case. The operator as written
> is fine as it is. I would also not suggest a new syntax for constraining
> the template.
> For this we already have SFINAE and concepts.
>
> Let me put it in another way:
> If variadic operators were part of the standard and if variadic operator+
> for string concatenation should go into STL, then we should think about
> constraining the additional template parameters (e.g. every type should be
> implicitly convertible to std::string or something similar). The constraints
> are just to narrow down the overload set, so that e.g.
> operator+(std::string, std::string, int)
> does not match (except if you want to have an implicit int->string
> conversion, of course).
>
> Kind regards,
> Manuel
>
> --
> 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/4a49916f-1541-418c-
> ae81-dcebd458fe49%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4a49916f-1541-418c-ae81-dcebd458fe49%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/CAEfefmzZG_i8K-jhj8s2YbWQJZ6LkJsR%3D1U19qXNWiGAitHAcw%40mail.gmail.com.
--001a1141e01498a1010564139dd2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>=C2=A0> 2) If you want to efficiently evaluate a s=
equence of operator+ calls, go with a variadic operator+.</div><div>=C2=A0<=
/div><div>Look at next example:</div><div><br></div><div><font face=3D"mono=
space,monospace">=C2=A0node_tree_string=C2=A0operator+( std::string const&a=
mp; left, std::string const& right ){ ... }</font></div><div><font face=
=3D"Courier New">=C2=A0node_tree_string::=C2=A0node_tree_string(=C2=A0=C2=
=A0node_tree_string && <em>right</em> ){ /*Evaluate <em>right</em> =
*/}</font></div><div><div><font face=3D"Courier New"><br></font></div><font=
face=3D"Courier New"><font face=3D"Courier New"><font face=3D"Courier New"=
><span><font face=3D"Courier New"><font face=3D"monospace,monospace">=C2=A0=
=C2=A0{ </font></font></span></font></font><font face=3D"Courier New"><font=
face=3D"Courier New"><span><font face=3D"Courier New"><div><font face=3D"m=
onospace,monospace">=C2=A0=C2=A0=C2=A0std::string s =3D "qwerty";=
</font></div><div><font face=3D"monospace,monospace">=C2=A0=C2=A0 auto resu=
lt5 =3D "abc" + std::string("def") + s;// Build express=
ion tree and evaluate.</font></div><div><font face=3D"monospace,monospace">=
=C2=A0=C2=A0=C2=A0s =3D "asdfgh"; // Try to make some side effect=
.. We already have result.</font></div><div><font face=3D"monospace,monospac=
e">=C2=A0=C2=A0=C2=A0std::cout << result5 << std::endl;=C2=A0//=
=C2=A0Already evaluated so no effect from side effects!</font></div><div><f=
ont face=3D"Arial"><font face=3D"Courier New"><font face=3D"monospace,monos=
pace">=C2=A0 }</font></font></font></div><div>=C2=A0 Type of result5 is=C2=
=A0node_tree_string but already evaluated.</div><div><br></div><div><font f=
ace=3D"arial,helvetica,sans-serif">Pros:</font></div><div><font face=3D"ari=
al,helvetica,sans-serif">=C2=A0=C2=A0 Still efficient. </font></div><div><f=
ont face=3D"arial,helvetica,sans-serif">=C2=A0=C2=A0 No changes in standard=
..</font></div><div><font face=3D"arial,helvetica,sans-serif">Cons:</font></=
div><div><font face=3D"arial,helvetica,sans-serif">=C2=A0=C2=A0=C2=A0 Imple=
mentation is harder to maintain. One additional class. In case of something=
more complex this can explode.</font></div><div><font face=3D"arial,helvet=
ica,sans-serif"><br></font></div><div><div><font face=3D"arial,helvetica,sa=
ns-serif">And thought:<br></font></div><div><font face=3D"arial,helvetica,s=
ans-serif">=C2=A0=C2=A0If we can overload=C2=A0multiplication=C2=A0to perfo=
rm arithmetic addition why not we have overloading that can change associat=
ivity.</font></div></div><div><div><font face=3D"Arial"><font face=3D"Arial=
"><div><font face=3D"Courier New"></font><font face=3D"Courier New"></font>=
=C2=A0</div></font></font></div></div></font></span></font></font></font></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
Jan 31, 2018 at 11:27 AM, Manuel Freiberger <span dir=3D"ltr"><<a href=
=3D"mailto:manuel.freiberger@gmail.com" target=3D"_blank">manuel.freiberger=
@gmail.com</a>></span> wrote:<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"><span><br>Am Mittwoch, 31. Januar 2018 10:24:11 UTC+1 schrieb Nico=
las Lesser:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rg=
b(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"l=
tr"><div>That might be a bit problematic. So basically you want your variad=
ic template to behave like this:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0 std::string operator+(const std::string& a, const std::string& =
b, const std::string&... rest);</div><div><br></div><div>Which doesn=
9;t make it a template anymore and so the name and the syntax used to achie=
ve this can get really confusing and also counter-intuitive: What if someon=
e really wants to get any parameter, like std::ostream and the like?</div><=
div><br></div><div>But, why is this restriction even necessary? After all, =
there is no problem with defining an `Foo operator+(const Foo &, int);`=
nowadays, so why disallow it for variadic operators? I can always use SFIN=
AE to restrict the variadic if I want to.</div></div></blockquote></div></b=
lockquote><div><br></div></span><div>Sorry, my wording was not very clear i=
n this case. The operator as written is fine as it is. I would also not sug=
gest a new syntax for constraining the template.</div><div>For this we alre=
ady have SFINAE and concepts.</div><div><br></div><div>Let me put it in ano=
ther way:<br></div><div>If variadic operators were part of the standard and=
if variadic operator+ for string concatenation should go into STL, then we=
should think about</div><div>constraining the additional template paramete=
rs (e.g. every type should be implicitly convertible to std::string or some=
thing similar). The constraints</div><div>are just to narrow down the overl=
oad set, so that e.g.</div><div>=C2=A0 =C2=A0 operator+(std::string, std::s=
tring, int)</div><div>does not match (except if you want to have an implici=
t int->string conversion, of course).</div><div><br></div><div>Kind rega=
rds,<br>Manuel</div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>.<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/4a49916f-1541-418c-ae81-dcebd458fe49%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4a49=
916f-1541-418c-<wbr>ae81-dcebd458fe49%40isocpp.org</a><wbr>.<br>
</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" 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/CAEfefmzZG_i8K-jhj8s2YbWQJZ6LkJsR%3D1=
U19qXNWiGAitHAcw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmzZG_i8K-=
jhj8s2YbWQJZ6LkJsR%3D1U19qXNWiGAitHAcw%40mail.gmail.com</a>.<br />
--001a1141e01498a1010564139dd2--
.
Author: Manuel Freiberger <manuel.freiberger@gmail.com>
Date: Wed, 31 Jan 2018 07:29:16 -0800 (PST)
Raw View
------=_Part_17508_1863047415.1517412557009
Content-Type: multipart/alternative;
boundary="----=_Part_17509_252248769.1517412557010"
------=_Part_17509_252248769.1517412557010
Content-Type: text/plain; charset="UTF-8"
Am Mittwoch, 31. Januar 2018 15:51:37 UTC+1 schrieb Dejan Milosavljevic:
>
> > 2) If you want to efficiently evaluate a sequence of operator+ calls,
> go with a variadic operator+.
>
> Look at next example:
>
> node_tree_string operator+( std::string const& left, std::string const&
> right ){ ... }
> node_tree_string:: node_tree_string( node_tree_string && *right* ){
> /*Evaluate *right* */}
>
> {
> std::string s = "qwerty";
> auto result5 = "abc" + std::string("def") + s;// Build expression tree
> and evaluate.
> s = "asdfgh"; // Try to make some side effect. We already have result.
> std::cout << result5 << std::endl; // Already evaluated so no effect
> from side effects!
> }
> Type of result5 is node_tree_string but already evaluated.
>
The fact that result5 is not std::string is unfortunate. I think this
creates quite some friction if you use the result as a temporary (for
example
when passing it to a template function). But probably this is the best one
can do in C++17.
The constructor taking an rvalue-reference is a nice idea! But doesn't it
evaluate the string too often? What happens, if you concatenate more strings
for example
std::string result = std::string("abc") + "def" + "ghi" + "jkl" + "mno";
Is the memory still allocated only once?
Another question: Does this compile as well and can it initialize the
result without copying?
std::string result("abc" + std::string("def") + s);
How do you store the const char* pointer in the node_tree_string when it is
no template? Do you use a variant? Or do you copy it to a std::string
internally?
And thought:
> If we can overload multiplication to perform arithmetic addition why not
> we have overloading that can change associativity.
>
I do not understand how multiplication overloads addition. Do you mean that
x + x + x == 3 * x? Well that's only true for some types (and not for
strings, for example).
Overloading on associativity would require much deeper changes to the
language I fear. You suddenly would have to deal with the fact that
a + b + c
for one type a is parsed as
(a + b) + c
but for another type it is
a + (b + c).
I think that Swift has such a feature (correct me if I'm wrong). But they
also have a different parsing model: The full expression is parsed
first and in a second step the operator precedence and associativity are
taken into account. And the latter has to be done together with
with type deduction.
--
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/2269b317-c1c9-4706-9a14-4c932b790649%40isocpp.org.
------=_Part_17509_252248769.1517412557010
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Mittwoch, 31. Januar 2018 15:51:37 UTC+1 schrieb Dejan =
Milosavljevic:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>=C2=A0> 2) If you want to efficiently evaluate a sequence of opera=
tor+ calls, go with a variadic operator+.</div><div>=C2=A0</div><div>Look a=
t next example:</div><div><br></div><div><font face=3D"monospace,monospace"=
>=C2=A0node_tree_string=C2=A0operator+( std::string const& left, std::s=
tring const& right ){ ... }</font></div><div><font face=3D"Courier New"=
>=C2=A0node_tree_string::=C2=A0node_tree_<wbr>string(=C2=A0=C2=A0node_tree_=
string && <em>right</em> ){ /*Evaluate <em>right</em> */}</font></d=
iv><div><div><font face=3D"Courier New"><br></font></div><font face=3D"Cour=
ier New"><font face=3D"Courier New"><font face=3D"Courier New"><span><font =
face=3D"Courier New"><font face=3D"monospace,monospace">=C2=A0=C2=A0{ </fon=
t></font></span></font></font><font face=3D"Courier New"><font face=3D"Cour=
ier New"><span><font face=3D"Courier New"><div><font face=3D"monospace,mono=
space">=C2=A0=C2=A0=C2=A0std::string s =3D "qwerty";</font></div>=
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0 auto result5 =3D "=
;abc" + std::string("def") + s;// Build expression tree and =
evaluate.</font></div><div><font face=3D"monospace,monospace">=C2=A0=C2=A0=
=C2=A0s =3D "asdfgh"; // Try to make some side effect. We already=
have result.</font></div><div><font face=3D"monospace,monospace">=C2=A0=C2=
=A0=C2=A0std::cout << result5 << std::endl;=C2=A0//=C2=A0Alread=
y evaluated so no effect from side effects!</font></div><div><font face=3D"=
Arial"><font face=3D"Courier New"><font face=3D"monospace,monospace">=C2=A0=
}</font></font></font></div><div>=C2=A0 Type of result5 is=C2=A0node_tree_=
string but already evaluated.</div></font></span></font></font></font></div=
></div></blockquote><div><br></div><div>The fact that=C2=A0<span style=3D"f=
ont-family: monospace, monospace;">result5=C2=A0</span>is not=C2=A0<span st=
yle=3D"font-family: monospace, monospace;">std::string=C2=A0</span>is unfor=
tunate. I think this creates quite some friction if you use the result as a=
temporary (for example</div><div>when passing it to a template function). =
But probably this is the best one can do in C++17.</div><div><br></div><div=
>The constructor taking an rvalue-reference is a nice idea! But doesn't=
it evaluate the string too often? What happens, if you concatenate more st=
rings</div><div>for example</div><div><span style=3D"font-family: monospace=
, monospace;">=C2=A0 =C2=A0 std::string result =3D std::string("abc&qu=
ot;) + "def" + "ghi" + "jkl" + "mno"=
;;</span><br></div><div>Is the memory still allocated only once?<br></div><=
div><br></div><div>Another question: Does this compile as well and can it i=
nitialize the result without copying?</div><div><span style=3D"font-family:=
monospace, monospace;">=C2=A0 =C2=A0 std::string result("abc" + =
std::string("def") + s);</span><br></div><div><span style=3D"font=
-family: monospace, monospace;"><br></span></div><div>How do you store the =
const char* pointer in the=C2=A0<span style=3D"font-family: "Courier N=
ew";">node_tree_string</span>=C2=A0when it is no template? Do you use =
a variant? Or do you copy it to a <span style=3D"font-family: "Courier=
New";">std::string</span>=C2=A0internally?=C2=A0</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><font fa=
ce=3D"Courier New"><font face=3D"Courier New"><font face=3D"Courier New"><s=
pan><font face=3D"Courier New"><div><div><font face=3D"arial,helvetica,sans=
-serif">And thought:<br></font></div><div><font face=3D"arial,helvetica,san=
s-serif">=C2=A0=C2=A0If we can overload=C2=A0multiplication=C2=A0to perform=
arithmetic addition why not we have overloading that can change associativ=
ity.</font></div></div><div><div><font face=3D"Arial"><font face=3D"Arial">=
<div><font face=3D"Courier New"></font><font face=3D"Courier New"></font></=
div></font></font></div></div></font></span></font></font></font></div></di=
v></blockquote><div><br></div><div>I do not understand how multiplication o=
verloads addition. Do you mean that x + x + x =3D=3D 3 * x? Well that's=
only true for some types (and not for strings, for example).</div><div><br=
></div><div>Overloading on associativity would require much deeper changes =
to the language I fear. You suddenly would have to deal with the fact that<=
/div><div>=C2=A0 =C2=A0 a + b + c</div><div>for one type a is parsed as</di=
v><div>=C2=A0 =C2=A0 (a + b) + c</div><div>but for another type it is</div>=
<div>=C2=A0 =C2=A0 a + (b + c).</div><div><br></div><div>I think that Swift=
has such a feature (correct me if I'm wrong). But they also have a dif=
ferent parsing model: The full expression is parsed</div><div>first and in =
a second step the operator precedence and associativity are taken into acco=
unt. And the latter has to be done together with</div><div>with type deduct=
ion.</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" 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/2269b317-c1c9-4706-9a14-4c932b790649%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2269b317-c1c9-4706-9a14-4c932b790649=
%40isocpp.org</a>.<br />
------=_Part_17509_252248769.1517412557010--
------=_Part_17508_1863047415.1517412557009--
.
Author: Manuel Freiberger <manuel.freiberger@gmail.com>
Date: Wed, 31 Jan 2018 17:53:09 -0800 (PST)
Raw View
------=_Part_21109_2118800430.1517449989833
Content-Type: multipart/alternative;
boundary="----=_Part_21110_2080723508.1517449989833"
------=_Part_21110_2080723508.1517449989833
Content-Type: text/plain; charset="UTF-8"
A nicely formatted version can be found on github now:
https://github.com/ombre5733/cpp_variadic_operators_proposal/blob/master/proposal.md
--
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/6506c98a-d333-475f-a97c-132e689cf926%40isocpp.org.
------=_Part_21110_2080723508.1517449989833
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A nicely formatted version can be found on github now:<br>=
<br>https://github.com/ombre5733/cpp_variadic_operators_proposal/blob/maste=
r/proposal.md<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6506c98a-d333-475f-a97c-132e689cf926%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6506c98a-d333-475f-a97c-132e689cf926=
%40isocpp.org</a>.<br />
------=_Part_21110_2080723508.1517449989833--
------=_Part_21109_2118800430.1517449989833--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 31 Jan 2018 20:32:42 -0600
Raw View
--001a113ef3686c4af305641d6bbf
Content-Type: text/plain; charset="UTF-8"
On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <
manuel.freiberger@gmail.com> wrote:
> The solution is to use a variadic function like Abseil's StrCat() [1], for
> example. Since the
> function sees all strings at once, it can sum up their sizes, allocate the
> final memory once
> and copy one string after another to the output.
>
And you haven't justified the downside to this solution, especially since
such a function is fairly simple to write in C++17:
std::string StringCat(std::initializer_list<std::string_view> il)
{
std::string s;
s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},
[](size_t sz, std::string_view sv){ return sz + sv.size(); }));
for (std::string_view sv : il)
s += sv;
return s;
}
template<typename... Ts>
std::string StringCat(Ts&&... ts)
{
return StringCat({std::string_view(std::forward<Ts>(ts))...});
}
Note that
> a proper implementation would constrain the elements of the parameter pack
> to be of type
> std::string (any maybe derived classes).
>
Which is a large constraint that the implementation above doesn't have.
This would be a not insignificant language change for something that is
ultimately very restrictive compared with the functional version we can
write today. Doesn't seem worth it.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPKKqN%3Dmmju6vgaZMoJ3uKjbFkwgBnxORs3ECtxojT8Tg%40mail.gmail.com.
--001a113ef3686c4af305641d6bbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <span d=
ir=3D"ltr"><<a href=3D"mailto:manuel.freiberger@gmail.com" target=3D"_bl=
ank">manuel.freiberger@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><spa=
n>The solution is to use a variadic function like Abseil's StrCat() [1]=
, for example. Since the<br>function sees all strings at once, it can sum u=
p their sizes, allocate the final memory once<br>and copy one string after =
another to the output.<br></span></div></blockquote><div><br></div><div>And=
you haven't justified the downside to this solution, especially since =
such a function is fairly simple to write in C++17:</div><div><br></div><di=
v><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:nor=
mal;font-family:Menlo;color:rgb(0,0,0)">std::string StringCat(std::initiali=
zer_list<std::string_view> il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 std::string s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 s.reserve(std::accumula=
te(std::begin(il), std::end(il), size_t{}, [](size_t sz, std::string_view s=
v){ <span style=3D"color:rgb(186,45,162)">return</span> sz + sv.size(); }))=
;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">for</span> (std::string_view sv : il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s +=3D sv=
;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(186,45,162)">template<span style=3D"color:rgb=
(0,0,0)"><</span>typename<span style=3D"color:rgb(0,0,0)">... Ts></sp=
an></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">std::string StringCat(Ts&&...=
ts)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> StringCat({std::string_view(std::forward<Ts=
>(ts))...});</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><span>Note that<br>a proper implementation would con=
strain the elements of the parameter pack to be of type<br>std::string (any=
maybe derived classes).<br></span></div></blockquote><div><br></div><div>W=
hich is a large constraint that the implementation above doesn't have.<=
/div><div><br></div><div><br></div><div>This would be a not insignificant l=
anguage change for something that is ultimately very restrictive compared w=
ith the functional version we can write today.=C2=A0 Doesn't seem worth=
it.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.com</a>> =C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BPKKqN%3Dmmju6vgaZMoJ3uKjbFkw=
gBnxORs3ECtxojT8Tg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPKKq=
N%3Dmmju6vgaZMoJ3uKjbFkwgBnxORs3ECtxojT8Tg%40mail.gmail.com</a>.<br />
--001a113ef3686c4af305641d6bbf--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 31 Jan 2018 19:47:02 -0800 (PST)
Raw View
------=_Part_20787_392681474.1517456822290
Content-Type: multipart/alternative;
boundary="----=_Part_20788_170585352.1517456822290"
------=_Part_20788_170585352.1517456822290
Content-Type: text/plain; charset="UTF-8"
On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <manuel.f...@gmail.com
> <javascript:>> wrote:
>
>> The solution is to use a variadic function like Abseil's StrCat() [1],
>> for example. Since the
>> function sees all strings at once, it can sum up their sizes, allocate
>> the final memory once
>> and copy one string after another to the output.
>>
>
> And you haven't justified the downside to this solution, especially since
> such a function is fairly simple to write in C++17:
>
> std::string StringCat(std::initializer_list<std::string_view> il)
>
> {
>
> std::string s;
>
> s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},
> [](size_t sz, std::string_view sv){ return sz + sv.size(); }));
>
> for (std::string_view sv : il)
>
> s += sv;
>
>
> return s;
>
> }
>
>
> template<typename... Ts>
>
> std::string StringCat(Ts&&... ts)
>
> {
>
> return StringCat({std::string_view(std::forward<Ts>(ts))...});
>
> }
>
> Note that
>> a proper implementation would constrain the elements of the parameter
>> pack to be of type
>> std::string (any maybe derived classes).
>>
>
> Which is a large constraint that the implementation above doesn't have.
>
>
> This would be a not insignificant language change for something that is
> ultimately very restrictive compared with the functional version we can
> write today. Doesn't seem worth it.
>
To be fair, the point of the proposal is to optimize the code people
already write. That is, nobody writes "StringCat({str1, str2, str3, ...});`
They write `str1 + str2 + str3 + ...`. It's the most obvious way to do it,
and it works; therefore, it should work* efficiently*.
Now personally, I would say that we simply shouldn't have operator+ for
concatenating strings, but there we are...
The other thing is that the string example is only one of (presumably) many
such examples. While string concatenation can reasonably be done with
function calls, the whole point of operator overloading is that you get to
make your code look more like what it is clearly doing. For mathematical
types, creating excessive numbers of temporaries as part of computing some
math equation is unnecessary and wasteful.
The main problem I see with this proposal is that it is very rare that, if
you write out a complex math equation in code, that you will be using *the
same operator*. This proposal only works based on repeating the same
operator, so it does little to resolve the temporary problem in general.
That's not to say that there cannot be times when this could help. But it's
not nearly often enough to be useful in most cases that actually deserve to
be using operator overloading (ie: not `string` operator+).
>
--
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/60e35557-f3a5-4b49-8d80-a99696fc2385%40isocpp.org.
------=_Part_20788_170585352.1517456822290
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5=
, Nevin ":-)" Liber 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"ltr">On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <=
span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;" href=
=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=
=3D"x-eB_eN8BgAJ">manuel.f...@gmail.com</a>></span> wrote:<br><div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span>The solution =
is to use a variadic function like Abseil's StrCat() [1], for example. =
Since the<br>function sees all strings at once, it can sum up their sizes, =
allocate the final memory once<br>and copy one string after another to the =
output.<br></span></div></blockquote><div><br></div><div>And you haven'=
t justified the downside to this solution, especially since such a function=
is fairly simple to write in C++17:</div><div><br></div><div><p style=3D"m=
argin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family=
:Menlo;color:rgb(0,0,0)">std::string StringCat(std::initializer_<wbr>list&l=
t;std::string_view> il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 std::string s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 s.reserve(std::accumula=
te(std:<wbr>:begin(il), std::end(il), size_t{}, [](size_t sz, std::string_v=
iew sv){ <span style=3D"color:rgb(186,45,162)">return</span> sz + sv.size()=
; }));</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">for</span> (std::string_view sv : il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s +=3D sv=
;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(186,45,162)">template<span style=3D"color:rgb=
(0,0,0)"><</span>typename<span style=3D"color:rgb(0,0,0)">... Ts></sp=
an></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">std::string StringCat(Ts&&...=
ts)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> StringCat({std::string_view(<wbr>std::forward&=
lt;Ts>(ts))...});</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><span>Note that<br>a proper implementation would con=
strain the elements of the parameter pack to be of type<br>std::string (any=
maybe derived classes).<br></span></div></blockquote><div><br></div><div>W=
hich is a large constraint that the implementation above doesn't have.<=
/div><div><br></div><div><br></div><div>This would be a not insignificant l=
anguage change for something that is ultimately very restrictive compared w=
ith the functional version we can write today.=C2=A0 Doesn't seem worth=
it.</div></div></div></div></blockquote><div><br></div><div>To be fair, th=
e point of the proposal is to optimize the code people already write. That =
is, nobody writes "StringCat({str1, str2, str3, ...});` They write `st=
r1 + str2 + str3 + ...`. It's the most obvious way to do it, and it wor=
ks; therefore, it should work<i> efficiently</i>.</div><div><br></div><div>=
Now personally, I would say that we simply shouldn't have operator+ for=
concatenating strings, but there we are...</div><div><i><br></i></div><div=
>The other thing is that the string example is only one of (presumably) man=
y such examples. While string concatenation can reasonably be done with fun=
ction calls, the whole point of operator overloading is that you get to mak=
e your code look more like what it is clearly doing. For mathematical types=
, creating excessive numbers of temporaries as part of computing some math =
equation is unnecessary and wasteful.</div><div><br></div><div>The main pro=
blem I see with this proposal is that it is very rare that, if you write ou=
t a complex math equation in code, that you will be using <i>the same opera=
tor</i>. This proposal only works based on repeating the same operator, so =
it does little to resolve the temporary problem in general.</div><div><br><=
/div><div>That's not to say that there cannot be times when this could =
help. But it's not nearly often enough to be useful in most cases that =
actually deserve to be using operator overloading (ie: not `string` operato=
r+).</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/60e35557-f3a5-4b49-8d80-a99696fc2385%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/60e35557-f3a5-4b49-8d80-a99696fc2385=
%40isocpp.org</a>.<br />
------=_Part_20788_170585352.1517456822290--
------=_Part_20787_392681474.1517456822290--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Thu, 1 Feb 2018 06:04:49 +0000
Raw View
--001a113ce66ea9073e0564205ff4
Content-Type: text/plain; charset="UTF-8"
On 1 Feb 2018 03:47, "Nicol Bolas" <jmckesson@gmail.com> wrote:
To be fair, the point of the proposal is to optimize the code people
already write. That is, nobody writes "StringCat({str1, str2, str3, ...});`
They write `str1 + str2 + str3 + ...`. It's the most obvious way to do it,
and it works; therefore, it should work* efficiently*.
I agree. This could have some noticeable impact on a lot of existing code.
Now personally, I would say that we simply shouldn't have operator+ for
concatenating strings, but there we are...
I know this is a controversial thing for a C++ developer to say, but I find
the stringstream approach (which, as far as I am aware, is the standard way
of getting around the issues multiple string concatenation) frustrating. It
obviously has a place, but it always bugged me to have to bring in a
toolbox for such a simple operation. I just think that common operations
should be writable with very little effort.
Here is where I'm really going to make you cringe: I'd like to have string
operator+(int) by default too. In terms of elegant code:
string s = "my age is "+age;
is as straightforward as it gets, maybe going one step further (perhaps
with some decoration to distinguish from current code)
string s = "my age is ${age}";
But I think that's enough torture for you for now.
The other thing is that the string example is only one of (presumably) many
such examples. While string concatenation can reasonably be done with
function calls, the whole point of operator overloading is that you get to
make your code look more like what it is clearly doing. For mathematical
types, creating excessive numbers of temporaries as part of computing some
math equation is unnecessary and wasteful.
This brings up an interesting point. A lot of code does, in fact, do this
explicitly with += over a few statements simply because there is no
difference (much of the time). That won't be remedied by variadic
operators, which is a shame.
There are certainly cases to be made for areas like geometry, where more
efficient approaches of multi-object arithmetic exist from mathematical
arguments - e.g. the vector triple product. Obviously we can get around
that by writing named functions, but the idea of incorporating that into
normal syntax is nice.
Manuel, I know this isnt in the direction you were thinking, but might this
also be extended to work with operator[]? And what about being able to
define an operator with N arguments without having an operator with (N-1)
arguments? There might be some fun to be had with universal algebra. But in
more common usage, just to combine my two above questions into an example:
template<typename T, size_t rows, size_t cols>
class matrix{
protected:
std::array<T, rows*cols> values;
public
T& operator[](const size_t& i, const size_t& j){
return values[i*rows + j];
}
};
matrix<int, 3, 3> m;
matrix[2]; // error.
matrix[2][1]; // fine
Of course, the operator() approach is nicer, but I'm just throwing that out
there. I'm sure there are better use cases for variadic operator[].
--
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/CAC%2B0CCM17Yu2uQj-0t0AcVurXTe-xeOpBqcguCjATaO0TX7QKg%40mail.gmail.com.
--001a113ce66ea9073e0564205ff4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 1 Feb 2018 03:47, "Nicol Bolas" <<a href=3D"mailto:jmckes=
son@gmail.com">jmckesson@gmail.com</a>> wrote:<blockquote class=3D"quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>To be fair, the point of the proposal is to optimize t=
he code people already write. That is, nobody writes "StringCat({str1,=
str2, str3, ...});` They write `str1 + str2 + str3 + ...`. It's the mo=
st obvious way to do it, and it works; therefore, it should work<i> efficie=
ntly</i>.</div></div></blockquote></div></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">I agree. This could have some noticeable impact on a=
lot of existing code.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Now personally, I would say that we simply shouldn=
't have operator+ for concatenating strings, but there we are...<br></d=
iv></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">I know this is a controversial thing for a C++ developer to say,=
but I find the stringstream approach (which, as far as I am aware, is the =
standard way of getting around the issues multiple string concatenation) fr=
ustrating. It obviously has a place, but it always bugged me to have to bri=
ng in a toolbox for such a simple operation. I just think that common opera=
tions should be writable with very little effort.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Here is where I'm really going to make you cr=
inge: I'd like to have string operator+(int) by default too. In terms o=
f elegant code:</div><div dir=3D"auto">=C2=A0 =C2=A0 string s =3D "my =
age is "+age;</div><div dir=3D"auto">is as straightforward as it gets,=
maybe going one step further (perhaps with some decoration to distinguish =
from current code)</div><div dir=3D"auto">=C2=A0 =C2=A0 string s =3D "=
my age is ${age}";<br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">But I think that's enough torture for you for now.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>The=
other thing is that the string example is only one of (presumably) many su=
ch examples. While string concatenation can reasonably be done with functio=
n calls, the whole point of operator overloading is that you get to make yo=
ur code look more like what it is clearly doing. For mathematical types, cr=
eating excessive numbers of temporaries as part of computing some math equa=
tion is unnecessary and wasteful.<br></div></div></blockquote></div></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">This brings up an intere=
sting point. A lot of code does, in fact, do this explicitly with +=3D over=
a few statements simply because there is no difference (much of the time).=
That won't be remedied by variadic operators, which is a shame.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">There are certainly cases to b=
e made for areas like geometry, where more efficient approaches of multi-ob=
ject arithmetic exist from mathematical arguments - e.g. the vector triple =
product. Obviously we can get around that by writing named functions, but t=
he idea of incorporating that into normal syntax is nice.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Manuel, I kno=
w this isnt in the direction you were thinking, but might this also be exte=
nded to work with operator[]? And what about being able to define an operat=
or with N arguments without having an operator with (N-1) arguments? There =
might be some fun to be had with universal algebra. But in more common usag=
e, just to combine my two above questions into an example:<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">template<typename T, size_t rows,=
size_t cols></div><div dir=3D"auto">class matrix{</div><div dir=3D"auto=
">protected:</div><div dir=3D"auto">=C2=A0 =C2=A0 std::array<T, rows*col=
s> values;</div><div dir=3D"auto">public</div><div dir=3D"auto">=C2=A0 =
=C2=A0 T& operator[](const size_t& i, const size_t& j){</div><d=
iv dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return values[i*r=
ows + j];</div><div dir=3D"auto">=C2=A0 =C2=A0 }</div><div dir=3D"auto">};<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">matrix<int, 3, 3> =
m;</div><div dir=3D"auto">matrix[2]; // error.</div><div dir=3D"auto">matri=
x[2][1]; // fine</div><div dir=3D"auto"><br></div><div dir=3D"auto">Of cour=
se, the operator() approach is nicer, but I'm just throwing that out th=
ere. I'm sure there are better use cases for variadic operator[].</div>=
<div dir=3D"auto"></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAC%2B0CCM17Yu2uQj-0t0AcVurXTe-xeOpBq=
cguCjATaO0TX7QKg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCM17Yu2=
uQj-0t0AcVurXTe-xeOpBqcguCjATaO0TX7QKg%40mail.gmail.com</a>.<br />
--001a113ce66ea9073e0564205ff4--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 1 Feb 2018 00:56:19 -0600
Raw View
--001a11458ea63de6460564211ae0
Content-Type: text/plain; charset="UTF-8"
On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber
> wrote:
>>
>> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <manuel.f...@gmail.com
>> > wrote:
>>
>>> The solution is to use a variadic function like Abseil's StrCat() [1],
>>> for example. Since the
>>> function sees all strings at once, it can sum up their sizes, allocate
>>> the final memory once
>>> and copy one string after another to the output.
>>>
>>
>> And you haven't justified the downside to this solution, especially since
>> such a function is fairly simple to write in C++17:
>>
>> std::string StringCat(std::initializer_list<std::string_view> il)
>>
>> {
>>
>> std::string s;
>>
>> s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},
>> [](size_t sz, std::string_view sv){ return sz + sv.size(); }));
>>
>> for (std::string_view sv : il)
>>
>> s += sv;
>>
>>
>> return s;
>>
>> }
>>
>>
>> template<typename... Ts>
>>
>> std::string StringCat(Ts&&... ts)
>>
>> {
>>
>> return StringCat({std::string_view(std::forward<Ts>(ts))...});
>>
>> }
>>
>> Note that
>>> a proper implementation would constrain the elements of the parameter
>>> pack to be of type
>>> std::string (any maybe derived classes).
>>>
>>
>> Which is a large constraint that the implementation above doesn't have.
>>
>>
>> This would be a not insignificant language change for something that is
>> ultimately very restrictive compared with the functional version we can
>> write today. Doesn't seem worth it.
>>
>
> To be fair, the point of the proposal is to optimize the code people
> already write. That is, nobody writes "StringCat({str1, str2, str3, ...});`
>
I'm not asking anyone to write that; it is just the helper for the template
function.
They can write:
StringCat("One", std::string("Two"), std::string_view("Three"));
Which returns the equivalent of a std::string("OneTwoThree")
and has the intended efficiency with respect to possible heap allocations.
Given a C string literal, a std::string and a std::string_view, you cannot
get that same heap efficiency with the proposal.
Yet strings are inefficiently built that way. For example, I've seen
plenty of code of the form:
std::string path = std::string(dir) + "/" + basename + ".ext";
> They write `str1 + str2 + str3 + ...`. It's the most obvious way to do it,
> and it works; therefore, it should work* efficiently*.
>
Make the above path example work efficiently (no more potential heap
allocations) with his proposal. Good luck.
The other thing is that the string example is only one of (presumably) many
> such examples.
>
We've been programming in C++ for decades. Show them.
> While string concatenation can reasonably be done with function calls, the
> whole point of operator overloading is that you get to make your code look
> more like what it is clearly doing. For mathematical types, creating
> excessive numbers of temporaries as part of computing some math equation is
> unnecessary and wasteful.
>
Again, please point to actual examples.
That's not to say that there cannot be times when this could help. But it's
> not nearly often enough to be useful in most cases that actually deserve to
> be using operator overloading (ie: not `string` operator+).
>
Every idea has at least one use case. The bar tends to be a bit higher
than that for adding something to the standard.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com.
--001a11458ea63de6460564211ae0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, Ja=
nuary 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber wrote:<span=
class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tue, Jan 30, 2018 at=
2:45 PM, Manuel Freiberger <span dir=3D"ltr"><<a rel=3D"nofollow">manue=
l.f...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><span>The solution is to use a variadic fu=
nction like Abseil's StrCat() [1], for example. Since the<br>function s=
ees all strings at once, it can sum up their sizes, allocate the final memo=
ry once<br>and copy one string after another to the output.<br></span></div=
></blockquote><div><br></div><div>And you haven't justified the downsid=
e to this solution, especially since such a function is fairly simple to wr=
ite in C++17:</div><div><br></div><div><p style=3D"margin:0px;font-stretch:=
normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)=
">std::string StringCat(std::initializer_lis<wbr>t<std::string_view> =
il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 std::string s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 s.reserve(std::accumula=
te(std:<wbr>:begin(il), std::end(il), size_t{}, [](size_t sz, std::string_v=
iew sv){ <span style=3D"color:rgb(186,45,162)">return</span> sz + sv.size()=
; }));</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">for</span> (std::string_view sv : il)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s +=3D sv=
;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> s;</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:12px;line-height:norma=
l;font-family:Helvetica;min-height:14px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(186,45,162)">template<span style=3D"color:rgb=
(0,0,0)"><</span>typename<span style=3D"color:rgb(0,0,0)">... Ts></sp=
an></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">std::string StringCat(Ts&&...=
ts)</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">{</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> StringCat({std::string_view(st<wbr>d::forward&=
lt;Ts>(ts))...});</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)">}</p></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><span>Note that<br>a proper implementation would con=
strain the elements of the parameter pack to be of type<br>std::string (any=
maybe derived classes).<br></span></div></blockquote><div><br></div><div>W=
hich is a large constraint that the implementation above doesn't have.<=
/div><div><br></div><div><br></div><div>This would be a not insignificant l=
anguage change for something that is ultimately very restrictive compared w=
ith the functional version we can write today.=C2=A0 Doesn't seem worth=
it.</div></div></div></div></blockquote><div><br></div></span><div>To be f=
air, the point of the proposal is to optimize the code people already write=
.. That is, nobody writes "StringCat({str1, str2, str3, ...});`</div></=
div></blockquote><div><br></div><div>I'm not asking anyone to write tha=
t; it is just the helper for the template function.</div><div><br></div><di=
v>They can write:</div><div><br></div><div><p style=3D"margin:0px;font-stre=
tch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,=
0,0)">StringCat(<span style=3D"color:rgb(209,47,27)">"One"</span>=
, std::string(<span style=3D"color:rgb(209,47,27)">"Two"</span>),=
std::string_view(<span style=3D"color:rgb(209,47,27)">"Three"</s=
pan>));</p></div><div><br></div><div>Which returns the equivalent of a std:=
:string("OneTwoThree")</div><div><br></div><div>and has the inten=
ded efficiency with respect to possible heap allocations.</div><div><br></d=
iv><div><br></div><div>Given a C string literal, a std::string and a std::s=
tring_view, you cannot get that same heap efficiency with the proposal.</di=
v><div><br></div><div>Yet strings are inefficiently built that way.=C2=A0 F=
or example, I've seen plenty of code of the form:</div><div><br></div><=
div>std::string path =3D std::string(dir) + "/" + basename + &quo=
t;.ext";</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
They write `str1 + str2 + str3 + ...`. It's the most obvious way to do=
it, and it works; therefore, it should work<i> efficiently</i>.</div></div=
></blockquote><div><br></div><div>Make the above path example work efficien=
tly (no more potential heap allocations) with his proposal.=C2=A0 Good luck=
..</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>The other thing is that the string example is only one of (presumably) man=
y such examples. </div></div></blockquote><div><br></div><div>We've bee=
n programming in C++ for decades.=C2=A0 Show them.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>While string concatenation can reasona=
bly be done with function calls, the whole point of operator overloading is=
that you get to make your code look more like what it is clearly doing. Fo=
r mathematical types, creating excessive numbers of temporaries as part of =
computing some math equation is unnecessary and wasteful.</div></div></bloc=
kquote><div><br></div><div>Again, please point to actual examples.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>That's not to say th=
at there cannot be times when this could help. But it's not nearly ofte=
n enough to be useful in most cases that actually deserve to be using opera=
tor overloading (ie: not `string` operator+).</div></div></blockquote><div>=
<br></div><div>Every idea has at least one use case.=C2=A0 The bar tends to=
be a bit higher than that for adding something to the standard.</div></div=
>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailt=
o:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></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" 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/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJL=
QyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%3D=
i8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com</a>.<br />
--001a11458ea63de6460564211ae0--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Thu, 1 Feb 2018 10:25:55 +0100
Raw View
--001a114b30e2d370730564232e1d
Content-Type: text/plain; charset="UTF-8"
>
> The other thing is that the string example is only one of (presumably)
> many such examples.
>
> We've been programming in C++ for decades. Show them.
Lets do not care about memory in next examples.
std::math::vector<double, 1000> a,b,c,d; // Mathematical vector
or strong type of std::array<double, 1000> if preferred.
a = b + c + d; // There are 2 consecutive loops behind this expression.
Lets extend this proposal in to *expression overloading*:
double x,y;
a = b + x*c + y*d; // There are 4 consecutive loops behind this
expression.
Now if in some point *expression overloading *become possible above
expression we can put on some number crunching processor e.g. GPU.
More complex example:
std::math::matrix< double, 1000 > m, n; // Square matrix.
a = b + m*c + n*d; // Utilizing GPU m*c and n*d can be done in parallel,
and one loop to sum all vectors.
On Thu, Feb 1, 2018 at 7:56 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber
>> wrote:
>>>
>>> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <
>>> manuel.f...@gmail.com> wrote:
>>>
>>>> The solution is to use a variadic function like Abseil's StrCat() [1],
>>>> for example. Since the
>>>> function sees all strings at once, it can sum up their sizes, allocate
>>>> the final memory once
>>>> and copy one string after another to the output.
>>>>
>>>
>>> And you haven't justified the downside to this solution, especially
>>> since such a function is fairly simple to write in C++17:
>>>
>>> std::string StringCat(std::initializer_list<std::string_view> il)
>>>
>>> {
>>>
>>> std::string s;
>>>
>>> s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},
>>> [](size_t sz, std::string_view sv){ return sz + sv.size(); }));
>>>
>>> for (std::string_view sv : il)
>>>
>>> s += sv;
>>>
>>>
>>> return s;
>>>
>>> }
>>>
>>>
>>> template<typename... Ts>
>>>
>>> std::string StringCat(Ts&&... ts)
>>>
>>> {
>>>
>>> return StringCat({std::string_view(std::forward<Ts>(ts))...});
>>>
>>> }
>>>
>>> Note that
>>>> a proper implementation would constrain the elements of the parameter
>>>> pack to be of type
>>>> std::string (any maybe derived classes).
>>>>
>>>
>>> Which is a large constraint that the implementation above doesn't have.
>>>
>>>
>>> This would be a not insignificant language change for something that is
>>> ultimately very restrictive compared with the functional version we can
>>> write today. Doesn't seem worth it.
>>>
>>
>> To be fair, the point of the proposal is to optimize the code people
>> already write. That is, nobody writes "StringCat({str1, str2, str3, ...});`
>>
>
> I'm not asking anyone to write that; it is just the helper for the
> template function.
>
> They can write:
>
> StringCat("One", std::string("Two"), std::string_view("Three"));
>
> Which returns the equivalent of a std::string("OneTwoThree")
>
> and has the intended efficiency with respect to possible heap allocations.
>
>
> Given a C string literal, a std::string and a std::string_view, you cannot
> get that same heap efficiency with the proposal.
>
> Yet strings are inefficiently built that way. For example, I've seen
> plenty of code of the form:
>
> std::string path = std::string(dir) + "/" + basename + ".ext";
>
>
>> They write `str1 + str2 + str3 + ...`. It's the most obvious way to do
>> it, and it works; therefore, it should work* efficiently*.
>>
>
> Make the above path example work efficiently (no more potential heap
> allocations) with his proposal. Good luck.
>
>
> The other thing is that the string example is only one of (presumably)
>> many such examples.
>>
>
> We've been programming in C++ for decades. Show them.
>
>
>> While string concatenation can reasonably be done with function calls,
>> the whole point of operator overloading is that you get to make your code
>> look more like what it is clearly doing. For mathematical types, creating
>> excessive numbers of temporaries as part of computing some math equation is
>> unnecessary and wasteful.
>>
>
> Again, please point to actual examples.
>
> That's not to say that there cannot be times when this could help. But
>> it's not nearly often enough to be useful in most cases that actually
>> deserve to be using operator overloading (ie: not `string` operator+).
>>
>
> Every idea has at least one use case. The bar tends to be a bit higher
> than that for adding something to the standard.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
> <(847)%20691-1404>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%3Di8R2FA_
> gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?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/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com.
--001a114b30e2d370730564232e1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid"><div dir=3D"ltr"><div>The other thing is =
that the string example is only one of (presumably) many such examples. </d=
iv></div></blockquote><div>> We've been programming in C++ for decad=
es.=C2=A0 Show them.</div><div><br></div><div>Lets do not care about memory=
in next examples.</div><div><font face=3D"monospace,monospace">=C2=A0=C2=
=A0=C2=A0 std::math::vector<double, 1000> a,b,c,d; // Mathematical ve=
ctor or=C2=A0strong type of std::array<double, 1000> if preferred.</f=
ont></div><div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D =
b + c + d; // There are=C2=A02 consecutive loops behind this expression. </=
font></div><div><br></div><div>Lets extend this=C2=A0proposal in to <strong=
><em>expression overloading</em></strong>:</div><div><font face=3D"monospac=
e,monospace">=C2=A0=C2=A0=C2=A0 double x,y;</font></div><div><div><font fac=
e=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D b + x*c + y*d; // There =
are=C2=A04 consecutive loops behind this expression. </font></div><div><fon=
t face=3D"Courier New"><br></font></div><div><font face=3D"arial,helvetica,=
sans-serif">Now if=C2=A0in some point <em><strong>expression overloading</s=
trong> </em>become possible above expression=C2=A0we can put on some number=
crunching processor e.g. GPU.=C2=A0</font></div><font face=3D"Courier New"=
></font></div><p><div><font face=3D"Courier New"><font face=3D"arial,helvet=
ica,sans-serif">More complex example:</font></font></div><div><font face=3D=
"Courier New"><font face=3D"arial,helvetica,sans-serif">=C2=A0=C2=A0=C2=A0 =
<font face=3D"Courier New"><font face=3D"monospace,monospace">std::math::ma=
trix< double, 1000 > m, n; // Square matrix.</font></font></font></fo=
nt></div><font face=3D"Courier New"><font face=3D"arial,helvetica,sans-seri=
f"><font face=3D"Courier New"><div><div><font face=3D"monospace,monospace">=
=C2=A0=C2=A0a =3D b + m*c + n*d; //=C2=A0Utilizing GPU m*c and n*d can be d=
one in parallel, and one loop to sum all vectors.<br></font></div></div></f=
ont></font></font><p></p><div><br></div></p></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Thu, Feb 1, 2018 at 7:56 AM, Nevin Libe=
r <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span>On Wed, Jan 31, 2018 at 9:47 PM, Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br></span><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><br><br>On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin =
":-)" Liber wrote:<span class=3D"m_-1044431518825900004gmail-"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-l=
eft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-lef=
t-style:solid"><div dir=3D"ltr">On Tue, Jan 30, 2018 at 2:45 PM, Manuel Fre=
iberger <span dir=3D"ltr"><<a rel=3D"nofollow">manuel.f...@gmail.com</a>=
></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left=
-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div=
dir=3D"ltr"><span>The solution is to use a variadic function like Abseil&#=
39;s StrCat() [1], for example. Since the<br>function sees all strings at o=
nce, it can sum up their sizes, allocate the final memory once<br>and copy =
one string after another to the output.<br></span></div></blockquote><div><=
br></div><div>And you haven't justified the downside to this solution, =
especially since such a function is fairly simple to write in C++17:</div><=
div><br></div><div><p style=3D"margin:0px;color:rgb(0,0,0);line-height:norm=
al;font-family:Menlo;font-size:11px;font-stretch:normal">std::string String=
Cat(std::initializer_lis<wbr>t<std::string_view> il)</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">{</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 std::string s;</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 s.reserve(std::accumula=
te(std:<wbr>:begin(il), std::end(il), size_t{}, [](size_t sz, std::string_v=
iew sv){ <span style=3D"color:rgb(186,45,162)">return</span> sz + sv.size()=
; }));</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">for</span> (std::string_view sv : il)</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s +=3D sv=
;</p>
<p style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:1=
2px;min-height:14px;font-stretch:normal"><br></p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> s;</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">}</p>
<p style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:1=
2px;min-height:14px;font-stretch:normal"><br></p>
<p style=3D"margin:0px;color:rgb(186,45,162);line-height:normal;font-family=
:Menlo;font-size:11px;font-stretch:normal">template<span style=3D"color:rgb=
(0,0,0)"><</span>typename<span style=3D"color:rgb(0,0,0)">... Ts></sp=
an></p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">std::string StringCat(Ts&&...=
ts)</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">{</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">=C2=A0 =C2=A0 <span style=3D"color:rg=
b(186,45,162)">return</span> StringCat({std::string_view(st<wbr>d::forward&=
lt;Ts>(ts))...});</p>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menl=
o;font-size:11px;font-stretch:normal">}</p></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr"><span>Note that<br>a proper implementation would con=
strain the elements of the parameter pack to be of type<br>std::string (any=
maybe derived classes).<br></span></div></blockquote><div><br></div><div>W=
hich is a large constraint that the implementation above doesn't have.<=
/div><div><br></div><div><br></div><div>This would be a not insignificant l=
anguage change for something that is ultimately very restrictive compared w=
ith the functional version we can write today.=C2=A0 Doesn't seem worth=
it.</div></div></div></div></blockquote><div><br></div></span><div>To be f=
air, the point of the proposal is to optimize the code people already write=
.. That is, nobody writes "StringCat({str1, str2, str3, ...});`</div></=
div></blockquote><div><br></div></span><div>I'm not asking anyone to wr=
ite that; it is just the helper for the template function.</div><div><br></=
div><div>They can write:</div><div><br></div><div><p style=3D"margin:0px;co=
lor:rgb(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-str=
etch:normal">StringCat(<span style=3D"color:rgb(209,47,27)">"One"=
</span>, std::string(<span style=3D"color:rgb(209,47,27)">"Two"</=
span>), std::string_view(<span style=3D"color:rgb(209,47,27)">"Three&q=
uot;</span>));</p></div><div><br></div><div>Which returns the equivalent of=
a std::string("OneTwoThree")</div><div><br></div><div>and has th=
e intended efficiency with respect to possible heap allocations.</div><div>=
<br></div><div><br></div><div>Given a C string literal, a std::string and a=
std::string_view, you cannot get that same heap efficiency with the propos=
al.</div><div><br></div><div>Yet strings are inefficiently built that way.=
=C2=A0 For example, I've seen plenty of code of the form:</div><div><br=
></div><div>std::string path =3D std::string(dir) + "/" + basenam=
e + ".ext";</div><span><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div> They write `str1 + str2 + str3 + ...`. It's the most obv=
ious way to do it, and it works; therefore, it should work<i> efficiently</=
i>.</div></div></blockquote><div><br></div></span><div>Make the above path =
example work efficiently (no more potential heap allocations) with his prop=
osal.=C2=A0 Good luck.</div><span><div><br></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr"><div>The other thing is that the string example is o=
nly one of (presumably) many such examples. </div></div></blockquote><div><=
br></div></span><div>We've been programming in C++ for decades.=C2=A0 S=
how them.</div><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,2=
04,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><di=
v>While string concatenation can reasonably be done with function calls, th=
e whole point of operator overloading is that you get to make your code loo=
k more like what it is clearly doing. For mathematical types, creating exce=
ssive numbers of temporaries as part of computing some math equation is unn=
ecessary and wasteful.</div></div></blockquote><div><br></div></span><div>A=
gain, please point to actual examples.</div><span><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div dir=3D"ltr"><div>That's not to say that there cannot be tim=
es when this could help. But it's not nearly often enough to be useful =
in most cases that actually deserve to be using operator overloading (ie: n=
ot `string` operator+).</div></div></blockquote><div><br></div></span><div>=
Every idea has at least one use case.=C2=A0 The bar tends to be a bit highe=
r than that for adding something to the standard.</div></div><span>-- <br><=
div class=3D"m_-1044431518825900004gmail_signature"><div dir=3D"ltr"><div><=
div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" target=3D"_blank" =
value=3D"+18476911404">+1-847-691-1404</a></div></div></div></div></div>
</span></div></div>
<p></p>
-- <br><span>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>.<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/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJL=
QyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAGg_6%2BN%3Di8R2FA_<wbr>gC92zYSOrF5DCiDJLQyCgdoN1Wp0HO<=
wbr>i93rA%40mail.gmail.com</a>.<br>
</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" 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/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0Hrr=
S%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjs=
KR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com</a>.<br />
--001a114b30e2d370730564232e1d--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 4 Feb 2018 12:51:40 +0200
Raw View
This is a multi-part message in MIME format.
--------------5F9D2699576E9EB720FF0DC5
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
It would be nice if we can get the compiler to switch to providing an=20
AST. The example
=C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n; // Square matri=
x.
=C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be don=
e in=20
parallel, and one loop to sum all vectors.
might compile to
=C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::assign(a, std::ast::sum(b,=
=20
std::ast::product(m ,c), std::ast::product(n, d)))
std::math::matrix would hint that we want delayed expression evaluation.=20
The default std::ast::evaluate() would fall back to regular evaluation,=20
but an overload of std::ast::evaluate() for those types would allow=20
compile-time rearranging of the ast.
On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:
>
> The other thing is that the string example is only one of
> (presumably) many such examples.
>
> > We've been programming in C++ for decades.=C2=A0 Show them.
>
> Lets do not care about memory in next examples.
> std::math::vector<double, 1000> a,b,c,d; // Mathematical vector=20
> or=C2=A0strong type of std::array<double, 1000> if preferred.
> =C2=A0=C2=A0=C2=A0 a =3D b + c + d; // There are=C2=A02 consecutive loops=
behind this=20
> expression.
>
> Lets extend this=C2=A0proposal in to */expression overloading/*:
> =C2=A0=C2=A0=C2=A0 double x,y;
> =C2=A0=C2=A0=C2=A0 a =3D b + x*c + y*d; // There are=C2=A04 consecutive l=
oops behind this=20
> expression.
>
> Now if=C2=A0in some point /*expression overloading* /become possible abov=
e=20
> expression=C2=A0we can put on some number crunching processor e.g. GPU.
> More complex example:
> std::math::matrix< double, 1000 > m, n; // Square matrix.
> =C2=A0=C2=A0a =3D b + m*c + n*d; //=C2=A0Utilizing GPU m*c and n*d can be=
done in=20
> parallel, and one loop to sum all vectors.
>
>
> On Thu, Feb 1, 2018 at 7:56 AM, Nevin Liber <nevin@eviloverlord.com=20
> <mailto:nevin@eviloverlord.com>> wrote:
>
> On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
>
>
>
> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin
> ":-)" Liber wrote:
>
> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger
> <manuel.f...@gmail.com> wrote:
>
> The solution is to use a variadic function like
> Abseil's StrCat() [1], for example. Since the
> function sees all strings at once, it can sum up their
> sizes, allocate the final memory once
> and copy one string after another to the output.
>
>
> And you haven't justified the downside to this solution,
> especially since such a function is fairly simple to write
> in C++17:
>
> std::string
> StringCat(std::initializer_list<std::string_view> il)
>
> {
>
> =C2=A0 std::string s;
>
> =C2=A0 s.reserve(std::accumulate(std::begin(il), std::end(il)=
,
> size_t{}, [](size_t sz, std::string_view sv){ return sz +
> sv.size(); }));
>
> for (std::string_view sv : il)
>
> =C2=A0 =C2=A0 =C2=A0 s +=3D sv;
>
>
> return s;
>
> }
>
>
> template<typename... Ts>
>
> std::string StringCat(Ts&&... ts)
>
> {
>
> return StringCat({std::string_view(std::forward<Ts>(ts))...})=
;
>
> }
>
>
> Note that
> a proper implementation would constrain the elements
> of the parameter pack to be of type
> std::string (any maybe derived classes).
>
>
> Which is a large constraint that the implementation above
> doesn't have.
>
>
> This would be a not insignificant language change for
> something that is ultimately very restrictive compared
> with the functional version we can write today.=C2=A0 Doesn't
> seem worth it.
>
>
> To be fair, the point of the proposal is to optimize the code
> people already write. That is, nobody writes "StringCat({str1,
> str2, str3, ...});`
>
>
> I'm not asking anyone to write that; it is just the helper for the
> template function.
>
> They can write:
>
> StringCat("One", std::string("Two"), std::string_view("Three"));
>
>
> Which returns the equivalent of a std::string("OneTwoThree")
>
> and has the intended efficiency with respect to possible heap
> allocations.
>
>
> Given a C string literal, a std::string and a std::string_view,
> you cannot get that same heap efficiency with the proposal.
>
> Yet strings are inefficiently built that way. For example, I've
> seen plenty of code of the form:
>
> std::string path =3D std::string(dir) + "/" + basename + ".ext";
>
> They write `str1 + str2 + str3 + ...`. It's the most obvious
> way to do it, and it works; therefore, it should
> work/efficiently/.
>
>
> Make the above path example work efficiently (no more potential
> heap allocations) with his proposal. Good luck.
>
>
> The other thing is that the string example is only one of
> (presumably) many such examples.
>
>
> We've been programming in C++ for decades.=C2=A0 Show them.
>
> While string concatenation can reasonably be done with
> function calls, the whole point of operator overloading is
> that you get to make your code look more like what it is
> clearly doing. For mathematical types, creating excessive
> numbers of temporaries as part of computing some math equation
> is unnecessary and wasteful.
>
>
> Again, please point to actual examples.
>
> That's not to say that there cannot be times when this could
> help. But it's not nearly often enough to be useful in most
> cases that actually deserve to be using operator overloading
> (ie: not `string` operator+).
>
>
> Every idea has at least one use case.=C2=A0 The bar tends to be a bit
> higher than that for adding something to the standard.
> --=20
> =C2=A0Nevin ":-)" Liber=C2=A0 <mailto:nevin@eviloverlord.com
> <mailto:nevin@eviloverlord.com>> +1-847-691-1404
> <tel:%28847%29%20691-1404>
> --=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 email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2=
BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%=
2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>.
>
>
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjsK=
R%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjs=
KR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>.
--=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/c4b49593-d18f-1514-7f29-64391add3969%40scylladb.=
com.
--------------5F9D2699576E9EB720FF0DC5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>It would be nice if we can get the compiler to switch to
providing an AST. The example<br>
</p>
<br>
=C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n; // Squ=
are matrix.<br>
=C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be =
done in
parallel, and one loop to sum all vectors.<br>
<br>
might compile to<br>
<br>
=C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::assign(a, std::ast::sum=
(b,
std::ast::product(m ,c), std::ast::product(n, d)))<br>
<br>
std::math::matrix would hint that we want delayed expression
evaluation. The default std::ast::evaluate() would fall back to
regular evaluation, but an overload of std::ast::evaluate() for
those types would allow compile-time rearranging of the ast.<br>
<br>
<br>
<div class=3D"moz-cite-prefix">On 02/01/2018 11:25 AM, Dejan
Milosavljevic wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CAEfefmxbjsKR+2Eb3bTuWLdh5h3JxT0HrrS+fe+Jzwp9H04bCQ@mail.gmail.=
com">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example is only one
of (presumably) many such examples. </div>
</div>
</blockquote>
<div>> We've been programming in C++ for decades.=C2=A0 Show the=
m.</div>
<div><br>
</div>
<div>Lets do not care about memory in next examples.</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0
std::math::vector<double, 1000> a,b,c,d; //
Mathematical vector or=C2=A0strong type of std::array<double=
,
1000> if preferred.</font></div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D b =
+ c + d; //
There are=C2=A02 consecutive loops behind this expression. </fo=
nt></div>
<div><br>
</div>
<div>Lets extend this=C2=A0proposal in to <strong><em>expression
overloading</em></strong>:</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 double x=
,y;</font></div>
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D =
b + x*c + y*d;
// There are=C2=A04 consecutive loops behind this expression.=
</font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"arial,helvetica,sans-serif">Now if=C2=A0in som=
e
point <em><strong>expression overloading</strong> </em>become
possible above expression=C2=A0we can put on some number
crunching processor e.g. GPU.=C2=A0</font></div>
</div>
<div><font face=3D"Courier New"><font
face=3D"arial,helvetica,sans-serif">More complex example:</fo=
nt></font></div>
<div><font face=3D"Courier New"><font
face=3D"arial,helvetica,sans-serif">=C2=A0=C2=A0=C2=A0 <font =
face=3D"Courier
New"><font face=3D"monospace,monospace">std::math::matrix&l=
t;
double, 1000 > m, n; // Square matrix.</font></font></=
font></font></div>
<font face=3D"Courier New"><font face=3D"arial,helvetica,sans-serif=
"><font
face=3D"Courier New">
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0a =3D b=
+ m*c +
n*d; //=C2=A0Utilizing GPU m*c and n*d can be done in
parallel, and one loop to sum all vectors.<br>
</font></div>
</div>
</font></font></font>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Thu, Feb 1, 2018 at 7:56 AM, Nevin
Liber <span dir=3D"ltr"><<a
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank"
moz-do-not-send=3D"true">nevin@eviloverlord.com</a>></span=
>
wrote:<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"><span>On Wed, Jan 31, 2018 at 9:47 PM, Nicol
Bolas <span dir=3D"ltr"><<a
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank"
moz-do-not-send=3D"true">jmckesson@gmail.com</a>></s=
pan>
wrote:<br>
</span>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote"><span>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><br>
<br>
On Wednesday, January 31, 2018 at 9:33:26 PM
UTC-5, Nevin ":-)" Liber wrote:<span
class=3D"m_-1044431518825900004gmail-">
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">On Tue, Jan 30, 2018 at 2:45
PM, Manuel Freiberger <span dir=3D"ltr"><<=
a
rel=3D"nofollow" moz-do-not-send=3D"true"=
>manuel.f...@gmail.com</a>></span>
wrote:<br>
<div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><span>The solution is
to use a variadic function like
Abseil's StrCat() [1], for
example. Since the<br>
function sees all strings at
once, it can sum up their sizes,
allocate the final memory once<br>
and copy one string after
another to the output.<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>And you haven't justified the
downside to this solution,
especially since such a function is
fairly simple to write in C++17:</div>
<div><br>
</div>
<div>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">std::string
StringCat(std::initializer_lis<wbr>t&=
lt;std::string_view>
il)</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">{</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 std::string s;</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 s.reserve(std::accumulate(std:=
<wbr>:begin(il),
std::end(il), size_t{}, [](size_t
sz, std::string_view sv){ <span
style=3D"color:rgb(186,45,162)">ret=
urn</span>
sz + sv.size(); }));</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,162)">for=
</span>
(std::string_view sv : il)</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 =C2=A0 =C2=A0 s +=3D sv;</p>
<p
style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:12px=
;min-height:14px;font-stretch:normal"><br>
</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,162)">ret=
urn</span>
s;</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">}</p>
<p
style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:12px=
;min-height:14px;font-stretch:normal"><br>
</p>
<p
style=3D"margin:0px;color:rgb(186,45,162);line-height:normal;font-family:Me=
nlo;font-size:11px;font-stretch:normal">template<span
style=3D"color:rgb(0,0,0)"><</sp=
an>typename<span
style=3D"color:rgb(0,0,0)">...
Ts></span></p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">std::string
StringCat(Ts&&... ts)</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">{</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,162)">ret=
urn</span>
StringCat({std::string_view(st<wbr>d:=
:forward<Ts>(ts))...});</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">}</p>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><span>Note that<br>
a proper implementation would
constrain the elements of the
parameter pack to be of type<br>
std::string (any maybe derived
classes).<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>Which is a large constraint that
the implementation above doesn't
have.</div>
<div><br>
</div>
<div><br>
</div>
<div>This would be a not insignificant
language change for something that
is ultimately very restrictive
compared with the functional version
we can write today.=C2=A0 Doesn't seem
worth it.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>To be fair, the point of the proposal is to
optimize the code people already write. That
is, nobody writes "StringCat({str1, str2,
str3, ...});`</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I'm not asking anyone to write that; it is just
the helper for the template function.</div>
<div><br>
</div>
<div>They can write:</div>
<div><br>
</div>
<div>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">StringCat(<span
style=3D"color:rgb(209,47,27)">"One"</span>,
std::string(<span style=3D"color:rgb(209,47,27)">"Two=
"</span>),
std::string_view(<span
style=3D"color:rgb(209,47,27)">"Three"</span>));</p=
>
</div>
<div><br>
</div>
<div>Which returns the equivalent of a
std::string("OneTwoThree")</div>
<div><br>
</div>
<div>and has the intended efficiency with respect to
possible heap allocations.</div>
<div><br>
</div>
<div><br>
</div>
<div>Given a C string literal, a std::string and a
std::string_view, you cannot get that same heap
efficiency with the proposal.</div>
<div><br>
</div>
<div>Yet strings are inefficiently built that way.=C2=A0
For example, I've seen plenty of code of the form:</div=
>
<div><br>
</div>
<div>std::string path =3D std::string(dir) + "/" +
basename + ".ext";</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div> They write `str1 + str2 + str3 + ...`.
It's the most obvious way to do it, and it
works; therefore, it should work<i>
efficiently</i>.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Make the above path example work efficiently (no
more potential heap allocations) with his proposal.=C2=
=A0
Good luck.</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example
is only one of (presumably) many such
examples. </div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>We've been programming in C++ for decades.=C2=A0 Sho=
w
them.</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>While string concatenation can reasonably
be done with function calls, the whole point
of operator overloading is that you get to
make your code look more like what it is
clearly doing. For mathematical types,
creating excessive numbers of temporaries as
part of computing some math equation is
unnecessary and wasteful.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Again, please point to actual examples.</div>
<span>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>That's not to say that there cannot be
times when this could help. But it's not
nearly often enough to be useful in most cases
that actually deserve to be using operator
overloading (ie: not `string` operator+).</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Every idea has at least one use case.=C2=A0 The bar
tends to be a bit higher than that for adding
something to the standard.</div>
</div>
<span>-- <br>
<div class=3D"m_-1044431518825900004gmail_signature">
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a
href=3D"mailto:nevin@eviloverlord.com"
target=3D"_blank" moz-do-not-send=3D"true">ne=
vin@eviloverlord.com</a><wbr>>
=C2=A0<a href=3D"tel:%28847%29%20691-1404"
target=3D"_blank" value=3D"+18476911404"
moz-do-not-send=3D"true">+1-847-691-1404</a><=
/div>
</div>
</div>
</div>
</div>
</span></div>
</div>
-- <br>
<span>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
target=3D"_blank" moz-do-not-send=3D"true">std-proposals+un=
subscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank"
moz-do-not-send=3D"true">std-proposals@isocpp.org</a>.<br>
</span>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6=
%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter"
target=3D"_blank" moz-do-not-send=3D"true">https://groups.goo=
gle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAGg_6%2BN%3Di8R2FA_<w=
br>gC92zYSOrF5DCiDJLQyCgdoN1Wp0HO<wbr>i93rA%40mail.gmail.com</a>.<br>
</blockquote>
</div>
<br>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfef=
mxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_me=
dium=3Demail&utm_source=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bC=
Q%40mail.gmail.com</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c4b49593-d18f-1514-7f29-64391add3969%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/c4b49593-d18f-1514-7f29-64391add39=
69%40scylladb.com</a>.<br />
--------------5F9D2699576E9EB720FF0DC5--
.
Author: florian.csdt@gmail.com
Date: Mon, 5 Feb 2018 00:31:51 -0800 (PST)
Raw View
------=_Part_4322_1080925614.1517819512089
Content-Type: multipart/alternative;
boundary="----=_Part_4323_1779022731.1517819512089"
------=_Part_4323_1779022731.1517819512089
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Then, what is the difference with usual expression templates?
Your "AST" looks really similar to Boost::Proto.
And it has the same main issue than Boost Proto (or any expression template=
=20
solution): You need to instantiate a hell lot of types.
The only difference with a compiler support and usual expression templates=
=20
is "auto" type deduction.
And *this* is the issue to solve.
BTW, already several proposals aim to solve this very problem of the auto=
=20
type deduction (don't remember which).
I don't think it would be a good idea to standardize Boost::Proto though.=
=20
But expression templates are relatively easy to implement for our own=20
custom types.
Florian
Le dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9crit :
>
> It would be nice if we can get the compiler to switch to providing an AST=
..=20
> The example
>
> std::math::matrix< double, 1000 > m, n; // Square matrix.
> a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be done in=20
> parallel, and one loop to sum all vectors.
>
> might compile to
>
> std::ast::evaluate(std::ast::assign(a, std::ast::sum(b,=20
> std::ast::product(m ,c), std::ast::product(n, d)))
>
> std::math::matrix would hint that we want delayed expression evaluation.=
=20
> The default std::ast::evaluate() would fall back to regular evaluation, b=
ut=20
> an overload of std::ast::evaluate() for those types would allow=20
> compile-time rearranging of the ast.
>
>
> On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:
>
> The other thing is that the string example is only one of (presumably)=20
>> many such examples.=20
>>
> > We've been programming in C++ for decades. Show them.
>
> Lets do not care about memory in next examples.
> std::math::vector<double, 1000> a,b,c,d; // Mathematical vector=20
> or strong type of std::array<double, 1000> if preferred.
> a =3D b + c + d; // There are 2 consecutive loops behind this=20
> expression.=20
>
> Lets extend this proposal in to *expression overloading*:
> double x,y;
> a =3D b + x*c + y*d; // There are 4 consecutive loops behind this=20
> expression.=20
>
> Now if in some point *expression overloading *become possible above=20
> expression we can put on some number crunching processor e.g. GPU.=20
> More complex example:
> std::math::matrix< double, 1000 > m, n; // Square matrix.
> a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be done in parall=
el,=20
> and one loop to sum all vectors.
>
>
> On Thu, Feb 1, 2018 at 7:56 AM, Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>> wrote:
>
>> On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <jmck...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>>
>>> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber=
=20
>>> wrote:=20
>>>>
>>>> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <
>>>> manuel.f...@gmail.com> wrote:
>>>>
>>>>> The solution is to use a variadic function like Abseil's StrCat() [1]=
,=20
>>>>> for example. Since the
>>>>> function sees all strings at once, it can sum up their sizes, allocat=
e=20
>>>>> the final memory once
>>>>> and copy one string after another to the output.
>>>>>
>>>>
>>>> And you haven't justified the downside to this solution, especially=20
>>>> since such a function is fairly simple to write in C++17:
>>>>
>>>> std::string StringCat(std::initializer_list<std::string_view> il)
>>>>
>>>> {
>>>>
>>>> std::string s;
>>>>
>>>> s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},=
=20
>>>> [](size_t sz, std::string_view sv){ return sz + sv.size(); }));
>>>>
>>>> for (std::string_view sv : il)
>>>>
>>>> s +=3D sv;
>>>>
>>>>
>>>> return s;
>>>>
>>>> }
>>>>
>>>>
>>>> template<typename... Ts>
>>>>
>>>> std::string StringCat(Ts&&... ts)
>>>>
>>>> {
>>>>
>>>> return StringCat({std::string_view(std::forward<Ts>(ts))...});
>>>>
>>>> }
>>>>
>>>> Note that
>>>>> a proper implementation would constrain the elements of the parameter=
=20
>>>>> pack to be of type
>>>>> std::string (any maybe derived classes).
>>>>>
>>>>
>>>> Which is a large constraint that the implementation above doesn't have=
..
>>>>
>>>>
>>>> This would be a not insignificant language change for something that i=
s=20
>>>> ultimately very restrictive compared with the functional version we ca=
n=20
>>>> write today. Doesn't seem worth it.
>>>>
>>>
>>> To be fair, the point of the proposal is to optimize the code people=20
>>> already write. That is, nobody writes "StringCat({str1, str2, str3, ...=
});`
>>>
>>
>> I'm not asking anyone to write that; it is just the helper for the=20
>> template function.
>>
>> They can write:
>>
>> StringCat("One", std::string("Two"), std::string_view("Three"));
>>
>> Which returns the equivalent of a std::string("OneTwoThree")
>>
>> and has the intended efficiency with respect to possible heap allocation=
s.
>>
>>
>> Given a C string literal, a std::string and a std::string_view, you=20
>> cannot get that same heap efficiency with the proposal.
>>
>> Yet strings are inefficiently built that way. For example, I've seen=20
>> plenty of code of the form:
>>
>> std::string path =3D std::string(dir) + "/" + basename + ".ext";
>> =20
>>
>>> They write `str1 + str2 + str3 + ...`. It's the most obvious way to do=
=20
>>> it, and it works; therefore, it should work* efficiently*.
>>>
>>
>> Make the above path example work efficiently (no more potential heap=20
>> allocations) with his proposal. Good luck.
>>
>>
>> The other thing is that the string example is only one of (presumably)=
=20
>>> many such examples.=20
>>>
>>
>> We've been programming in C++ for decades. Show them.
>> =20
>>
>>> While string concatenation can reasonably be done with function calls,=
=20
>>> the whole point of operator overloading is that you get to make your co=
de=20
>>> look more like what it is clearly doing. For mathematical types, creati=
ng=20
>>> excessive numbers of temporaries as part of computing some math equatio=
n is=20
>>> unnecessary and wasteful.
>>>
>>
>> Again, please point to actual examples.
>>
>> That's not to say that there cannot be times when this could help. But=
=20
>>> it's not nearly often enough to be useful in most cases that actually=
=20
>>> deserve to be using operator overloading (ie: not `string` operator+).
>>>
>>
>> Every idea has at least one use case. The bar tends to be a bit higher=
=20
>> than that for adding something to the standard.
>> --=20
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> =20
>> +1-847-691-1404
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%=
3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN=
%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjsK=
R%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjs=
KR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>
>
>
--=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/24f92a35-b67e-45cd-9493-77fb278a40c7%40isocpp.or=
g.
------=_Part_4323_1779022731.1517819512089
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Then, what is the difference with usual expression templat=
es?<br>Your "AST" looks really similar to Boost::Proto.<br>And it=
has the same main issue than Boost Proto (or any expression template solut=
ion): You need to instantiate a hell lot of types.<br><br>The only differen=
ce with a compiler support and usual expression templates is "auto&quo=
t; type deduction.<br>And <b>this</b> is the issue to solve.<br>BTW, alread=
y several proposals aim to solve this very problem of the auto type deducti=
on (don't remember which).<br><br>I don't think it would be a good =
idea to standardize Boost::Proto though. But expression templates are relat=
ively easy to implement for our own custom types.<br><br>Florian<br><br>Le =
dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9crit=C2=A0:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>It would be nice if we can get the compiler to switch to
providing an AST. The example<br>
</p>
<br>
=C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n; // Squ=
are matrix.<br>
=C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be =
done in
parallel, and one loop to sum all vectors.<br>
<br>
might compile to<br>
<br>
=C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::<wbr>assign(a, std::ast=
::sum(b,
std::ast::product(m ,c), std::ast::product(n, d)))<br>
<br>
std::math::matrix would hint that we want delayed expression
evaluation. The default std::ast::evaluate() would fall back to
regular evaluation, but an overload of std::ast::evaluate() for
those types would allow compile-time rearranging of the ast.<br>
<br>
<br>
<div>On 02/01/2018 11:25 AM, Dejan
Milosavljevic wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example is only one
of (presumably) many such examples. </div>
</div>
</blockquote>
<div>> We've been programming in C++ for decades.=C2=A0 Show=
them.</div>
<div><br>
</div>
<div>Lets do not care about memory in next examples.</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0
std::math::vector<double, 1000> a,b,c,d; //
Mathematical vector or=C2=A0strong type of std::array<double=
,
1000> if preferred.</font></div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D b =
+ c + d; //
There are=C2=A02 consecutive loops behind this expression. </fo=
nt></div>
<div><br>
</div>
<div>Lets extend this=C2=A0proposal in to <b><i>expression
overloading</i></b>:</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 double x=
,y;</font></div>
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 a =3D =
b + x*c + y*d;
// There are=C2=A04 consecutive loops behind this expression.=
</font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"arial,helvetica,sans-serif">Now if=C2=A0in som=
e
point <i><b>expression overloading</b> </i>become
possible above expression=C2=A0we can put on some number
crunching processor e.g. GPU.=C2=A0</font></div>
</div>
<div><font face=3D"Courier New"><font face=3D"arial,helvetica,sans-=
serif">More complex example:</font></font></div>
<div><font face=3D"Courier New"><font face=3D"arial,helvetica,sans-=
serif">=C2=A0=C2=A0=C2=A0 <font face=3D"Courier
New"><font face=3D"monospace,monospace">std::math::matrix&l=
t;
double, 1000 > m, n; // Square matrix.</font></font></=
font></font></div>
<font face=3D"Courier New"><font face=3D"arial,helvetica,sans-serif=
"><font face=3D"Courier New">
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0a =3D b=
+ m*c +
n*d; //=C2=A0Utilizing GPU m*c and n*d can be done in
parallel, and one loop to sum all vectors.<br>
</font></div>
</div>
</font></font></font>
<div><br>
</div>
</div>
<div><br>
<div class=3D"gmail_quote">On Thu, Feb 1, 2018 at 7:56 AM, Nevin
Liber <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">ne...@eviloverlord.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><span>On Wed, Jan 31, 2018 at 9:47 PM, Nicol
Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">jmck...@gmail.com</a>></span>
wrote:<br>
</span>
<div>
<div class=3D"gmail_quote"><span>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr"><br>
<br>
On Wednesday, January 31, 2018 at 9:33:26 PM
UTC-5, Nevin ":-)" Liber wrote:<span>
<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
er-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">On Tue, Jan 30, 2018 at 2:45
PM, Manuel Freiberger <span dir=3D"ltr"><<=
a rel=3D"nofollow">manuel.f...@gmail.com</a>></span>
wrote:<br>
<div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><span>The solution is
to use a variadic function like
Abseil's StrCat() [1], for
example. Since the<br>
function sees all strings at
once, it can sum up their sizes,
allocate the final memory once<br>
and copy one string after
another to the output.<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>And you haven't justified the
downside to this solution,
especially since such a function is
fairly simple to write in C++17:</div>
<div><br>
</div>
<div>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">s=
td::string
StringCat(std::initializer_<wbr>list&=
lt;std::string_view>
il)</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">{=
</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 std::string s;</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 s.reserve(std::accumulate(std:=
<wbr>:begin(il),
std::end(il), size_t{}, [](size_t
sz, std::string_view sv){ <span style=
=3D"color:rgb(186,45,162)">return</span>
sz + sv.size(); }));</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 <span style=3D"color:rgb(186,4=
5,162)">for</span>
(std::string_view sv : il)</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 s +=3D sv;</p>
<p style=3D"margin:0px;line-height:norm=
al;font-family:Helvetica;font-size:12px;min-height:14px;font-stretch:normal=
"><br>
</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 <span style=3D"color:rgb(186,4=
5,162)">return</span>
s;</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">}=
</p>
<p style=3D"margin:0px;line-height:norm=
al;font-family:Helvetica;font-size:12px;min-height:14px;font-stretch:normal=
"><br>
</p>
<p style=3D"margin:0px;color:rgb(186,45=
,162);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:norm=
al">template<span style=3D"color:rgb(0,0,0)"><</span>typename<span style=
=3D"color:rgb(0,0,0)">...
Ts></span></p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">s=
td::string
StringCat(Ts&&... ts)</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">{=
</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">=
=C2=A0
=C2=A0 <span style=3D"color:rgb(186,4=
5,162)">return</span>
StringCat({std::string_view(<wbr>std:=
:forward<Ts>(ts))...});</p>
<p style=3D"margin:0px;color:rgb(0,0,0)=
;line-height:normal;font-family:Menlo;font-size:11px;font-stretch:normal">}=
</p>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><span>Note that<br>
a proper implementation would
constrain the elements of the
parameter pack to be of type<br>
std::string (any maybe derived
classes).<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>Which is a large constraint that
the implementation above doesn't
have.</div>
<div><br>
</div>
<div><br>
</div>
<div>This would be a not insignificant
language change for something that
is ultimately very restrictive
compared with the functional version
we can write today.=C2=A0 Doesn't s=
eem
worth it.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>To be fair, the point of the proposal is to
optimize the code people already write. That
is, nobody writes "StringCat({str1, str2,
str3, ...});`</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I'm not asking anyone to write that; it is just
the helper for the template function.</div>
<div><br>
</div>
<div>They can write:</div>
<div><br>
</div>
<div>
<p style=3D"margin:0px;color:rgb(0,0,0);line-height:nor=
mal;font-family:Menlo;font-size:11px;font-stretch:normal">StringCat(<span s=
tyle=3D"color:rgb(209,47,27)">"One"</span>,
std::string(<span style=3D"color:rgb(209,47,27)">&quo=
t;Two"</span>),
std::string_view(<span style=3D"color:rgb(209,47,27)"=
>"Three"</span>));</p>
</div>
<div><br>
</div>
<div>Which returns the equivalent of a
std::string("OneTwoThree")</div>
<div><br>
</div>
<div>and has the intended efficiency with respect to
possible heap allocations.</div>
<div><br>
</div>
<div><br>
</div>
<div>Given a C string literal, a std::string and a
std::string_view, you cannot get that same heap
efficiency with the proposal.</div>
<div><br>
</div>
<div>Yet strings are inefficiently built that way.=C2=A0
For example, I've seen plenty of code of the form:<=
/div>
<div><br>
</div>
<div>std::string path =3D std::string(dir) + "/"=
; +
basename + ".ext";</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div> They write `str1 + str2 + str3 + ...`.
It's the most obvious way to do it, and it
works; therefore, it should work<i>
efficiently</i>.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Make the above path example work efficiently (no
more potential heap allocations) with his proposal.=C2=
=A0
Good luck.</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example
is only one of (presumably) many such
examples. </div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>We've been programming in C++ for decades.=C2=A0=
Show
them.</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>While string concatenation can reasonably
be done with function calls, the whole point
of operator overloading is that you get to
make your code look more like what it is
clearly doing. For mathematical types,
creating excessive numbers of temporaries as
part of computing some math equation is
unnecessary and wasteful.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Again, please point to actual examples.</div>
<span>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>That's not to say that there cannot be
times when this could help. But it's not
nearly often enough to be useful in most cases
that actually deserve to be using operator
overloading (ie: not `string` operator+).</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Every idea has at least one use case.=C2=A0 The bar
tends to be a bit higher than that for adding
something to the standard.</div>
</div>
<span>-- <br>
<div>
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div>=C2=A0Nevin ":-)" Liber=C2=A0 <=
mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"z=
BvegzjvBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">ne...@eviloverlord.com</a><wbr>>
=C2=A0<a value=3D"+18476911404">+1-847-691-1404=
</a></div>
</div>
</div>
</div>
</div>
</span></div>
</div>
-- <br>
<span>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals&q=
uot;
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">std-proposal...@<wbr>isocpp.org</a>.<br=
>
To post to this group, send email to <a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
</span>
To view this discussion on the web visit <a href=3D"https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN%3Di8R2FA_gC92z=
YSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=3Demail&utm_=
source=3Dfooter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_=
6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_med=
ium\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_=
6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_med=
ium\x3demail\x26utm_source\x3dfooter';return true;">https://groups.goog=
le.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAGg_6%2BN%3Di8R2FA_<wb=
r>gC92zYSOrF5DCiDJLQyCgdoN1Wp0HO<wbr>i93rA%40mail.gmail.com</a>.<br>
</blockquote>
</div>
<br>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3J=
xT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=3Demail&utm_sour=
ce=3Dfooter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxb=
jsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_mediu=
m\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfef=
mxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_me=
dium\x3demail\x26utm_source\x3dfooter';return true;">https://groups.goo=
gle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAEfefmxbjsKR%<wbr>2B2=
Eb3bTuWLdh5h3JxT0HrrS%2Bfe%<wbr>2BJzwp9H04bCQ%40mail.gmail.com</a><wbr>.<br=
>
</blockquote>
<br>
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/24f92a35-b67e-45cd-9493-77fb278a40c7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b67e-45cd-9493-77fb278a40c7=
%40isocpp.org</a>.<br />
------=_Part_4323_1779022731.1517819512089--
------=_Part_4322_1080925614.1517819512089--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 5 Feb 2018 14:13:54 +0200
Raw View
This is a multi-part message in MIME format.
--------------E1068885A94E23E3E7D52C6D
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 02/05/2018 10:31 AM, florian.csdt@gmail.com wrote:
> Then, what is the difference with usual expression templates?
The compiler generates them.
> Your "AST" looks really similar to Boost::Proto.
> And it has the same main issue than Boost Proto (or any expression=20
> template solution): You need to instantiate a hell lot of types.
>
> The only difference with a compiler support and usual expression=20
> templates is "auto" type deduction.
> And *this* is the issue to solve.
> BTW, already several proposals aim to solve this very problem of the=20
> auto type deduction (don't remember which).
>
> I don't think it would be a good idea to standardize Boost::Proto=20
> though. But expression templates are relatively easy to implement for=20
> our own custom types.
>
> Florian
>
> Le dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9crit=
=C2=A0:
>
> It would be nice if we can get the compiler to switch to providing
> an AST. The example
>
>
> =C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n; // Square =
matrix.
> =C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can b=
e done in
> parallel, and one loop to sum all vectors.
>
> might compile to
>
> =C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::assign(a, std::ast::s=
um(b,
> std::ast::product(m ,c), std::ast::product(n, d)))
>
> std::math::matrix would hint that we want delayed expression
> evaluation. The default std::ast::evaluate() would fall back to
> regular evaluation, but an overload of std::ast::evaluate() for
> those types would allow compile-time rearranging of the ast.
>
>
> On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:
>>
>> The other thing is that the string example is only one of
>> (presumably) many such examples.
>>
>> > We've been programming in C++ for decades. Show them.
>>
>> Lets do not care about memory in next examples.
>> std::math::vector<double, 1000> a,b,c,d; // Mathematical vector
>> or=C2=A0strong type of std::array<double, 1000> if preferred.
>> =C2=A0=C2=A0=C2=A0 a =3D b + c + d; // There are=C2=A02 consecutive =
loops behind this
>> expression.
>>
>> Lets extend this=C2=A0proposal in to */expression overloading/*:
>> =C2=A0=C2=A0=C2=A0 double x,y;
>> =C2=A0=C2=A0=C2=A0 a =3D b + x*c + y*d; // There are=C2=A04 consecut=
ive loops behind
>> this expression.
>>
>> Now if=C2=A0in some point /*expression overloading* /become possible
>> above expression=C2=A0we can put on some number crunching processor
>> e.g. GPU.
>> More complex example:
>> std::math::matrix< double, 1000 > m, n; // Square matrix.
>> =C2=A0=C2=A0a =3D b + m*c + n*d; //=C2=A0Utilizing GPU m*c and n*d c=
an be done in
>> parallel, and one loop to sum all vectors.
>>
>>
>> On Thu, Feb 1, 2018 at 7:56 AM, Nevin Liber
>> <ne...@eviloverlord.com <javascript:>> wrote:
>>
>> On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas
>> <jmck...@gmail.com <javascript:>> wrote:
>>
>>
>>
>> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin
>> ":-)" Liber wrote:
>>
>> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger
>> <manuel.f...@gmail.com> wrote:
>>
>> The solution is to use a variadic function like
>> Abseil's StrCat() [1], for example. Since the
>> function sees all strings at once, it can sum up
>> their sizes, allocate the final memory once
>> and copy one string after another to the output.
>>
>>
>> And you haven't justified the downside to this
>> solution, especially since such a function is fairly
>> simple to write in C++17:
>>
>> std::string
>> StringCat(std::initializer_list<std::string_view> il)
>>
>> {
>>
>> =C2=A0 std::string s;
>>
>> s.reserve(std::accumulate(std::begin(il),
>> std::end(il), size_t{}, [](size_t sz,
>> std::string_view sv){ return sz + sv.size(); }));
>>
>> for (std::string_view sv : il)
>>
>> =C2=A0 =C2=A0 =C2=A0 s +=3D sv;
>>
>>
>> return s;
>>
>> }
>>
>>
>> template<typename... Ts>
>>
>> std::string StringCat(Ts&&... ts)
>>
>> {
>>
>> return
>> StringCat({std::string_view(std::forward<Ts>(ts))...});
>>
>> }
>>
>>
>> Note that
>> a proper implementation would constrain the
>> elements of the parameter pack to be of type
>> std::string (any maybe derived classes).
>>
>>
>> Which is a large constraint that the implementation
>> above doesn't have.
>>
>>
>> This would be a not insignificant language change for
>> something that is ultimately very restrictive
>> compared with the functional version we can write
>> today. Doesn't seem worth it.
>>
>>
>> To be fair, the point of the proposal is to optimize the
>> code people already write. That is, nobody writes
>> "StringCat({str1, str2, str3, ...});`
>>
>>
>> I'm not asking anyone to write that; it is just the helper
>> for the template function.
>>
>> They can write:
>>
>> StringCat("One", std::string("Two"), std::string_view("Three"));
>>
>>
>> Which returns the equivalent of a std::string("OneTwoThree")
>>
>> and has the intended efficiency with respect to possible heap
>> allocations.
>>
>>
>> Given a C string literal, a std::string and a
>> std::string_view, you cannot get that same heap efficiency
>> with the proposal.
>>
>> Yet strings are inefficiently built that way.=C2=A0 For example,
>> I've seen plenty of code of the form:
>>
>> std::string path =3D std::string(dir) + "/" + basename + ".ext";
>>
>> They write `str1 + str2 + str3 + ...`. It's the most
>> obvious way to do it, and it works; therefore, it should
>> work/efficiently/.
>>
>>
>> Make the above path example work efficiently (no more
>> potential heap allocations) with his proposal.=C2=A0 Good luck.
>>
>>
>> The other thing is that the string example is only one of
>> (presumably) many such examples.
>>
>>
>> We've been programming in C++ for decades.=C2=A0 Show them.
>>
>> While string concatenation can reasonably be done with
>> function calls, the whole point of operator overloading
>> is that you get to make your code look more like what it
>> is clearly doing. For mathematical types, creating
>> excessive numbers of temporaries as part of computing
>> some math equation is unnecessary and wasteful.
>>
>>
>> Again, please point to actual examples.
>>
>> That's not to say that there cannot be times when this
>> could help. But it's not nearly often enough to be useful
>> in most cases that actually deserve to be using operator
>> overloading (ie: not `string` operator+).
>>
>>
>> Every idea has at least one use case. The bar tends to be a
>> bit higher than that for adding something to the standard.
>> --=20
>> =C2=A0Nevin ":-)" Liber=C2=A0 <mailto:ne...@eviloverlord.com
>> <javascript:>> +1-847-691-1404
>> --=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 email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAG=
g_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA=
Gg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_=
medium=3Demail&utm_source=3Dfooter>.
>>
>>
>> --=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 email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefm=
xbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfef=
mxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_me=
dium=3Demail&utm_source=3Dfooter>.
>
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b67=
e-45cd-9493-77fb278a40c7%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b6=
7e-45cd-9493-77fb278a40c7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>.
--=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/cc43892d-26a5-cfc4-613a-f0cfdca6310d%40scylladb.=
com.
--------------E1068885A94E23E3E7D52C6D
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 02/05/2018 10:31 AM,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:florian.csdt@gma=
il.com">florian.csdt@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:24f92a35-b67e-45cd-9493-77fb278a40c7@isocpp.org">
<div dir=3D"ltr">Then, what is the difference with usual expression
templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:24f92a35-b67e-45cd-9493-77fb278a40c7@isocpp.org">
<div dir=3D"ltr">Your "AST" looks really similar to Boost::Proto.<br>
And it has the same main issue than Boost Proto (or any
expression template solution): You need to instantiate a hell
lot of types.<br>
<br>
The only difference with a compiler support and usual expression
templates is "auto" type deduction.<br>
And <b>this</b> is the issue to solve.<br>
BTW, already several proposals aim to solve this very problem of
the auto type deduction (don't remember which).<br>
<br>
I don't think it would be a good idea to standardize
Boost::Proto though. But expression templates are relatively
easy to implement for our own custom types.<br>
<br>
Florian<br>
<br>
Le dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9=
crit=C2=A0:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>It would be nice if we can get the compiler to switch to
providing an AST. The example<br>
</p>
<br>
=C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n=
; // Square
matrix.<br>
=C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d=
can be
done in parallel, and one loop to sum all vectors.<br>
<br>
might compile to<br>
<br>
=C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::<wbr>assign(a,
std::ast::sum(b, std::ast::product(m ,c),
std::ast::product(n, d)))<br>
<br>
std::math::matrix would hint that we want delayed expression
evaluation. The default std::ast::evaluate() would fall back
to regular evaluation, but an overload of
std::ast::evaluate() for those types would allow
compile-time rearranging of the ast.<br>
<br>
<br>
<div>On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example is
only one of (presumably) many such examples. </div>
</div>
</blockquote>
<div>> We've been programming in C++ for decades.=C2=A0
Show them.</div>
<div><br>
</div>
<div>Lets do not care about memory in next examples.</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0
std::math::vector<double, 1000> a,b,c,d; //
Mathematical vector or=C2=A0strong type of
std::array<double, 1000> if preferred.</font></di=
v>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 =
a =3D b + c + d;
// There are=C2=A02 consecutive loops behind this
expression. </font></div>
<div><br>
</div>
<div>Lets extend this=C2=A0proposal in to <b><i>expression
overloading</i></b>:</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 =
double x,y;</font></div>
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=
=A0 a =3D b + x*c
+ y*d; // There are=C2=A04 consecutive loops behind
this expression. </font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"arial,helvetica,sans-serif">Now if=C2=
=A0in
some point <i><b>expression overloading</b> </i>becom=
e
possible above expression=C2=A0we can put on some
number crunching processor e.g. GPU.=C2=A0</font></di=
v>
</div>
<div><font face=3D"Courier New"><font
face=3D"arial,helvetica,sans-serif">More complex
example:</font></font></div>
<div><font face=3D"Courier New"><font
face=3D"arial,helvetica,sans-serif">=C2=A0=C2=A0=C2=
=A0 <font
face=3D"Courier New"><font
face=3D"monospace,monospace">std::math::matrix<=
;
double, 1000 > m, n; // Square matrix.</font><=
/font></font></font></div>
<font face=3D"Courier New"><font
face=3D"arial,helvetica,sans-serif"><font
face=3D"Courier New">
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=
=A0a =3D b +
m*c + n*d; //=C2=A0Utilizing GPU m*c and n*d ca=
n
be done in parallel, and one loop to sum all
vectors.<br>
</font></div>
</div>
</font></font></font>
<div><br>
</div>
</div>
<div><br>
<div class=3D"gmail_quote">On Thu, Feb 1, 2018 at 7:56 AM,
Nevin Liber <span dir=3D"ltr"><<a href=3D"javascript:"
target=3D"_blank"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return true;=
"
onclick=3D"this.href=3D'javascript:';return true;"
moz-do-not-send=3D"true">ne...@eviloverlord.com</a>&g=
t;</span>
wrote:<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"><span>On Wed, Jan 31, 2018 at 9:47
PM, Nicol Bolas <span dir=3D"ltr"><<a
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;"
onclick=3D"this.href=3D'javascript:';return
true;" moz-do-not-send=3D"true">jmck...@gmail.c=
om</a>></span>
wrote:<br>
</span>
<div>
<div class=3D"gmail_quote"><span>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><br>
<br>
On Wednesday, January 31, 2018 at
9:33:26 PM UTC-5, Nevin ":-)" Liber
wrote:<span>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">On Tue, Jan 30, 2018
at 2:45 PM, Manuel Freiberger <span
dir=3D"ltr"><<a rel=3D"nofollow"
moz-do-not-send=3D"true">manuel.f=
....@gmail.com</a>></span>
wrote:<br>
<div>
<div class=3D"gmail_quote">
<blockquote
class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><span>The
solution is to use a
variadic function like
Abseil's StrCat() [1],
for example. Since the<br>
function sees all
strings at once, it can
sum up their sizes,
allocate the final
memory once<br>
and copy one string
after another to the
output.<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>And you haven't justified
the downside to this
solution, especially since
such a function is fairly
simple to write in C++17:</div>
<div><br>
</div>
<div>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">std::string
StringCat(std::initializer_<wbr>list<std::string_view> il)</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">{</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 std::string s;</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0
s.reserve(std::accumulate(std=
:<wbr>:begin(il),
std::end(il), size_t{},
[](size_t sz,
std::string_view sv){ <span
style=3D"color:rgb(186,45,162)">return</span> sz + sv.size(); }));</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,1=
62)">for</span>
(std::string_view sv : il)</p=
>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 =C2=A0 =C2=A0 s +=3D s=
v;</p>
<p
style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:12px=
;min-height:14px;font-stretch:normal"><br>
</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,1=
62)">return</span>
s;</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">}</p>
<p
style=3D"margin:0px;line-height:normal;font-family:Helvetica;font-size:12px=
;min-height:14px;font-stretch:normal"><br>
</p>
<p
style=3D"margin:0px;color:rgb(186,45,162);line-height:normal;font-family:Me=
nlo;font-size:11px;font-stretch:normal">template<span
style=3D"color:rgb(0,0,0)">=
<</span>typename<span
style=3D"color:rgb(0,0,0)">=
....
Ts></span></p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">std::string
StringCat(Ts&&...
ts)</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">{</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">=C2=A0
=C2=A0 <span
style=3D"color:rgb(186,45,1=
62)">return</span>
StringCat({std::string_view(<wbr>std::forward<Ts>(ts))...});</p>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">}</p>
</div>
<div><br>
</div>
<blockquote
class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr"><span>Note
that<br>
a proper implementation
would constrain the
elements of the
parameter pack to be of
type<br>
std::string (any maybe
derived classes).<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>Which is a large
constraint that the
implementation above doesn't
have.</div>
<div><br>
</div>
<div><br>
</div>
<div>This would be a not
insignificant language
change for something that is
ultimately very restrictive
compared with the functional
version we can write today.=C2=
=A0
Doesn't seem worth it.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>To be fair, the point of the
proposal is to optimize the code
people already write. That is, nobody
writes "StringCat({str1, str2, str3,
...});`</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I'm not asking anyone to write that; it
is just the helper for the template
function.</div>
<div><br>
</div>
<div>They can write:</div>
<div><br>
</div>
<div>
<p
style=3D"margin:0px;color:rgb(0,0,0);line-height:normal;font-family:Menlo;f=
ont-size:11px;font-stretch:normal">StringCat(<span
style=3D"color:rgb(209,47,27)">"One"</span>=
,
std::string(<span
style=3D"color:rgb(209,47,27)">"Two"</span>=
),
std::string_view(<span
style=3D"color:rgb(209,47,27)">"Three"</spa=
n>));</p>
</div>
<div><br>
</div>
<div>Which returns the equivalent of a
std::string("OneTwoThree")</div>
<div><br>
</div>
<div>and has the intended efficiency with
respect to possible heap allocations.</div>
<div><br>
</div>
<div><br>
</div>
<div>Given a C string literal, a std::string
and a std::string_view, you cannot get that
same heap efficiency with the proposal.</div>
<div><br>
</div>
<div>Yet strings are inefficiently built that
way.=C2=A0 For example, I've seen plenty of cod=
e
of the form:</div>
<div><br>
</div>
<div>std::string path =3D std::string(dir) + "/"
+ basename + ".ext";</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div> They write `str1 + str2 + str3 +
...`. It's the most obvious way to do
it, and it works; therefore, it should
work<i> efficiently</i>.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Make the above path example work
efficiently (no more potential heap
allocations) with his proposal.=C2=A0 Good luck=
..</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string
example is only one of (presumably)
many such examples. </div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>We've been programming in C++ for
decades.=C2=A0 Show them.</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>While string concatenation can
reasonably be done with function
calls, the whole point of operator
overloading is that you get to make
your code look more like what it is
clearly doing. For mathematical types,
creating excessive numbers of
temporaries as part of computing some
math equation is unnecessary and
wasteful.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Again, please point to actual examples.</div=
>
<span>
<div><br>
</div>
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>That's not to say that there cannot
be times when this could help. But
it's not nearly often enough to be
useful in most cases that actually
deserve to be using operator
overloading (ie: not `string`
operator+).</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Every idea has at least one use case.=C2=A0
The bar tends to be a bit higher than that
for adding something to the standard.</div>
</div>
<span>-- <br>
<div>
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div>=C2=A0Nevin ":-)" Liber=C2=A0 <ma=
ilto:<a
href=3D"javascript:" target=3D"_blank=
"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascrip=
t:';return
true;"
onclick=3D"this.href=3D'javascript:';=
return
true;" moz-do-not-send=3D"true">ne...=
@eviloverlord.com</a><wbr>>
=C2=A0<a value=3D"+18476911404"
moz-do-not-send=3D"true">+1-847-691-1=
404</a></div>
</div>
</div>
</div>
</div>
</span></div>
</div>
-- <br>
<span> You received this message because you are
subscribed to the Google Groups "ISO C++ Standard
- Future Proposals" group.<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;" onclick=3D"this.href=3D'javascript:';return
true;" moz-do-not-send=3D"true">std-proposal...@<wb=
r>isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;" onclick=3D"this.href=3D'javascript:';return
true;" moz-do-not-send=3D"true">std-pr...@isocpp.or=
g</a>.<br>
</span> To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6=
%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mai=
l.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return
true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gm=
ail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return
true;" moz-do-not-send=3D"true">https://groups.google=
..com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAGg_6%2BN%3Di8R2FA_<wbr>=
gC92zYSOrF5DCiDJLQyCgdoN1Wp0HO<wbr>i93rA%40mail.gmail.com</a>.<br>
</blockquote>
</div>
<br>
</div>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"javascript:"
target=3D"_blank" gdf-obfuscated-mailto=3D"zBvegzjvBgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;"
moz-do-not-send=3D"true">std-proposal...@<wbr>isocpp.org</a=
>.<br>
To post to this group, send email to <a
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"zBvegzjvBgAJ" rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;"
moz-do-not-send=3D"true">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfef=
mxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_me=
dium=3Demail&utm_source=3Dfooter"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40m=
ail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return
true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.=
gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return
true;" moz-do-not-send=3D"true">https://groups.google.com/a=
/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAEfefmxbjsKR%<wbr>2B2Eb3bTuWLd=
h5h3JxT0HrrS%2Bfe%<wbr>2BJzwp9H04bCQ%40mail.gmail.com</a><wbr>.<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24f92a=
35-b67e-45cd-9493-77fb278a40c7%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/24f92a35-b67e-45cd-9493-77fb278a40c7%40isocpp.org</a>.<b=
r>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cc43892d-26a5-cfc4-613a-f0cfdca6310d%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/cc43892d-26a5-cfc4-613a-f0cfdca631=
0d%40scylladb.com</a>.<br />
--------------E1068885A94E23E3E7D52C6D--
.
Author: florian.csdt@gmail.com
Date: Mon, 5 Feb 2018 04:24:04 -0800 (PST)
Raw View
------=_Part_3626_674206928.1517833445064
Content-Type: multipart/alternative;
boundary="----=_Part_3627_794145824.1517833445066"
------=_Part_3627_794145824.1517833445066
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9crit :
>
>
>
> On 02/05/2018 10:31 AM, floria...@gmail.com <javascript:> wrote:
>
> Then, what is the difference with usual expression templates?
>
>
> The compiler generates them.
>
So? What is the difference for the end user?
If you want the compiler to generate this AST, you should change the=20
language itself, while a library solution is already available and working.
So it better provides a huge improvement over the library solution.
As I said, the only *real* difference would/could be the auto type=20
deduction. And other proposals already try to address this issue, while=20
being much more lightweight compared to what you propose.
=20
>
> Your "AST" looks really similar to Boost::Proto.
> And it has the same main issue than Boost Proto (or any expression=20
> template solution): You need to instantiate a hell lot of types.
>
> The only difference with a compiler support and usual expression template=
s=20
> is "auto" type deduction.
> And *this* is the issue to solve.
> BTW, already several proposals aim to solve this very problem of the auto=
=20
> type deduction (don't remember which).
>
> I don't think it would be a good idea to standardize Boost::Proto though.=
=20
> But expression templates are relatively easy to implement for our own=20
> custom types.
>
> Florian
>
> Le dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9crit :=
=20
>>
>> It would be nice if we can get the compiler to switch to providing an=20
>> AST. The example
>>
>> std::math::matrix< double, 1000 > m, n; // Square matrix.
>> a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be done in=20
>> parallel, and one loop to sum all vectors.
>>
>> might compile to
>>
>> std::ast::evaluate(std::ast::assign(a, std::ast::sum(b,=20
>> std::ast::product(m ,c), std::ast::product(n, d)))
>>
>> std::math::matrix would hint that we want delayed expression evaluation.=
=20
>> The default std::ast::evaluate() would fall back to regular evaluation, =
but=20
>> an overload of std::ast::evaluate() for those types would allow=20
>> compile-time rearranging of the ast.
>>
>>
>> On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:
>>
>> The other thing is that the string example is only one of (presumably)=
=20
>>> many such examples.=20
>>>
>> > We've been programming in C++ for decades. Show them.
>>
>> Lets do not care about memory in next examples.
>> std::math::vector<double, 1000> a,b,c,d; // Mathematical vector=20
>> or strong type of std::array<double, 1000> if preferred.
>> a =3D b + c + d; // There are 2 consecutive loops behind this=20
>> expression.=20
>>
>> Lets extend this proposal in to *expression overloading*:
>> double x,y;
>> a =3D b + x*c + y*d; // There are 4 consecutive loops behind this=20
>> expression.=20
>>
>> Now if in some point *expression overloading *become possible above=20
>> expression we can put on some number crunching processor e.g. GPU.=20
>> More complex example:
>> std::math::matrix< double, 1000 > m, n; // Square matrix.
>> a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d can be done in=20
>> parallel, and one loop to sum all vectors.
>>
>>
>> On Thu, Feb 1, 2018 at 7:56 AM, Nevin Liber <ne...@eviloverlord.com>=20
>> wrote:
>>
>>> On Wed, Jan 31, 2018 at 9:47 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, January 31, 2018 at 9:33:26 PM UTC-5, Nevin ":-)" Liber=
=20
>>>> wrote:=20
>>>>>
>>>>> On Tue, Jan 30, 2018 at 2:45 PM, Manuel Freiberger <
>>>>> manuel.f...@gmail.com> wrote:
>>>>>
>>>>>> The solution is to use a variadic function like Abseil's StrCat()=20
>>>>>> [1], for example. Since the
>>>>>> function sees all strings at once, it can sum up their sizes,=20
>>>>>> allocate the final memory once
>>>>>> and copy one string after another to the output.
>>>>>>
>>>>>
>>>>> And you haven't justified the downside to this solution, especially=
=20
>>>>> since such a function is fairly simple to write in C++17:
>>>>>
>>>>> std::string StringCat(std::initializer_list<std::string_view> il)
>>>>>
>>>>> {
>>>>>
>>>>> std::string s;
>>>>>
>>>>> s.reserve(std::accumulate(std::begin(il), std::end(il), size_t{},=
=20
>>>>> [](size_t sz, std::string_view sv){ return sz + sv.size(); }));
>>>>>
>>>>> for (std::string_view sv : il)
>>>>>
>>>>> s +=3D sv;
>>>>>
>>>>>
>>>>> return s;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> template<typename... Ts>
>>>>>
>>>>> std::string StringCat(Ts&&... ts)
>>>>>
>>>>> {
>>>>>
>>>>> return StringCat({std::string_view(std::forward<Ts>(ts))...});
>>>>>
>>>>> }
>>>>>
>>>>> Note that
>>>>>> a proper implementation would constrain the elements of the paramete=
r=20
>>>>>> pack to be of type
>>>>>> std::string (any maybe derived classes).
>>>>>>
>>>>>
>>>>> Which is a large constraint that the implementation above doesn't hav=
e.
>>>>>
>>>>>
>>>>> This would be a not insignificant language change for something that=
=20
>>>>> is ultimately very restrictive compared with the functional version w=
e can=20
>>>>> write today. Doesn't seem worth it.
>>>>>
>>>>
>>>> To be fair, the point of the proposal is to optimize the code people=
=20
>>>> already write. That is, nobody writes "StringCat({str1, str2, str3, ..=
..});`
>>>>
>>>
>>> I'm not asking anyone to write that; it is just the helper for the=20
>>> template function.
>>>
>>> They can write:
>>>
>>> StringCat("One", std::string("Two"), std::string_view("Three"));
>>>
>>> Which returns the equivalent of a std::string("OneTwoThree")
>>>
>>> and has the intended efficiency with respect to possible heap=20
>>> allocations.
>>>
>>>
>>> Given a C string literal, a std::string and a std::string_view, you=20
>>> cannot get that same heap efficiency with the proposal.
>>>
>>> Yet strings are inefficiently built that way. For example, I've seen=
=20
>>> plenty of code of the form:
>>>
>>> std::string path =3D std::string(dir) + "/" + basename + ".ext";
>>> =20
>>>
>>>> They write `str1 + str2 + str3 + ...`. It's the most obvious way to do=
=20
>>>> it, and it works; therefore, it should work* efficiently*.
>>>>
>>>
>>> Make the above path example work efficiently (no more potential heap=20
>>> allocations) with his proposal. Good luck.
>>>
>>>
>>> The other thing is that the string example is only one of (presumably)=
=20
>>>> many such examples.=20
>>>>
>>>
>>> We've been programming in C++ for decades. Show them.
>>> =20
>>>
>>>> While string concatenation can reasonably be done with function calls,=
=20
>>>> the whole point of operator overloading is that you get to make your c=
ode=20
>>>> look more like what it is clearly doing. For mathematical types, creat=
ing=20
>>>> excessive numbers of temporaries as part of computing some math equati=
on is=20
>>>> unnecessary and wasteful.
>>>>
>>>
>>> Again, please point to actual examples.
>>>
>>> That's not to say that there cannot be times when this could help. But=
=20
>>>> it's not nearly often enough to be useful in most cases that actually=
=20
>>>> deserve to be using operator overloading (ie: not `string` operator+).
>>>>
>>>
>>> Every idea has at least one use case. The bar tends to be a bit higher=
=20
>>> than that for adding something to the standard.
>>> --=20
>>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> +1-847-691-1404
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN=
%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
N%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>> .
>>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjs=
KR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbj=
sKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>>
>> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b67=
e-45cd-9493-77fb278a40c7%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b6=
7e-45cd-9493-77fb278a40c7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
>
--=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/7adbbe85-72f1-4bdb-945c-3dc3f1a161b4%40isocpp.or=
g.
------=_Part_3627_794145824.1517833445066
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi K=
ivity a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 02/05/2018 10:31 AM,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"QX=
WdD0pCBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>floria...@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Then, what is the difference with usual expression
templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br></div></blockquote><div><br></div><div>=
So? What is the difference for the end user?</div><div>If you want the comp=
iler to generate this AST, you should change the language itself, while a l=
ibrary solution is already available and working.</div><div>So it better pr=
ovides a huge improvement over the library solution.<br></div><div><br></di=
v><div>As I said, the only <i>real</i> difference would/could be the auto t=
ype deduction. And other proposals already try to address this issue, while=
being much more lightweight compared to what you propose.<br></div><div><b=
r></div><div>=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 =
text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">Your "AST" looks really similar to Boost::=
Proto.<br>
And it has the same main issue than Boost Proto (or any
expression template solution): You need to instantiate a hell
lot of types.<br>
<br>
The only difference with a compiler support and usual expression
templates is "auto" type deduction.<br>
And <b>this</b> is the issue to solve.<br>
BTW, already several proposals aim to solve this very problem of
the auto type deduction (don't remember which).<br>
<br>
I don't think it would be a good idea to standardize
Boost::Proto though. But expression templates are relatively
easy to implement for our own custom types.<br>
<br>
Florian<br>
<br>
Le dimanche 4 f=C3=A9vrier 2018 11:51:45 UTC+1, Avi Kivity a =C3=A9=
crit=C2=A0:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>It would be nice if we can get the compiler to switch to
providing an AST. The example<br>
</p>
<br>
=C2=A0=C2=A0=C2=A0 std::math::matrix< double, 1000 > m, n=
; // Square
matrix.<br>
=C2=A0 =C2=A0 a =3D b + m*c + n*d; // Utilizing GPU m*c and n*d=
can be
done in parallel, and one loop to sum all vectors.<br>
<br>
might compile to<br>
<br>
=C2=A0=C2=A0=C2=A0 std::ast::evaluate(std::ast::<wbr>assign(a,
std::ast::sum(b, std::ast::product(m ,c),
std::ast::product(n, d)))<br>
<br>
std::math::matrix would hint that we want delayed expression
evaluation. The default std::ast::evaluate() would fall back
to regular evaluation, but an overload of
std::ast::evaluate() for those types would allow
compile-time rearranging of the ast.<br>
<br>
<br>
<div>On 02/01/2018 11:25 AM, Dejan Milosavljevic wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string example is
only one of (presumably) many such examples. </div>
</div>
</blockquote>
<div>> We've been programming in C++ for decades.=C2=
=A0
Show them.</div>
<div><br>
</div>
<div>Lets do not care about memory in next examples.</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0
std::math::vector<double, 1000> a,b,c,d; //
Mathematical vector or=C2=A0strong type of
std::array<double, 1000> if preferred.</font></di=
v>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 =
a =3D b + c + d;
// There are=C2=A02 consecutive loops behind this
expression. </font></div>
<div><br>
</div>
<div>Lets extend this=C2=A0proposal in to <b><i>expression
overloading</i></b>:</div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=A0 =
double x,y;</font></div>
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=A0=C2=
=A0 a =3D b + x*c
+ y*d; // There are=C2=A04 consecutive loops behind
this expression. </font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"arial,helvetica,sans-serif">Now if=C2=
=A0in
some point <i><b>expression overloading</b> </i>becom=
e
possible above expression=C2=A0we can put on some
number crunching processor e.g. GPU.=C2=A0</font></di=
v>
</div>
<div><font face=3D"Courier New"><font face=3D"arial,helveti=
ca,sans-serif">More complex
example:</font></font></div>
<div><font face=3D"Courier New"><font face=3D"arial,helveti=
ca,sans-serif">=C2=A0=C2=A0=C2=A0 <font face=3D"Courier New"><font face=3D"=
monospace,monospace">std::math::matrix<
double, 1000 > m, n; // Square matrix.</font><=
/font></font></font></div>
<font face=3D"Courier New"><font face=3D"arial,helvetica,sa=
ns-serif"><font face=3D"Courier New">
<div>
<div><font face=3D"monospace,monospace">=C2=A0=C2=
=A0a =3D b +
m*c + n*d; //=C2=A0Utilizing GPU m*c and n*d ca=
n
be done in parallel, and one loop to sum all
vectors.<br>
</font></div>
</div>
</font></font></font>
<div><br>
</div>
</div>
<div><br>
<div class=3D"gmail_quote">On Thu, Feb 1, 2018 at 7:56 AM,
Nevin Liber <span dir=3D"ltr"><<a rel=3D"nofollow">ne.=
...@eviloverlord.com</a>></span>
wrote:<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"><span>On Wed, Jan 31, 2018 at 9:47
PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nof=
ollow">jmck...@gmail.com</a>></span>
wrote:<br>
</span>
<div>
<div class=3D"gmail_quote"><span>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><br>
<br>
On Wednesday, January 31, 2018 at
9:33:26 PM UTC-5, Nevin ":-)" Lib=
er
wrote:<span>
<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">On Tue, Jan 30, 2018
at 2:45 PM, Manuel Freiberger <span d=
ir=3D"ltr"><<a rel=3D"nofollow">manuel.f...@gmail.com</a>></span>
wrote:<br>
<div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><span>The
solution is to use a
variadic function like
Abseil's StrCat() [1],
for example. Since the<br>
function sees all
strings at once, it can
sum up their sizes,
allocate the final
memory once<br>
and copy one string
after another to the
output.<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>And you haven't justifie=
d
the downside to this
solution, especially since
such a function is fairly
simple to write in C++17:</div>
<div><br>
</div>
<div>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">std::string
StringCat(std::initializer_<wbr>list<std::string_view> il)</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">{</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0 std::string s;</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0
s.reserve(std::accumulate(std=
:<wbr>:begin(il),
std::end(il), size_t{},
[](size_t sz,
std::string_view sv){ <span s=
tyle=3D"color:rgb(186,45,162)">return</span> sz + sv.size(); }));</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0 <span style=3D"color:r=
gb(186,45,162)">for</span>
(std::string_view sv : il)</p=
>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0 =C2=A0 =C2=A0 s +=3D s=
v;</p>
<p style=3D"margin:0px;line-hei=
ght:normal;font-family:Helvetica;font-size:12px;min-height:14px;font-stretc=
h:normal"><br>
</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0 <span style=3D"color:r=
gb(186,45,162)">return</span>
s;</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">}</p>
<p style=3D"margin:0px;line-hei=
ght:normal;font-family:Helvetica;font-size:12px;min-height:14px;font-stretc=
h:normal"><br>
</p>
<p style=3D"margin:0px;color:rg=
b(186,45,162);line-height:normal;font-family:Menlo;font-size:11px;font-stre=
tch:normal">template<span style=3D"color:rgb(0,0,0)"><</span>typename<sp=
an style=3D"color:rgb(0,0,0)">...
Ts></span></p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">std::string
StringCat(Ts&&...
ts)</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">{</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">=C2=A0
=C2=A0 <span style=3D"color:r=
gb(186,45,162)">return</span>
StringCat({std::string_view(<wbr>std::forward<Ts>(ts))...});</p>
<p style=3D"margin:0px;color:rg=
b(0,0,0);line-height:normal;font-family:Menlo;font-size:11px;font-stretch:n=
ormal">}</p>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><span>Note
that<br>
a proper implementation
would constrain the
elements of the
parameter pack to be of
type<br>
std::string (any maybe
derived classes).<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>Which is a large
constraint that the
implementation above doesn'=
t
have.</div>
<div><br>
</div>
<div><br>
</div>
<div>This would be a not
insignificant language
change for something that is
ultimately very restrictive
compared with the functional
version we can write today.=C2=
=A0
Doesn't seem worth it.</div=
>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>To be fair, the point of the
proposal is to optimize the code
people already write. That is, nobody
writes "StringCat({str1, str2, str3,
...});`</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I'm not asking anyone to write that; it
is just the helper for the template
function.</div>
<div><br>
</div>
<div>They can write:</div>
<div><br>
</div>
<div>
<p style=3D"margin:0px;color:rgb(0,0,0);line-he=
ight:normal;font-family:Menlo;font-size:11px;font-stretch:normal">StringCat=
(<span style=3D"color:rgb(209,47,27)">"One"</span>,
std::string(<span style=3D"color:rgb(209,47,2=
7)">"Two"</span>),
std::string_view(<span style=3D"color:rgb(209=
,47,27)">"Three"</span>));</p>
</div>
<div><br>
</div>
<div>Which returns the equivalent of a
std::string("OneTwoThree")</div>
<div><br>
</div>
<div>and has the intended efficiency with
respect to possible heap allocations.</div>
<div><br>
</div>
<div><br>
</div>
<div>Given a C string literal, a std::string
and a std::string_view, you cannot get that
same heap efficiency with the proposal.</div>
<div><br>
</div>
<div>Yet strings are inefficiently built that
way.=C2=A0 For example, I've seen plenty of=
code
of the form:</div>
<div><br>
</div>
<div>std::string path =3D std::string(dir) + &quo=
t;/"
+ basename + ".ext";</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div> They write `str1 + str2 + str3 +
...`. It's the most obvious way to do
it, and it works; therefore, it should
work<i> efficiently</i>.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Make the above path example work
efficiently (no more potential heap
allocations) with his proposal.=C2=A0 Good luck=
..</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>The other thing is that the string
example is only one of (presumably)
many such examples. </div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>We've been programming in C++ for
decades.=C2=A0 Show them.</div>
<span>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>While string concatenation can
reasonably be done with function
calls, the whole point of operator
overloading is that you get to make
your code look more like what it is
clearly doing. For mathematical types,
creating excessive numbers of
temporaries as part of computing some
math equation is unnecessary and
wasteful.</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Again, please point to actual examples.</div=
>
<span>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">
<div>That's not to say that there canno=
t
be times when this could help. But
it's not nearly often enough to be
useful in most cases that actually
deserve to be using operator
overloading (ie: not `string`
operator+).</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Every idea has at least one use case.=C2=A0
The bar tends to be a bit higher than that
for adding something to the standard.</div>
</div>
<span>-- <br>
<div>
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a rel=3D"nofollow">ne...@eviloverlord.com</a><wbr>>
=C2=A0<a value=3D"+18476911404">+1-847-=
691-1404</a></div>
</div>
</div>
</div>
</div>
</span></div>
</div>
-- <br>
<span> You received this message because you are
subscribed to the Google Groups "ISO C++ Standar=
d
- Future Proposals" group.<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a rel=3D"nofollow">=
std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofoll=
ow">std-pr...@isocpp.org</a>.<br>
</span> To view this discussion on the web visit <a hre=
f=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
N%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.=
gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/CAGg_6%2BN%3Di8R2FA_gC92zYSOrF5DCiDJLQyCgdoN1Wp0HOi93rA%40mail.=
gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;">ht=
tps://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAGg_6=
%2BN%3Di8R2FA_<wbr>gC92zYSOrF5DCiDJLQyCgdoN1Wp0HO<wbr>i93rA%40mail.gmail.co=
m</a>.<br>
</blockquote>
</div>
<br>
</div>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals&q=
uot;
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a rel=3D"nofollow">std-proposal...=
@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-=
pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxbjsKR%2B2Eb3bTu=
WLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?utm_medium=3Demail&=
utm_source=3Dfooter" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this=
..href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/C=
AEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com?u=
tm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"th=
is.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/CAEfefmxbjsKR%2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%2BJzwp9H04bCQ%40mail.gmail.com=
?utm_medium\x3demail\x26utm_source\x3dfooter';return true;">https://gro=
ups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAEfefmxbjsKR%<=
wbr>2B2Eb3bTuWLdh5h3JxT0HrrS%2Bfe%<wbr>2BJzwp9H04bCQ%40mail.gmail.com</a><w=
br>.<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"QXWdD0pCBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"QXWdD0pCBwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b67e-45cd-9493-77fb278=
a40c7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/24f92a35-b67e-45cd-9493-77fb278a40=
c7%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return tru=
e;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/24f92a35-b67e-45cd-9493-77fb278a40c7%40isocpp.org?utm_med=
ium\x3demail\x26utm_source\x3dfooter';return true;">https://groups.goog=
le.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/24f92a35-b67e-45cd-<wbr=
>9493-77fb278a40c7%40isocpp.org</a><wbr>.<br>
</blockquote>
<br>
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7adbbe85-72f1-4bdb-945c-3dc3f1a161b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7adbbe85-72f1-4bdb-945c-3dc3f1a161b4=
%40isocpp.org</a>.<br />
------=_Part_3627_794145824.1517833445066--
------=_Part_3626_674206928.1517833445064--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 5 Feb 2018 08:50:45 -0800 (PST)
Raw View
------=_Part_32135_1736437811.1517849445747
Content-Type: multipart/alternative;
boundary="----=_Part_32136_943222870.1517849445748"
------=_Part_32136_943222870.1517849445748
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, February 5, 2018 at 7:24:05 AM UTC-5, floria...@gmail.com wrote:
>
>
>
> Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9crit :
>>
>>
>>
>> On 02/05/2018 10:31 AM, floria...@gmail.com wrote:
>>
>> Then, what is the difference with usual expression templates?
>>
>>
>> The compiler generates them.
>>
>
> So? What is the difference for the end user?
>
That you don't have to write one. Writing an expression template system is=
=20
exceedingly complicated. It's not something you can easily abstract.
Granted, this variadic operator idea is hardly equivalent to an expression=
=20
template system, so comparing them isn't really reasonable.
--=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/c46f019e-48a3-4eaf-a9fd-087357593abb%40isocpp.or=
g.
------=_Part_32136_943222870.1517849445748
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 5, 2018 at 7:24:05 AM UTC-5, floria...=
@gmail.com 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"><br><br>Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=
=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 02/05/2018 10:31 AM,
<a rel=3D"nofollow">floria...@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Then, what is the difference with usual expression
templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br></div></blockquote><div><br></div><div>=
So? What is the difference for the end user?</div></div></blockquote><div><=
br></div><div>That you don't have to write one. Writing an expression t=
emplate system is exceedingly complicated. It's not something you can e=
asily abstract.</div><div><br></div><div>Granted, this variadic operator id=
ea is hardly equivalent to an expression template system, so comparing them=
isn't really reasonable.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
</div>
</blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c46f019e-48a3-4eaf-a9fd-087357593abb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c46f019e-48a3-4eaf-a9fd-087357593abb=
%40isocpp.org</a>.<br />
------=_Part_32136_943222870.1517849445748--
------=_Part_32135_1736437811.1517849445747--
.
Author: florian.csdt@gmail.com
Date: Mon, 5 Feb 2018 09:59:39 -0800 (PST)
Raw View
------=_Part_4716_588483579.1517853579767
Content-Type: multipart/alternative;
boundary="----=_Part_4717_2068653500.1517853579767"
------=_Part_4717_2068653500.1517853579767
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bolas a =C3=A9crit :
>
> On Monday, February 5, 2018 at 7:24:05 AM UTC-5, floria...@gmail.com=20
> wrote:
>>
>>
>>
>> Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9crit :
>>>
>>>
>>>
>>> On 02/05/2018 10:31 AM, floria...@gmail.com wrote:
>>>
>>> Then, what is the difference with usual expression templates?
>>>
>>>
>>> The compiler generates them.
>>>
>>
>> So? What is the difference for the end user?
>>
>
> That you don't have to write one. Writing an expression template system i=
s=20
> exceedingly complicated. It's not something you can easily abstract.
>
> Granted, this variadic operator idea is hardly equivalent to an expressio=
n=20
> template system, so comparing them isn't really reasonable.
>
>
I was referring to Avi's sub-proposal for the compiler to generate an AST.=
=20
This will not help that much as you still need to explore the AST, and this=
=20
is a tricky part.
But the variadic operator could help when applicable (so not a*b + c*d).
--=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/6e631a15-1b53-4cfa-bf96-db8d8b141366%40isocpp.or=
g.
------=_Part_4717_2068653500.1517853579767
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bol=
as a =C3=A9crit=C2=A0:<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">On Monday, February 5, 2018 at 7:24:05 AM UTC-5, <a>floria...@gmai=
l.com</a> 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"ltr"><b=
r><br>Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9crit=
=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 02/05/2018 10:31 AM,
<a rel=3D"nofollow">floria...@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Then, what is the difference with usual expression
templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br></div></blockquote><div><br></div><div>=
So? What is the difference for the end user?</div></div></blockquote><div><=
br></div><div>That you don't have to write one. Writing an expression t=
emplate system is exceedingly complicated. It's not something you can e=
asily abstract.</div><div><br></div><div>Granted, this variadic operator id=
ea is hardly equivalent to an expression template system, so comparing them=
isn't really reasonable.</div><div><br></div></div></blockquote><div><=
br></div><div>I was referring to Avi's sub-proposal for the compiler to=
generate an AST. This will not help that much as you still need to explore=
the AST, and this is a tricky part.</div><div><br></div><div>But the varia=
dic operator could help when applicable (so not a*b + c*d).<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6e631a15-1b53-4cfa-bf96-db8d8b141366%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e631a15-1b53-4cfa-bf96-db8d8b141366=
%40isocpp.org</a>.<br />
------=_Part_4717_2068653500.1517853579767--
------=_Part_4716_588483579.1517853579767--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Tue, 6 Feb 2018 13:44:44 +0200
Raw View
This is a multi-part message in MIME format.
--------------A07E4CE16FECECC9ECED8DEE
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 02/05/2018 07:59 PM, florian.csdt@gmail.com wrote:
>
> Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bolas a =C3=A9crit=C2=
=A0:
>
> On Monday, February 5, 2018 at 7:24:05 AM UTC-5,
> floria...@gmail.com wrote:
>
>
>
> Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9c=
rit=C2=A0:
>
>
>
> On 02/05/2018 10:31 AM, floria...@gmail.com wrote:
>> Then, what is the difference with usual expression templates=
?
>
> The compiler generates them.
>
>
> So? What is the difference for the end user?
>
>
> That you don't have to write one. Writing an expression template
> system is exceedingly complicated. It's not something you can
> easily abstract.
>
> Granted, this variadic operator idea is hardly equivalent to an
> expression template system, so comparing them isn't really reasonable=
..
>
>
> I was referring to Avi's sub-proposal for the compiler to generate an=20
> AST. This will not help that much as you still need to explore the=20
> AST, and this is a tricky part.
>
Exploring the AST could be done by pattern-matching, for which there is=20
good support already. For more complex optimizations you'd have to write=20
code, but that's life.
> But the variadic operator could help when applicable (so not a*b + c*d).
>
The variadic operator captures one special case, but there are many=20
more. Why solve a small subset of the problem?
--=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/6cedf15c-fc15-ca0b-ec93-574b16a8d797%40scylladb.=
com.
--------------A07E4CE16FECECC9ECED8DEE
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 02/05/2018 07:59 PM,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:florian.csdt@gma=
il.com">florian.csdt@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:6e631a15-1b53-4cfa-bf96-db8d8b141366@isocpp.org">
<div dir=3D"ltr"><br>
Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bolas a =C3=A9cr=
it=C2=A0:
<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">On Monday, February 5, 2018 at 7:24:05 AM
UTC-5, <a moz-do-not-send=3D"true">floria...@gmail.com</a>
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"ltr"><br>
<br>
Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a
=C3=A9crit=C2=A0:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 02/05/2018 10:31 AM, <a rel=3D"nofollow"
moz-do-not-send=3D"true">floria...@gmail.com</a>
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Then, what is the difference with
usual expression templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br>
</div>
</blockquote>
<div><br>
</div>
<div>So? What is the difference for the end user?</div>
</div>
</blockquote>
<div><br>
</div>
<div>That you don't have to write one. Writing an expression
template system is exceedingly complicated. It's not
something you can easily abstract.</div>
<div><br>
</div>
<div>Granted, this variadic operator idea is hardly
equivalent to an expression template system, so comparing
them isn't really reasonable.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I was referring to Avi's sub-proposal for the compiler to
generate an AST. This will not help that much as you still
need to explore the AST, and this is a tricky part.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Exploring the AST could be done by pattern-matching, for which there
is good support already. For more complex optimizations you'd have
to write code, but that's life.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:6e631a15-1b53-4cfa-bf96-db8d8b141366@isocpp.org">
<div dir=3D"ltr">
<div>But the variadic operator could help when applicable (so
not a*b + c*d).<br>
</div>
</div>
<br>
</blockquote>
<br>
The variadic operator captures one special case, but there are many
more. Why solve a small subset of the problem?<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6cedf15c-fc15-ca0b-ec93-574b16a8d797%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/6cedf15c-fc15-ca0b-ec93-574b16a8d7=
97%40scylladb.com</a>.<br />
--------------A07E4CE16FECECC9ECED8DEE--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 6 Feb 2018 07:10:54 -0800 (PST)
Raw View
------=_Part_39395_2077933701.1517929855094
Content-Type: multipart/alternative;
boundary="----=_Part_39396_1907268706.1517929855095"
------=_Part_39396_1907268706.1517929855095
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 6, 2018 at 6:44:49 AM UTC-5, Avi Kivity wrote:
>
>
>
> On 02/05/2018 07:59 PM, floria...@gmail.com <javascript:> wrote:
>
>
> Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bolas a =C3=A9crit :=
=20
>>
>> On Monday, February 5, 2018 at 7:24:05 AM UTC-5, floria...@gmail.com=20
>> wrote:=20
>>>
>>>
>>>
>>> Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a =C3=A9crit :=
=20
>>>>
>>>>
>>>>
>>>> On 02/05/2018 10:31 AM, floria...@gmail.com wrote:
>>>>
>>>> Then, what is the difference with usual expression templates?
>>>>
>>>>
>>>> The compiler generates them.
>>>>
>>>
>>> So? What is the difference for the end user?
>>>
>>
>> That you don't have to write one. Writing an expression template system=
=20
>> is exceedingly complicated. It's not something you can easily abstract.
>>
>> Granted, this variadic operator idea is hardly equivalent to an=20
>> expression template system, so comparing them isn't really reasonable.
>>
>>
> I was referring to Avi's sub-proposal for the compiler to generate an AST=
..=20
> This will not help that much as you still need to explore the AST, and th=
is=20
> is a tricky part.
>
>
> Exploring the AST could be done by pattern-matching, for which there is=
=20
> good support already. For more complex optimizations you'd have to write=
=20
> code, but that's life.
>
I think this is just too much work for too little gain. With metaclasses,=
=20
it should be possible to abstract much of the expression template=20
boilerplate. Given such a tool, the only thing you lack is the ability for=
=20
deduction to deduce the value type rather than the expression type.
>
--=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/a3ebba1f-1bc7-4078-8f0d-e6536df6db3d%40isocpp.or=
g.
------=_Part_39396_1907268706.1517929855095
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 6, 2018 at 6:44:49 AM UTC-5, =
Avi Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 02/05/2018 07:59 PM,
<a onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:=
" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"z7PcCkePBwAJ"=
>floria...@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
Le lundi 5 f=C3=A9vrier 2018 17:50:45 UTC+1, Nicol Bolas a =C3=A9cr=
it=C2=A0:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Monday, February 5, 2018 at 7:24:05 AM
UTC-5, <a>floria...@gmail.com</a>
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"ltr"><br>
<br>
Le lundi 5 f=C3=A9vrier 2018 13:14:00 UTC+1, Avi Kivity a
=C3=A9crit=C2=A0:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 02/05/2018 10:31 AM, <a rel=3D"nofollow">floria=
....@gmail.com</a>
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Then, what is the difference with
usual expression templates?<br>
</div>
</blockquote>
<br>
The compiler generates them.<br>
</div>
</blockquote>
<div><br>
</div>
<div>So? What is the difference for the end user?</div>
</div>
</blockquote>
<div><br>
</div>
<div>That you don't have to write one. Writing an expressio=
n
template system is exceedingly complicated. It's not
something you can easily abstract.</div>
<div><br>
</div>
<div>Granted, this variadic operator idea is hardly
equivalent to an expression template system, so comparing
them isn't really reasonable.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I was referring to Avi's sub-proposal for the compiler to
generate an AST. This will not help that much as you still
need to explore the AST, and this is a tricky part.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Exploring the AST could be done by pattern-matching, for which there
is good support already. For more complex optimizations you'd have
to write code, but that's life.<br></div></blockquote><div><br></di=
v><div>I think this is just too much work for too little gain. With metacla=
sses, it should be possible to abstract much of the expression template boi=
lerplate. Given such a tool, the only thing you lack is the ability for ded=
uction to deduce the value type rather than the expression type.<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a3ebba1f-1bc7-4078-8f0d-e6536df6db3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3ebba1f-1bc7-4078-8f0d-e6536df6db3d=
%40isocpp.org</a>.<br />
------=_Part_39396_1907268706.1517929855095--
------=_Part_39395_2077933701.1517929855094--
.