------=_Part_3138_817465002.1477980097861
Content-Type: multipart/alternative;
 boundary="----=_Part_3139_380469089.1477980097861"

------=_Part_3139_380469089.1477980097861
Content-Type: text/plain; charset=UTF-8

Currently, __func__ is part of the c++ standard, however
__PRETTY_FUNCTION__ (part of GCC and Clang) provides significantly more
information about a function. It's more useful for printing debugging
information and error messages, and in addition it provides a method for
getting the programmatic name of a type. An example usage is shown below:

#include <string>
#include <iostream>
#include <tuple>

template<class type> constexpr std::string GetName()
{
const char* start = __PRETTY_FUNCTION__;
while(*start != '=') ++start;
start += 2;
size_t size = 0;
while(start[size] != ';') ++size;
return std::string(start, size);
}
int main()
{
std::cout << GetName<void>() << std::endl;
std::cout << GetName<int>() << std::endl;
std::cout << GetName<decltype(0.3)>() << std::endl;
std::cout << GetName<std::tuple<int, char>>() << std::endl;
// Output:
// void
// int
// double
// std::tuple<int, char>
}


--
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/758acd83-fc11-4acb-b9dc-1ec287e2e4ec%40isocpp.org.

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

<div dir=3D"ltr">Currently, __func__ is part of the c++ standard, however _=
_PRETTY_FUNCTION__ (part of GCC and Clang) provides significantly more info=
rmation about a function. It&#39;s more useful for printing debugging infor=
mation and error messages, and in addition it provides a method for getting=
 the programmatic name of a type. An example usage is shown below:<div><br>=
</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><font color=3D"#660066"><div class=3D"subprettyprint">#incl=
ude &lt;string&gt;</div><div class=3D"subprettyprint">#include &lt;iostream=
&gt;</div><div class=3D"subprettyprint">#include &lt;tuple&gt;</div><div cl=
ass=3D"subprettyprint"><br></div><div class=3D"subprettyprint">template&lt;=
class type&gt; constexpr std::string GetName()</div><div class=3D"subpretty=
print">{</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>const char* start =3D __PRETTY_FUNCTION__=
;</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>while(*start !=3D &#39;=3D&#39;) ++start;</div=
><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre"> </span>start +=3D 2;</div><div class=3D"subprettyprint"><span=
 class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>size_t size =3D=
 0;</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>while(start[size] !=3D &#39;;&#39;) ++size;</d=
iv><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>return std::string(start, size);</div><div class=3D"=
subprettyprint">}</div><div class=3D"subprettyprint">int main()</div><div c=
lass=3D"subprettyprint">{</div><div class=3D"subprettyprint"><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>std::cout &lt;&lt; GetNa=
me&lt;void&gt;() &lt;&lt; std::endl;=C2=A0</div><div class=3D"subprettyprin=
t"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>std::co=
ut &lt;&lt; GetName&lt;int&gt;() &lt;&lt; std::endl;</div><div class=3D"sub=
prettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>std::cout &lt;&lt; GetName&lt;decltype(0.3)&gt;() &lt;&lt; std::endl;</d=
iv><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>std::cout &lt;&lt; GetName&lt;std::tuple&lt;int, cha=
r&gt;&gt;() &lt;&lt; std::endl;</div><div class=3D"subprettyprint"><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// Output:=C2=A0</=
div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>// void</div><div class=3D"subprettyprint"><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// int</div><div c=
lass=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space=
:pre"> </span>// double</div><div class=3D"subprettyprint"><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>// std::tuple&lt;int, char=
&gt;</div><div class=3D"subprettyprint">}</div></font></div></code></div><b=
r><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/758acd83-fc11-4acb-b9dc-1ec287e2e4ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/758acd83-fc11-4acb-b9dc-1ec287e2e4ec=
%40isocpp.org</a>.<br />

------=_Part_3139_380469089.1477980097861--

------=_Part_3138_817465002.1477980097861--

.

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

>
> it provides a method for getting the programmatic name of a type


So does typeid().name() if you're willing to decode it. My guess is you
don't think that's "PRETTY" enough.

What's your proposed format for the result of this macro? That might help
people get enthused.

However, I don't think I can, since this is nothing I can't already do
myself while debugging - a process that can never be pretty anyway - and
anyway, I would prefer a macro to get the pretty name of a single
designated type, rather than having to chop it out of a (currently
arbitrary) string myself.

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

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

<div dir=3D"ltr"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">it provi=
des a method for getting the programmatic name of a type</blockquote><div><=
br></div><div>So does typeid().name() if you&#39;re willing to decode it. M=
y guess is you don&#39;t think that&#39;s &quot;PRETTY&quot; enough.<br><br=
></div><div>What&#39;s your proposed format for the result of this macro? T=
hat might help people get enthused.<br><br>However, I don&#39;t think I can=
, since this is nothing I can&#39;t already do myself while debugging - a p=
rocess that can never be pretty anyway - and anyway, I would prefer a macro=
 to get the pretty name of a single designated type, rather than having to =
chop it out of a (currently arbitrary) string myself.<br>=C2=A0<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhF1xhsgoN_5bY6JDvRtx6sTeggcvjB4=
fyCLiGsRjjpGsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF1xhsgoN_5=
bY6JDvRtx6sTeggcvjB4fyCLiGsRjjpGsw%40mail.gmail.com</a>.<br />

--001a11443a003a916a0540386d20--

.

On 01.11.2016 08:39, D. B. wrote:
>I would prefer a macro to get the pretty name of a single
> designated type, rather than having to chop it out of a (currently
> arbitrary) string myself.

There is a `typename(type)` that returns a string proposed by some
reflection proposal, isn't it?

--
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/419cf0aa-a532-2e76-b975-062c1ffaf3e9%40gmail.com.

.

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

On Tue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=BCller <
jonathanmueller.dev@gmail.com> wrote:

>
> There is a `typename(type)` that returns a string proposed by some
> reflection proposal, isn't it?
>

Yeah, no doubt all reflection proposals have a solution for this, and in a
much tidier way, so the 'get a type name' argument doesn't hold water to
me. Done right, reflection would also better serve the 'get a function
signature' use case. I think it's more productive to push for reflection to
be standardised, as it just keeps coming up, and it could solve this as a
consequence. Getting a modular reflection system in seems more productive
than arguing about exactly how a debug text string should be formatted (to
the level of arguing over the positioning of asterisks, ampersands, etc.)

Maybe I'm wrong and there's some key feature of __PRETTY_FUNCTION__ that
makes it uniquely desirable, which I might see if the OP would actually
substantiate the proposal and its context, instead of just asking for it to
be added.

--=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/CACGiwhHxRVP8cWcyzuqTO%2BMZxwT4LAkfaNyMkB6rosB0E=
z8LUg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=BCller <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jonathanmueller.dev@gmail.com" target=3D"_blank">jonathanmuel=
ler.dev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span class=3D""><br></span>
There is a `typename(type)` that returns a string proposed by some reflecti=
on proposal, isn&#39;t it?<span class=3D""><br></span></blockquote><div><br=
></div><div>Yeah, no doubt all reflection proposals have a solution for thi=
s, and in a much tidier way, so the &#39;get a type name&#39; argument does=
n&#39;t hold water to me. Done right, reflection would also better serve th=
e &#39;get a function signature&#39; use case. I think it&#39;s more produc=
tive to push for reflection to be standardised, as it just keeps coming up,=
 and it could solve this as a consequence. Getting a modular reflection sys=
tem in seems more productive than arguing about exactly how a debug text st=
ring should be formatted (to the level of arguing over the positioning of a=
sterisks, ampersands, etc.)<br><br>Maybe I&#39;m wrong and there&#39;s some=
 key feature of __PRETTY_FUNCTION__ that makes it uniquely desirable, which=
 I might see if the OP would actually substantiate the proposal and its con=
text, instead of just asking for it to be added.<br></div></div></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHxRVP8cWcyzuqTO%2BMZxwT4LAkfaN=
yMkB6rosB0Ez8LUg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHxRVP8cW=
cyzuqTO%2BMZxwT4LAkfaNyMkB6rosB0Ez8LUg%40mail.gmail.com</a>.<br />

--001a113677f4dbcfa705403adb9d--

.

------=_Part_3502_1451744535.1478041746460
Content-Type: multipart/alternative;
 boundary="----=_Part_3503_1337327191.1478041746460"

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

On Monday, October 31, 2016 at 11:01:38 PM UTC-7, ant...@perezexcelsior.com=
=20
wrote:
>
> Currently, __func__ is part of the c++ standard, however=20
> __PRETTY_FUNCTION__ (part of GCC and Clang) provides significantly more=
=20
> information about a function.
>

FWIW, my attitude toward __PRETTY_FUNCTION__ is the same as my attitude=20
toward "#pragma once" (in the recent thread on that subject).  I love it=20
and evangelize its usage; but since it already exists and works great (for=
=20
me and everyone I know), what's the benefit of standardizing it?  Just to=
=20
antagonize the MSVC dev team? ;)  (MSVC supports something called _FUNCSIG=
=20
but not __PRETTY_FUNCTION__. I'd love for them to get on that, but I don't=
=20
think the ISO C++ committee is the right vector for MSVC feature requests.)

Putting on my language-lawyer hat: Notice that there is technically nothing=
=20
stopping any vendor from making __func__'s implementation-defined string=20
match the output of GCC's __PRETTY_FUNCTION__.  Also notice that=20
__FUNCTION__ itself is not yet standardized; __func__ was C99's way of=20
sneaking __FUNCTION__-like semantics into the language without having to=20
admit the existence of predefined macros.

IMHO you have presented a very neat little GetName() idiom that works on=20
all implementations I care about; but IMHO you have not particularly shown=
=20
any reason for changing the C++ Standard.

my $.02,
=E2=80=93Arthur

--=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/fb9daec5-1c3d-4f08-932b-47a6b64d5c05%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, October 31, 2016 at 11:01:38 PM UTC-7, ant...@p=
erezexcelsior.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Currently, __func__ is part of the c++ standard, however __PRETT=
Y_FUNCTION__ (part of GCC and Clang) provides significantly more informatio=
n about a function.</div></blockquote><div><br></div><div>FWIW, my attitude=
 toward __PRETTY_FUNCTION__ is the same as my attitude toward &quot;#pragma=
 once&quot; (in the recent thread on that subject). =C2=A0I love it and eva=
ngelize its usage; but since it already exists and works great (for me and =
everyone I know), what&#39;s the benefit of standardizing it? =C2=A0Just to=
 antagonize the MSVC dev team? ;) =C2=A0(MSVC supports something called _FU=
NCSIG but not __PRETTY_FUNCTION__. I&#39;d love for them to get on that, bu=
t I don&#39;t think the ISO C++ committee is the right vector for MSVC feat=
ure requests.)</div><div><br></div><div>Putting on my language-lawyer hat: =
Notice that there is technically nothing stopping any vendor from making __=
func__&#39;s implementation-defined string match the output of GCC&#39;s __=
PRETTY_FUNCTION__. =C2=A0Also notice that __FUNCTION__ itself is not yet st=
andardized; __func__ was C99&#39;s way of sneaking __FUNCTION__-like semant=
ics into the language without having to admit the existence of predefined m=
acros.</div><div><br></div><div>IMHO you have presented a very neat little =
GetName() idiom that works on all implementations I care about; but IMHO yo=
u have not particularly shown any reason for changing the C++ Standard.</di=
v><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb9daec5-1c3d-4f08-932b-47a6b64d5c05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb9daec5-1c3d-4f08-932b-47a6b64d5c05=
%40isocpp.org</a>.<br />

------=_Part_3503_1337327191.1478041746460--

------=_Part_3502_1451744535.1478041746460--

.

------=_Part_752_1433107232.1478048524154
Content-Type: multipart/alternative;
 boundary="----=_Part_753_1759016025.1478048524154"

------=_Part_753_1759016025.1478048524154
Content-Type: text/plain; charset=UTF-8

On Tuesday, November 1, 2016 at 7:09:06 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Monday, October 31, 2016 at 11:01:38 PM UTC-7,
> ant...@perezexcelsior.com wrote:
>>
>> Currently, __func__ is part of the c++ standard, however
>> __PRETTY_FUNCTION__ (part of GCC and Clang) provides significantly more
>> information about a function.
>>
>
> FWIW, my attitude toward __PRETTY_FUNCTION__ is the same as my attitude
> toward "#pragma once" (in the recent thread on that subject).  I love it
> and evangelize its usage; but since it already exists and works great (for
> me and everyone I know), what's the benefit of standardizing it?  Just to
> antagonize the MSVC dev team? ;)  (MSVC supports something called _FUNCSIG
> but not __PRETTY_FUNCTION__. I'd love for them to get on that, but I don't
> think the ISO C++ committee is the right vector for MSVC feature requests.)
>

That's the whole point of standardizing *anything*: so that all
implementations can agree on what a particular thing means and how it will
behave. You're basically saying that if GCC and Clang both implement some
feature, then who cares if it's part of the standard or not.

The C++ standard is not just for people using GCC or Clang.

--
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/8f0ded60-d765-4029-862c-d10d5dcd26b4%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, November 1, 2016 at 7:09:06 PM UTC-4, Arthur O=
&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Monday, October 31, 2016 at 11:01:38 PM UTC-7, <a>ant...@perezexcels=
ior.com</a> 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"ltr">=
Currently, __func__ is part of the c++ standard, however __PRETTY_FUNCTION_=
_ (part of GCC and Clang) provides significantly more information about a f=
unction.</div></blockquote><div><br></div><div>FWIW, my attitude toward __P=
RETTY_FUNCTION__ is the same as my attitude toward &quot;#pragma once&quot;=
 (in the recent thread on that subject). =C2=A0I love it and evangelize its=
 usage; but since it already exists and works great (for me and everyone I =
know), what&#39;s the benefit of standardizing it? =C2=A0Just to antagonize=
 the MSVC dev team? ;) =C2=A0(MSVC supports something called _FUNCSIG but n=
ot __PRETTY_FUNCTION__. I&#39;d love for them to get on that, but I don&#39=
;t think the ISO C++ committee is the right vector for MSVC feature request=
s.)</div></div></blockquote><div><br>That&#39;s the whole point of standard=
izing <i>anything</i>: so that all implementations can agree on what a part=
icular thing means and how it will behave. You&#39;re basically saying that=
 if GCC and Clang both implement some feature, then who cares if it&#39;s p=
art of the standard or not.<br><br>The C++ standard is not just for people =
using GCC or Clang.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8f0ded60-d765-4029-862c-d10d5dcd26b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8f0ded60-d765-4029-862c-d10d5dcd26b4=
%40isocpp.org</a>.<br />

------=_Part_753_1759016025.1478048524154--

------=_Part_752_1433107232.1478048524154--

.

Em ter=C3=A7a-feira, 1 de novembro de 2016, =C3=A0s 18:02:04 PDT, Nicol Bol=
as escreveu:
> That's the whole point of standardizing *anything*: so that all
> implementations can agree on what a particular thing means and how it wil=
l
> behave. You're basically saying that if GCC and Clang both implement some
> feature, then who cares if it's part of the standard or not.
>=20
> The C++ standard is not just for people using GCC or Clang.

Except that we'd standardise that it is a string literal of unknown and=20
arbitrary contents. What's the point of standardising that?

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/27892437.xZt6Yvu74S%40tjmaciei-mobl1.

.

------=_Part_3227_1721482115.1478055850918
Content-Type: multipart/alternative;
 boundary="----=_Part_3228_1481531193.1478055850918"

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



On Tuesday, November 1, 2016 at 9:19:07 PM UTC-4, Thiago Macieira wrote:
>
> Em ter=C3=A7a-feira, 1 de novembro de 2016, =C3=A0s 18:02:04 PDT, Nicol B=
olas=20
> escreveu:=20
> > That's the whole point of standardizing *anything*: so that all=20
> > implementations can agree on what a particular thing means and how it=
=20
> will=20
> > behave. You're basically saying that if GCC and Clang both implement=20
> some=20
> > feature, then who cares if it's part of the standard or not.=20
> >=20
> > The C++ standard is not just for people using GCC or Clang.=20
>
> Except that we'd standardise that it is a string literal of unknown and=
=20
> arbitrary contents. What's the point of standardising that?
>

Well, I assumed that if it were going to be standardized, it would be=20
standardized to have *specific* content. Yes, if it's just "it's a string=
=20
of some kind which probably represents the function declaration," then=20
standardizing it has no point.

If we can't give it a specific, well-understood format, then it'd be better=
=20
if we all just waited for reflection so that we could build it ourselves.

--=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/79e8df8a-a2f8-4852-8384-452c4e7a9d43%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, November 1, 2016 at 9:19:07 PM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em ter=
=C3=A7a-feira, 1 de novembro de 2016, =C3=A0s 18:02:04 PDT, Nicol Bolas esc=
reveu:
<br>&gt; That&#39;s the whole point of standardizing *anything*: so that al=
l
<br>&gt; implementations can agree on what a particular thing means and how=
 it will
<br>&gt; behave. You&#39;re basically saying that if GCC and Clang both imp=
lement some
<br>&gt; feature, then who cares if it&#39;s part of the standard or not.
<br>&gt;=20
<br>&gt; The C++ standard is not just for people using GCC or Clang.
<br>
<br>Except that we&#39;d standardise that it is a string literal of unknown=
 and=20
<br>arbitrary contents. What&#39;s the point of standardising that?<br></bl=
ockquote><div><br>Well, I assumed that if it were going to be standardized,=
 it would be standardized to have <i>specific</i> content. Yes, if it&#39;s=
 just &quot;it&#39;s a string of some kind which probably represents the fu=
nction declaration,&quot; then standardizing it has no point.<br><br>If we =
can&#39;t give it a specific, well-understood format, then it&#39;d be bett=
er if we all just waited for reflection so that we could build it ourselves=
..<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79e8df8a-a2f8-4852-8384-452c4e7a9d43%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79e8df8a-a2f8-4852-8384-452c4e7a9d43=
%40isocpp.org</a>.<br />

------=_Part_3228_1481531193.1478055850918--

------=_Part_3227_1721482115.1478055850918--

.

On 11/1/2016 10:04 PM, Nicol Bolas wrote:
> Well, I assumed that if it were going to be standardized, it would be
> standardized to have /specific/ content. Yes, if it's just "it's a
> string of some kind which probably represents the function declaration,"
> then standardizing it has no point.

Even if you standardized the general format of how the content is laid
out, like how you show template arguments, that doesn't necessarily mean
every compiler will show the same thing. For instance, if you have a
function `std::string foo()`, __PRETTY_FUNCTION__ could be:

* std::string foo() -- clang
* std::basic_string<char> foo() -- gcc
* std::__cxx11::basic_string<char> foo() -- gcc with libstdc++'s C++11 ABI
* class std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > __cdecl foo(void) -- msvc (via __FUNCSIG__)

All of these are valid, and I don't think there's a great way to say in
general which one is the *most* valid; if you say
`std::basic_string<char>` in your declaration, but `std::string` in your
definition, which do you prefer? (Arguably the latter.) While it's true
we could standardize this as well, I'm not sure if it's worth it when we
could focus on standardizing reflection.

- Jim

--
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/nvbmpp%24q2i%241%40blaine.gmane.org.

.

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

On Tue, Nov 1, 2016 at 7:01 AM, <antonio@perezexcelsior.com> wrote:

> Currently, __func__ is part of the c++ standard, however
__PRETTY_FUNCTION__ (part of GCC and Clang) provides significantly more
information about a function. It's more useful for printing debugging
information and error messages, and in addition it provides a method for
getting the programmatic name of a type.

C++ has no way to refer to the current function. That is why we use
__func__ and __PRETTY_FUNCTION__ to refer to *some* information on the
current function. That may also be why we keep seeing proposals "let's
standardise this way of getting stack traces".

I'd rather have the real problem fixed than more hacks standardised.

Cheers,
V.

--
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/CAA7YVg2_j1Kd8CAfYXnD65mksf3%2BvweD_Qxuw9%3D5Bg7KWnbaEw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 1, 2016 at 7:01 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:antoni=
o@perezexcelsior.com" target=3D"_blank">antonio@perezexcelsior.com</a>&gt;<=
/span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">&gt; Currently, __func__ is part of the c++ standard, however __PRE=
TTY_FUNCTION__ (part of GCC and Clang) provides significantly more informat=
ion about a function. It&#39;s more useful for printing debugging informati=
on and error messages, and in addition it provides a method for getting the=
 programmatic name of a type.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">C++ has no way to refer to the current function. Th=
at is why we use __func__ and __PRETTY_FUNCTION__ to refer to <i>some</i>=
=C2=A0information on the current function. That may also be why we keep see=
ing proposals &quot;let&#39;s standardise this way of getting stack traces&=
quot;.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>I&#39;d rather have the real problem fixed than more hacks standardised.<b=
r></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Che=
ers,</div><div class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2_j1Kd8CAfYXnD65mksf3%2BvweD_Q=
xuw9%3D5Bg7KWnbaEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2_j1Kd=
8CAfYXnD65mksf3%2BvweD_Qxuw9%3D5Bg7KWnbaEw%40mail.gmail.com</a>.<br />

--001a114197aa78d1fd05406335fc--

.

------=_Part_18948_1967043570.1530334997279
Content-Type: multipart/alternative;
 boundary="----=_Part_18949_33811583.1530334997280"

------=_Part_18949_33811583.1530334997280
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would argue that the key feature of __PRETTY_FUNCTION__ is that for=20
template functions, it contains the abstract signature followed by a list=
=20
of parameter/argument pairs, while __FUNCSIG__ contains the signature with=
=20
substitutions in-place. Pardon my vocabulary if that isn't quite clear -=20
hopefully an example will go further.

#include <iostream>
#include <utility>
template<class S, template<class...> class TT, class T =3D TT<S,S>>
const char *pretty(T && t =3D {S(), S()})
{ return __PRETTY_FUNCTION__; }
//{ return __FUNCSIG__; }
int main() {
    std::cout << pretty<float, std::pair>() << std::endl;
    //   GCC: const char* pretty(T&&) [with S =3D float; TT =3D std::pair; =
T =3D=20
std::pair<float, float>]
    // Clang: const char *pretty(T &&) [S =3D float, TT =3D std::pair, T =
=3D=20
std::__1::pair<float, float>]
    //  MSVC: const char *__cdecl pretty<float,struct std::pair,struct=20
std::pair<float,float>>(struct std::pair<float,float> &&)
}

I appreciate most of the arguments against standardization so far, but I=20
still see a unique benefit to __PRETTY_FUNCTION__ in particular. The fact=
=20
that it maps template arguments to template parameter names makes it much=
=20
more valuable to anyone neck-deep in template metaprogramming. My example=
=20
is simple and uses brief but unhelpful parameter names, so imagine a=20
complex, heterogeneous parameter list, but with reasonably descriptive=20
parameter names instead.

My argument for standardization would be that all the major compilers found=
=20
the need to represent the current function one way or another, other than=
=20
the nearly useless __func__; there's clearly enough demand for it, but=20
without standardization, every use requires sniffing for each compiler and=
=20
its extensions. (Every missed compiler, even those with a similar=20
definition by another name, is either unable to compile at all, or gets a=
=20
partial build if the default case shunts them around this section.) The=20
standardization would not need to hammer out a specific format, as long as=
=20
it specifies what information must be represented. __PRETTY_FUNCTION__=20
represents more information than the others, so ideally this information=20
would be a part of the standard, but at least some representation of the=20
signature seems reasonable, right?

I agree about reflection, but I think it's a separate concern, albeit=20
tangentially related. We can have multiple concerns. If I'm mistaken, I'd=
=20
happily take an equivalent definition via reflection if it were=20
compiler-agnostic, but I assume this isn't what you intended, or this would=
=20
just be a subset of what you'd like anyway.

On Tuesday, November 1, 2016 at 6:33:46 AM UTC-4, D. B. wrote:
>
> On Tue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=BCller <jonathanm...@gmail.=
com=20
> <javascript:>> wrote:
>
>>
>> There is a `typename(type)` that returns a string proposed by some=20
>> reflection proposal, isn't it?
>>
>
> Yeah, no doubt all reflection proposals have a solution for this, and in =
a=20
> much tidier way, so the 'get a type name' argument doesn't hold water to=
=20
> me. Done right, reflection would also better serve the 'get a function=20
> signature' use case. I think it's more productive to push for reflection =
to=20
> be standardised, as it just keeps coming up, and it could solve this as a=
=20
> consequence. Getting a modular reflection system in seems more productive=
=20
> than arguing about exactly how a debug text string should be formatted (t=
o=20
> the level of arguing over the positioning of asterisks, ampersands, etc.)
>
> Maybe I'm wrong and there's some key feature of __PRETTY_FUNCTION__ that=
=20
> makes it uniquely desirable, which I might see if the OP would actually=
=20
> substantiate the proposal and its context, instead of just asking for it =
to=20
> be added.
>

--=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/c398c7ae-3490-457e-989c-9342bb9b580e%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>I would argue that the key feature of __PRETTY_FUNCTI=
ON__ is that for template functions, it contains the abstract signature fol=
lowed by a list of parameter/argument pairs, while __FUNCSIG__ contains the=
 signature with substitutions in-place. Pardon my vocabulary if that isn&#3=
9;t quite clear - hopefully an example will go further.<br></div><div><br><=
/div><div><div style=3D"background-color: rgb(250, 250, 250); border-color:=
 rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap:=
 break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;iost=
ream&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#include=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">&lt;utility&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> S</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">class</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> TT</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> TT</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">S</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">S</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">pretty</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">S</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> S</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()})</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> __PRETTY_FUNCTION__</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">//{ return __FUNCSIG__; }</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> prett=
y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">pair</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
ndl</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =C2=
=A0 GCC: const char* pretty(T&amp;&amp;) [with S =3D float; TT =3D std::pai=
r; T =3D std::pair&lt;float, float&gt;]</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// Clang: const char *pretty(T &amp;&a=
mp;) [S =3D float, TT =3D std::pair, T =3D std::__1::pair&lt;float, float&g=
t;]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// =C2=A0MSVC: const char *__cdecl pretty&lt;float,struct std::pair,struct=
 std::pair&lt;float,float&gt;&gt;(struct std::pair&lt;float,float&gt; &amp;=
&amp;)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></=
div></code></div></div><div><br>I appreciate most of the arguments against =
standardization so far, but I still see a unique benefit to __PRETTY_FUNCTI=
ON__ in particular.<span style=3D"font-family: arial, sans-serif;"> The fac=
t that it maps template arguments to template parameter names makes it much=
 more valuable to anyone neck-deep in template metaprogramming. <span class=
=3D"_username"><span class=3D"F0XO1GC-D-a" style=3D"color: rgb(34, 34, 34);=
"></span></span></span>My example is simple and uses brief but unhelpful pa=
rameter names, so imagine a complex, heterogeneous parameter list, but with=
 reasonably descriptive parameter names instead.</div><div><br></div><div>M=
y argument for standardization would be that all the major compilers found =
the need to represent the current function one way or another, other than t=
he nearly useless __func__; there&#39;s clearly enough demand for it, but w=
ithout standardization, every use requires sniffing for each compiler and i=
ts extensions. (Every missed compiler, even those with a similar definition=
 by another name, is either unable to compile at all, or gets a partial bui=
ld if the default case shunts them around this section.) The standardizatio=
n would not need to hammer out a specific format, as long as it specifies w=
hat information must be represented. __PRETTY_FUNCTION__ represents more in=
formation than the others, so ideally this information would be a part of t=
he standard, but at least some representation of the signature seems reason=
able, right?</div><div><br></div><div>I agree about reflection, but I think=
 it&#39;s a separate concern, albeit tangentially related. We can have mult=
iple concerns. If I&#39;m mistaken, I&#39;d happily take an equivalent defi=
nition via reflection if it were compiler-agnostic, but I assume this isn&#=
39;t what you intended, or this would just be a subset of what you&#39;d li=
ke anyway.<br></div><br>On Tuesday, November 1, 2016 at 6:33:46 AM UTC-4, D=
.. B. 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"><d=
iv><div class=3D"gmail_quote">On Tue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=
=BCller <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"tQ7GdMSjBAAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jonathanm...@gmail.com</a><wbr>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span><br></span>
There is a `typename(type)` that returns a string proposed by some reflecti=
on proposal, isn&#39;t it?<span><br></span></blockquote><div><br></div><div=
>Yeah, no doubt all reflection proposals have a solution for this, and in a=
 much tidier way, so the &#39;get a type name&#39; argument doesn&#39;t hol=
d water to me. Done right, reflection would also better serve the &#39;get =
a function signature&#39; use case. I think it&#39;s more productive to pus=
h for reflection to be standardised, as it just keeps coming up, and it cou=
ld solve this as a consequence. Getting a modular reflection system in seem=
s more productive than arguing about exactly how a debug text string should=
 be formatted (to the level of arguing over the positioning of asterisks, a=
mpersands, etc.)<br><br>Maybe I&#39;m wrong and there&#39;s some key featur=
e of __PRETTY_FUNCTION__ that makes it uniquely desirable, which I might se=
e if the OP would actually substantiate the proposal and its context, inste=
ad of just asking for it to be added.<br></div></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c398c7ae-3490-457e-989c-9342bb9b580e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c398c7ae-3490-457e-989c-9342bb9b580e=
%40isocpp.org</a>.<br />

------=_Part_18949_33811583.1530334997280--

------=_Part_18948_1967043570.1530334997279--

.

--000000000000017e5d056fdd1849
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Wouldn't we prefer something like this?

namespace std
{
  struct current_funcition_details
  {
    constexpr string_view base_name() const;  // returns "foo"
    constexpr string_view full_name() const;  // returns e.g. "int
bar::baz::foo(int, double) noexcept"
    size_t argument_count() const;
    array<type_info const&> argument_types() const; // could be something
more constexpr-friendly to avoid instantiation of type_info
    // ... etc ...
  };

  constexpr auto current_function() -> current_function_details;
}


On Sat, 30 Jun 2018 at 07:03, <sobeita@gmail.com> wrote:

> I would argue that the key feature of __PRETTY_FUNCTION__ is that for
> template functions, it contains the abstract signature followed by a list
> of parameter/argument pairs, while __FUNCSIG__ contains the signature wit=
h
> substitutions in-place. Pardon my vocabulary if that isn't quite clear -
> hopefully an example will go further.
>
> #include <iostream>
> #include <utility>
> template<class S, template<class...> class TT, class T =3D TT<S,S>>
> const char *pretty(T && t =3D {S(), S()})
> { return __PRETTY_FUNCTION__; }
> //{ return __FUNCSIG__; }
> int main() {
>     std::cout << pretty<float, std::pair>() << std::endl;
>     //   GCC: const char* pretty(T&&) [with S =3D float; TT =3D std::pair=
; T
> =3D std::pair<float, float>]
>     // Clang: const char *pretty(T &&) [S =3D float, TT =3D std::pair, T =
=3D
> std::__1::pair<float, float>]
>     //  MSVC: const char *__cdecl pretty<float,struct std::pair,struct
> std::pair<float,float>>(struct std::pair<float,float> &&)
> }
>
> I appreciate most of the arguments against standardization so far, but I
> still see a unique benefit to __PRETTY_FUNCTION__ in particular. The fact
> that it maps template arguments to template parameter names makes it much
> more valuable to anyone neck-deep in template metaprogramming. My example
> is simple and uses brief but unhelpful parameter names, so imagine a
> complex, heterogeneous parameter list, but with reasonably descriptive
> parameter names instead.
>
> My argument for standardization would be that all the major compilers
> found the need to represent the current function one way or another, othe=
r
> than the nearly useless __func__; there's clearly enough demand for it, b=
ut
> without standardization, every use requires sniffing for each compiler an=
d
> its extensions. (Every missed compiler, even those with a similar
> definition by another name, is either unable to compile at all, or gets a
> partial build if the default case shunts them around this section.) The
> standardization would not need to hammer out a specific format, as long a=
s
> it specifies what information must be represented. __PRETTY_FUNCTION__
> represents more information than the others, so ideally this information
> would be a part of the standard, but at least some representation of the
> signature seems reasonable, right?
>
> I agree about reflection, but I think it's a separate concern, albeit
> tangentially related. We can have multiple concerns. If I'm mistaken, I'd
> happily take an equivalent definition via reflection if it were
> compiler-agnostic, but I assume this isn't what you intended, or this wou=
ld
> just be a subset of what you'd like anyway.
>
> On Tuesday, November 1, 2016 at 6:33:46 AM UTC-4, D. B. wrote:
>>
>> On Tue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=BCller <jonathanm...@gmail=
..com>
>> wrote:
>>
>>>
>>> There is a `typename(type)` that returns a string proposed by some
>>> reflection proposal, isn't it?
>>>
>>
>> Yeah, no doubt all reflection proposals have a solution for this, and in
>> a much tidier way, so the 'get a type name' argument doesn't hold water =
to
>> me. Done right, reflection would also better serve the 'get a function
>> signature' use case. I think it's more productive to push for reflection=
 to
>> be standardised, as it just keeps coming up, and it could solve this as =
a
>> consequence. Getting a modular reflection system in seems more productiv=
e
>> than arguing about exactly how a debug text string should be formatted (=
to
>> the level of arguing over the positioning of asterisks, ampersands, etc.=
)
>>
>> Maybe I'm wrong and there's some key feature of __PRETTY_FUNCTION__ that
>> makes it uniquely desirable, which I might see if the OP would actually
>> substantiate the proposal and its context, instead of just asking for it=
 to
>> be added.
>>
> --
> 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/c398c7ae-349=
0-457e-989c-9342bb9b580e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c398c7ae-34=
90-457e-989c-9342bb9b580e%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/CALvx3haDvbud8f1dY9pU3-LDsq9wzUEHUXbNaviWnW%2Bi_=
8Q1ww%40mail.gmail.com.

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

<div dir=3D"ltr">Wouldn&#39;t we prefer something like this?<div><br></div>=
<div><font face=3D"monospace, monospace">namespace std</font></div><div><fo=
nt face=3D"monospace, monospace">{</font></div><div><font face=3D"monospace=
, monospace">=C2=A0 struct current_funcition_details</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 {</font></div><div><div style=3D"text=
-decoration-style:initial;text-decoration-color:initial"><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 constexpr string_view base_name() const;=C2=
=A0 // returns &quot;foo&quot;</font></div><div style=3D"text-decoration-st=
yle:initial;text-decoration-color:initial"><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 constexpr string_view full_name() const;=C2=A0 // returns=
 e.g. &quot;int bar::baz::foo(int, double) noexcept&quot;</font></div><div =
style=3D"text-decoration-style:initial;text-decoration-color:initial"><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 size_t argument_count() const;=
</font></div><div style=3D"text-decoration-style:initial;text-decoration-co=
lor:initial"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 array&lt;typ=
e_info const&amp;&gt; argument_types() const; // could be something more co=
nstexpr-friendly to avoid instantiation of type_info</font></div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 // ... etc ...<br class=3D"gmail-Ap=
ple-interchange-newline">=C2=A0 };<br></font></div><div><font face=3D"monos=
pace, monospace"><br></font></div><div><font face=3D"monospace, monospace">=
=C2=A0 constexpr auto current_function() -&gt; current_function_details;</f=
ont></div><div><div><font face=3D"monospace, monospace">}</font></div><div>=
<br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sa=
t, 30 Jun 2018 at 07:03, &lt;<a href=3D"mailto:sobeita@gmail.com">sobeita@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>I would argue that the key feature of __PRETTY_FUNCTION__ is tha=
t for template functions, it contains the abstract signature followed by a =
list of parameter/argument pairs, while __FUNCSIG__ contains the signature =
with substitutions in-place. Pardon my vocabulary if that isn&#39;t quite c=
lear - hopefully an example will go further.<br></div><div><br></div><div><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px" class=3D"m_8923802573064918954pretty=
print"><code class=3D"m_8923802573064918954prettyprint"><div class=3D"m_892=
3802573064918954subprettyprint"><span style=3D"color:#800" class=3D"m_89238=
02573064918954styled-by-prettify">#include</span><span style=3D"color:#000"=
 class=3D"m_8923802573064918954styled-by-prettify"> </span><span style=3D"c=
olor:#080" class=3D"m_8923802573064918954styled-by-prettify">&lt;iostream&g=
t;</span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by=
-prettify"><br></span><span style=3D"color:#800" class=3D"m_892380257306491=
8954styled-by-prettify">#include</span><span style=3D"color:#000" class=3D"=
m_8923802573064918954styled-by-prettify"> </span><span style=3D"color:#080"=
 class=3D"m_8923802573064918954styled-by-prettify">&lt;utility&gt;</span><s=
pan style=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify">=
<br></span><span style=3D"color:#008" class=3D"m_8923802573064918954styled-=
by-prettify">template</span><span style=3D"color:#660" class=3D"m_892380257=
3064918954styled-by-prettify">&lt;</span><span style=3D"color:#008" class=
=3D"m_8923802573064918954styled-by-prettify">class</span><span style=3D"col=
or:#000" class=3D"m_8923802573064918954styled-by-prettify"> S</span><span s=
tyle=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify">,</sp=
an><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-prett=
ify"> </span><span style=3D"color:#008" class=3D"m_8923802573064918954style=
d-by-prettify">template</span><span style=3D"color:#660" class=3D"m_8923802=
573064918954styled-by-prettify">&lt;</span><span style=3D"color:#008" class=
=3D"m_8923802573064918954styled-by-prettify">class</span><span style=3D"col=
or:#660" class=3D"m_8923802573064918954styled-by-prettify">...&gt;</span><s=
pan style=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify">=
 </span><span style=3D"color:#008" class=3D"m_8923802573064918954styled-by-=
prettify">class</span><span style=3D"color:#000" class=3D"m_892380257306491=
8954styled-by-prettify"> TT</span><span style=3D"color:#660" class=3D"m_892=
3802573064918954styled-by-prettify">,</span><span style=3D"color:#000" clas=
s=3D"m_8923802573064918954styled-by-prettify"> </span><span style=3D"color:=
#008" class=3D"m_8923802573064918954styled-by-prettify">class</span><span s=
tyle=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify"> T </=
span><span style=3D"color:#660" class=3D"m_8923802573064918954styled-by-pre=
ttify">=3D</span><span style=3D"color:#000" class=3D"m_8923802573064918954s=
tyled-by-prettify"> TT</span><span style=3D"color:#660" class=3D"m_89238025=
73064918954styled-by-prettify">&lt;</span><span style=3D"color:#000" class=
=3D"m_8923802573064918954styled-by-prettify">S</span><span style=3D"color:#=
660" class=3D"m_8923802573064918954styled-by-prettify">,</span><span style=
=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify">S</span><=
span style=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify"=
>&gt;&gt;</span><span style=3D"color:#000" class=3D"m_8923802573064918954st=
yled-by-prettify"><br></span><span style=3D"color:#008" class=3D"m_89238025=
73064918954styled-by-prettify">const</span><span style=3D"color:#000" class=
=3D"m_8923802573064918954styled-by-prettify"> </span><span style=3D"color:#=
008" class=3D"m_8923802573064918954styled-by-prettify">char</span><span sty=
le=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify"> </span=
><span style=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettif=
y">*</span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-=
by-prettify">pretty</span><span style=3D"color:#660" class=3D"m_89238025730=
64918954styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_8=
923802573064918954styled-by-prettify">T </span><span style=3D"color:#660" c=
lass=3D"m_8923802573064918954styled-by-prettify">&amp;&amp;</span><span sty=
le=3D"color:#000" class=3D"m_8923802573064918954styled-by-prettify"> t </sp=
an><span style=3D"color:#660" class=3D"m_8923802573064918954styled-by-prett=
ify">=3D</span><span style=3D"color:#000" class=3D"m_8923802573064918954sty=
led-by-prettify"> </span><span style=3D"color:#660" class=3D"m_892380257306=
4918954styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_89=
23802573064918954styled-by-prettify">S</span><span style=3D"color:#660" cla=
ss=3D"m_8923802573064918954styled-by-prettify">(),</span><span style=3D"col=
or:#000" class=3D"m_8923802573064918954styled-by-prettify"> S</span><span s=
tyle=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify">()})<=
/span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-pr=
ettify"><br></span><span style=3D"color:#660" class=3D"m_892380257306491895=
4styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_89238025=
73064918954styled-by-prettify"> </span><span style=3D"color:#008" class=3D"=
m_8923802573064918954styled-by-prettify">return</span><span style=3D"color:=
#000" class=3D"m_8923802573064918954styled-by-prettify"> __PRETTY_FUNCTION_=
_</span><span style=3D"color:#660" class=3D"m_8923802573064918954styled-by-=
prettify">;</span><span style=3D"color:#000" class=3D"m_8923802573064918954=
styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_892380257=
3064918954styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m=
_8923802573064918954styled-by-prettify"><br></span><span style=3D"color:#80=
0" class=3D"m_8923802573064918954styled-by-prettify">//{ return __FUNCSIG__=
; }</span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-b=
y-prettify"><br></span><span style=3D"color:#008" class=3D"m_89238025730649=
18954styled-by-prettify">int</span><span style=3D"color:#000" class=3D"m_89=
23802573064918954styled-by-prettify"> main</span><span style=3D"color:#660"=
 class=3D"m_8923802573064918954styled-by-prettify">()</span><span style=3D"=
color:#000" class=3D"m_8923802573064918954styled-by-prettify"> </span><span=
 style=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify">{</=
span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660" class=3D"m_89=
23802573064918954styled-by-prettify">::</span><span style=3D"color:#000" cl=
ass=3D"m_8923802573064918954styled-by-prettify">cout </span><span style=3D"=
color:#660" class=3D"m_8923802573064918954styled-by-prettify">&lt;&lt;</spa=
n><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-pretti=
fy"> pretty</span><span style=3D"color:#660" class=3D"m_8923802573064918954=
styled-by-prettify">&lt;</span><span style=3D"color:#008" class=3D"m_892380=
2573064918954styled-by-prettify">float</span><span style=3D"color:#660" cla=
ss=3D"m_8923802573064918954styled-by-prettify">,</span><span style=3D"color=
:#000" class=3D"m_8923802573064918954styled-by-prettify"> std</span><span s=
tyle=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify">::</s=
pan><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-pret=
tify">pair</span><span style=3D"color:#660" class=3D"m_8923802573064918954s=
tyled-by-prettify">&gt;()</span><span style=3D"color:#000" class=3D"m_89238=
02573064918954styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_8923802573064918954styled-by-prettify">&lt;&lt;</span><span style=3D"=
color:#000" class=3D"m_8923802573064918954styled-by-prettify"> std</span><s=
pan style=3D"color:#660" class=3D"m_8923802573064918954styled-by-prettify">=
::</span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by=
-prettify">endl</span><span style=3D"color:#660" class=3D"m_892380257306491=
8954styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_89238=
02573064918954styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor:#800" class=3D"m_8923802573064918954styled-by-prettify">// =C2=A0 GCC:=
 const char* pretty(T&amp;&amp;) [with S =3D float; TT =3D std::pair; T =3D=
 std::pair&lt;float, float&gt;]</span><span style=3D"color:#000" class=3D"m=
_8923802573064918954styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color:#800" class=3D"m_8923802573064918954styled-by-prettify">// Clang=
: const char *pretty(T &amp;&amp;) [S =3D float, TT =3D std::pair, T =3D st=
d::__1::pair&lt;float, float&gt;]</span><span style=3D"color:#000" class=3D=
"m_8923802573064918954styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color:#800" class=3D"m_8923802573064918954styled-by-prettify">// =C2=
=A0MSVC: const char *__cdecl pretty&lt;float,struct std::pair,struct std::p=
air&lt;float,float&gt;&gt;(struct std::pair&lt;float,float&gt; &amp;&amp;)<=
/span><span style=3D"color:#000" class=3D"m_8923802573064918954styled-by-pr=
ettify"><br></span><span style=3D"color:#660" class=3D"m_892380257306491895=
4styled-by-prettify">}</span></div></code></div></div><div><br>I appreciate=
 most of the arguments against standardization so far, but I still see a un=
ique benefit to __PRETTY_FUNCTION__ in particular.<span style=3D"font-famil=
y:arial,sans-serif"> The fact that it maps template arguments to template p=
arameter names makes it much more valuable to anyone neck-deep in template =
metaprogramming. <span class=3D"m_8923802573064918954_username"><span class=
=3D"m_8923802573064918954F0XO1GC-D-a" style=3D"color:rgb(34,34,34)"></span>=
</span></span>My example is simple and uses brief but unhelpful parameter n=
ames, so imagine a complex, heterogeneous parameter list, but with reasonab=
ly descriptive parameter names instead.</div><div><br></div><div>My argumen=
t for standardization would be that all the major compilers found the need =
to represent the current function one way or another, other than the nearly=
 useless __func__; there&#39;s clearly enough demand for it, but without st=
andardization, every use requires sniffing for each compiler and its extens=
ions. (Every missed compiler, even those with a similar definition by anoth=
er name, is either unable to compile at all, or gets a partial build if the=
 default case shunts them around this section.) The standardization would n=
ot need to hammer out a specific format, as long as it specifies what infor=
mation must be represented. __PRETTY_FUNCTION__ represents more information=
 than the others, so ideally this information would be a part of the standa=
rd, but at least some representation of the signature seems reasonable, rig=
ht?</div><div><br></div><div>I agree about reflection, but I think it&#39;s=
 a separate concern, albeit tangentially related. We can have multiple conc=
erns. If I&#39;m mistaken, I&#39;d happily take an equivalent definition vi=
a reflection if it were compiler-agnostic, but I assume this isn&#39;t what=
 you intended, or this would just be a subset of what you&#39;d like anyway=
..<br></div><br>On Tuesday, November 1, 2016 at 6:33:46 AM UTC-4, D. B. wrot=
e:<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><div class=
=3D"gmail_quote">On Tue, Nov 1, 2016 at 8:10 AM, Jonathan M=C3=BCller <span=
 dir=3D"ltr">&lt;<a rel=3D"nofollow">jonathanm...@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span><br></span>
There is a `typename(type)` that returns a string proposed by some reflecti=
on proposal, isn&#39;t it?<span><br></span></blockquote><div><br></div><div=
>Yeah, no doubt all reflection proposals have a solution for this, and in a=
 much tidier way, so the &#39;get a type name&#39; argument doesn&#39;t hol=
d water to me. Done right, reflection would also better serve the &#39;get =
a function signature&#39; use case. I think it&#39;s more productive to pus=
h for reflection to be standardised, as it just keeps coming up, and it cou=
ld solve this as a consequence. Getting a modular reflection system in seem=
s more productive than arguing about exactly how a debug text string should=
 be formatted (to the level of arguing over the positioning of asterisks, a=
mpersands, etc.)<br><br>Maybe I&#39;m wrong and there&#39;s some key featur=
e of __PRETTY_FUNCTION__ that makes it uniquely desirable, which I might se=
e if the OP would actually substantiate the proposal and its context, inste=
ad of just asking for it to be added.<br></div></div></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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/c398c7ae-3490-457e-989c-9342bb9b580e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c398c7ae-3490-=
457e-989c-9342bb9b580e%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3haDvbud8f1dY9pU3-LDsq9wzUEHUXbN=
aviWnW%2Bi_8Q1ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDvbud8f=
1dY9pU3-LDsq9wzUEHUXbNaviWnW%2Bi_8Q1ww%40mail.gmail.com</a>.<br />

--000000000000017e5d056fdd1849--

.

------=_Part_22172_1739879699.1530370568585
Content-Type: multipart/alternative;
 boundary="----=_Part_22173_292507241.1530370568585"

------=_Part_22173_292507241.1530370568585
Content-Type: text/plain; charset="UTF-8"

On Saturday, June 30, 2018 at 10:51:06 AM UTC-4, Richard Hodges wrote:
>
> Wouldn't we prefer something like this?
>

That's just reflection. Which we can all agree ought to be able to do what
__PRETTY_FUNCTION__, only in a consistent way.

--
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/fe332e9c-0c72-43e2-858f-f513cd83c746%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, June 30, 2018 at 10:51:06 AM UTC-4, Richard H=
odges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
ouldn&#39;t we prefer something like this?</div></blockquote><div><br></div=
><div>That&#39;s just reflection. Which we can all agree ought to be able t=
o do what __PRETTY_FUNCTION__, only in a consistent way.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fe332e9c-0c72-43e2-858f-f513cd83c746%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe332e9c-0c72-43e2-858f-f513cd83c746=
%40isocpp.org</a>.<br />

------=_Part_22173_292507241.1530370568585--

------=_Part_22172_1739879699.1530370568585--

.

--00000000000082cf0e056fdfd2fa
Content-Type: text/plain; charset="UTF-8"

> That's just reflection

Which just about the most requested feature and the most frustrating
omission of the language.

On Sat, 30 Jun 2018 at 16:56, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, June 30, 2018 at 10:51:06 AM UTC-4, Richard Hodges wrote:
>>
>> Wouldn't we prefer something like this?
>>
>
> That's just reflection. Which we can all agree ought to be able to do what
> __PRETTY_FUNCTION__, only in a consistent way.
>
> --
> 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/fe332e9c-0c72-43e2-858f-f513cd83c746%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe332e9c-0c72-43e2-858f-f513cd83c746%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/CALvx3ha6XeJjTXKGcrsU9J-vBAeog23qEV6RZfduvWB_2V7tUA%40mail.gmail.com.

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

<div dir=3D"ltr">&gt; That&#39;s just reflection<div><br></div><div>Which j=
ust about the most requested feature and the most frustrating omission of t=
he language.</div><div><br></div><div><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Sat, 30 Jun 2018 at 16:56, Nicol Bolas &lt;<a href=3D"mailto:jm=
ckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">On Saturday, June 30, 2018 at 10:51:06 =
AM UTC-4, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">Wouldn&#39;t we prefer something like this?</div></blockquote>=
<div><br></div><div>That&#39;s just reflection. Which we can all agree ough=
t to be able to do what __PRETTY_FUNCTION__, only in a consistent way.<br><=
/div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/fe332e9c-0c72-43e2-858f-f513cd83c746%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe332e9c-0c72-=
43e2-858f-f513cd83c746%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha6XeJjTXKGcrsU9J-vBAeog23qEV6R=
ZfduvWB_2V7tUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha6XeJjTXKG=
crsU9J-vBAeog23qEV6RZfduvWB_2V7tUA%40mail.gmail.com</a>.<br />

--00000000000082cf0e056fdfd2fa--

.

------=_Part_24497_1401052774.1530392513076
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, 3 November 2016 10:42:09 UTC, Viacheslav Usov  wrote:
> On Tue, Nov 1, 2016 at 7:01 AM,  <ant...@perezexcelsior.com> wrote:
>=20
>=20
> > Currently, __func__ is part of the c++ standard, however __PRETTY_FUNCT=
ION__ (part of GCC and Clang) provides significantly more information about=
 a function. It's more useful for printing debugging information and error =
messages, and in addition it provides a method for getting the programmatic=
 name of a type.
>=20
>=20
> C++ has no way to refer to the current function. That is why we use __fun=
c__ and __PRETTY_FUNCTION__ to refer to some=C2=A0information on the curren=
t function. That may also be why we keep seeing proposals "let's standardis=
e this way of getting stack traces".
>=20

Perhaps it's something of a hack, but it's trivial to declare and refer to =
a local class:

    typeid(struct tag)=20

Demangling the name of that type, whether through reflection or through a s=
topgap solution, would I think be more generally useful than standardising =
a macro.=20

>=20
> I'd rather have the real problem fixed than more hacks standardised.
>=20
>=20
>=20
> Cheers,
> V.

--=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/94ccb3a4-f044-49f7-affd-336b0a97b757%40isocpp.or=
g.

------=_Part_24497_1401052774.1530392513076--

.

--000000000000d98fd7056ff943d2
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 30, 2018 at 11:06 AM Richard Hodges <hodges.r@gmail.com> wrote:

> > That's just reflection
>
> Which just about the most requested feature and the most frustrating
> omission of the language.
>

I believe a Reflection TS is in the works.

--
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/CAB%2B4KHKTNf1jy-y1SG3R4AazwpA3b9_KwEqkQurrR6FZ5uiFng%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Jun 30=
, 2018 at 11:06 AM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com"=
>hodges.r@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">&gt; That&#39;s just reflection<div><br></div><div>Which j=
ust about the most requested feature and the most frustrating omission of t=
he language.</div></div></blockquote><div><br></div><div>I believe a Reflec=
tion TS is in the works.</div><div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKTNf1jy-y1SG3R4AazwpA3b9_KwE=
qkQurrR6FZ5uiFng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKTNf1j=
y-y1SG3R4AazwpA3b9_KwEqkQurrR6FZ5uiFng%40mail.gmail.com</a>.<br />

--000000000000d98fd7056ff943d2--

.