------=_Part_102548_978908373.1531088432908
Content-Type: multipart/alternative;
 boundary="----=_Part_102549_937995187.1531088432909"

------=_Part_102549_937995187.1531088432909
Content-Type: text/plain; charset="UTF-8"

We have a __LINE__ macro which expands to the source file line number. Why
not also have __COLUMN__ which expands to the column number?

There are some cases where a unique identifier is desirable, such as
SCOPE_EXIT. Currently, this identifier has to be generated either by
__LINE__ or by __COUNTER__, but both have drawbacks: __LINE__ means you
can't define two on the same line and __COUNTER__ is a recipe for ODR
violations when used in inline functions in header files. Regardless,
people do use these:

#define CONCAT_IMPL(A, B) A ## B
#define CONCAT(A, B) CONCAT_IMPL(A, B)

#define UNIQUE_NAME CONCAT(some_prefix_, __LINE__)
// or
#define UNIQUE_NAME CONCAT(some_prefix_, __COUNTER__)

A __COLUMN__ macro would make unique identifiers possible with none of the
drawbacks of __LINE__ or __COUNTER__:

// Given a ternary preprocessor CONCAT
#define UNIQUE_NAME CONCAT(some_prefix_, __LINE__, __COLUMN__)

I know about std::experimental::source_location, but it's not a macro, so
it can't do this.

--
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/29394898-f878-45ad-b21c-b589e4a36caf%40isocpp.org.

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

<div dir=3D"ltr">We have a __LINE__ macro which expands to the source file =
line number. Why not also have __COLUMN__ which expands to the column numbe=
r?<div><br></div><div>There are some cases where a unique identifier is des=
irable, such as SCOPE_EXIT. Currently, this identifier has to be generated =
either by __LINE__ or by __COUNTER__, but both have drawbacks: __LINE__ mea=
ns you can&#39;t define two on the same line and __COUNTER__ is a recipe fo=
r ODR violations when used in inline functions in header files. Regardless,=
 people do use these:<br><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><div style=3D"color: #000=
000;background-color: #fffffe;font-family: Consolas, " liberation=3D"" mono=
",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14=
px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D""><div><span style=3D"=
color: #0000ff;"><span style=3D"color: #800;" class=3D"styled-by-prettify">=
#define</span></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: rgb(136, 0, 0); background-color: rgb(250=
, 250, 250);"><span style=3D"color: #000;" class=3D"styled-by-prettify">CON=
CAT_IMPL</span></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">A</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> A </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">## B</span></div><div><span style=3D"color: =
#0000ff;"><span style=3D"color: #800;" class=3D"styled-by-prettify">#define=
</span></span><span style=3D"color: #800;" class=3D"styled-by-prettify"> </=
span><span style=3D"background-color: rgb(250, 250, 250);"><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">CONCAT</span></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">(A, B) </span><span style=3D=
"color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);"><span style=3D=
"color: #800;" class=3D"styled-by-prettify">CONCAT_IMPL</span></span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">(A, B)</span></div></di=
v><font color=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></font><div style=3D"color: #000000;background-color: #=
fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" m=
onospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19=
px;white-space:=3D"" pre;"=3D""><span style=3D"color: #0000ff;"><span style=
=3D"color: #800;" class=3D"styled-by-prettify">#define</span></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> UNIQUE_NAME </span><spa=
n style=3D"color: rgb(136, 0, 0); background-color: rgb(250, 250, 250);"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">CONCAT</span></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">some_prefix_</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> __LINE__</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">// or</span></div><font color=3D"#660066"><span =
style=3D"color: #800;" class=3D"styled-by-prettify">#define UNIQUE_NAME</sp=
an></font><span style=3D"color: #800;" class=3D"styled-by-prettify"> CONCAT=
(some_prefix_, __COUNTER__)</span></div></code></div><br>A __COLUMN__ macro=
 would make unique identifiers possible with none of the drawbacks of __LIN=
E__ or __COUNTER__:</div><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// Given a ternary=
 preprocessor CONCAT</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">#define</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> UNIQUE_NAME </span></font><span style=3D"color: rgb(136, 0, 0);"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">CONCAT</span></span><font=
 color=3D"#660066"><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">some_pr=
efix_</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> __LINE__</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> __COLUMN__</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span></font></div></=
code></div></div><div><br></div><div>I know about std::experimental::source=
_location, but it&#39;s not a macro, so it can&#39;t do this.</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/29394898-f878-45ad-b21c-b589e4a36caf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/29394898-f878-45ad-b21c-b589e4a36caf=
%40isocpp.org</a>.<br />

------=_Part_102549_937995187.1531088432909--

------=_Part_102548_978908373.1531088432908--

.

------=_Part_104193_715833981.1531106224596
Content-Type: multipart/alternative;
 boundary="----=_Part_104194_531447248.1531106224596"

------=_Part_104194_531447248.1531106224596
Content-Type: text/plain; charset="UTF-8"

On Sunday, July 8, 2018 at 6:20:33 PM UTC-4, Justin Bassett wrote:
>
> We have a __LINE__ macro which expands to the source file line number. Why
> not also have __COLUMN__ which expands to the column number?
>
> There are some cases where a unique identifier is desirable,
>

Or we could just allow people to declare anonymous variables. It's a
language change either way; better to have the change that obsoletes a
(small) class of macro usage.

--
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/228dda03-af94-47b5-a993-673032e86092%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 8, 2018 at 6:20:33 PM UTC-4, Justin Basset=
t 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">We ha=
ve a __LINE__ macro which expands to the source file line number. Why not a=
lso have __COLUMN__ which expands to the column number?<div><br></div><div>=
There are some cases where a unique identifier is desirable,</div></div></b=
lockquote><div><br></div><div>Or we could just allow people to declare anon=
ymous variables. It&#39;s a language change either way; better to have the =
change that obsoletes a (small) class of macro usage.</div><br></div>

<p></p>

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

------=_Part_104194_531447248.1531106224596--

------=_Part_104193_715833981.1531106224596--

.

------=_Part_12402_157338932.1531175784720
Content-Type: multipart/alternative;
 boundary="----=_Part_12403_656073611.1531175784721"

------=_Part_12403_656073611.1531175784721
Content-Type: text/plain; charset="UTF-8"



On Monday, July 9, 2018 at 12:20:33 AM UTC+2, Justin Bassett wrote:
>
> We have a __LINE__ macro which expands to the source file line number. Why
> not also have __COLUMN__ which expands to the column number?
>
> There are some cases where a unique identifier is desirable, such as
> SCOPE_EXIT. Currently, this identifier has to be generated either by
> __LINE__ or by __COUNTER__, but both have drawbacks: __LINE__ means you
> can't define two on the same line and __COUNTER__ is a recipe for ODR
> violations when used in inline functions in header files. Regardless,
> people do use these:
>
> #define CONCAT_IMPL(A, B) A ## B
> #define CONCAT(A, B) CONCAT_IMPL(A, B)
>
> #define UNIQUE_NAME CONCAT(some_prefix_, __LINE__)
> // or
> #define UNIQUE_NAME CONCAT(some_prefix_, __COUNTER__)
>
> A __COLUMN__ macro would make unique identifiers possible with none of the
> drawbacks of __LINE__ or __COUNTER__:
>
> // Given a ternary preprocessor CONCAT
> #define UNIQUE_NAME CONCAT(some_prefix_, __LINE__, __COLUMN__)
>
> I know about std::experimental::source_location, but it's not a macro, so
> it can't do this.
>
I believe that we should be able to do something like this once we have
reflection:

constexpr! std::fixed_string current_column_string() { return std::
to_fixed_string(std::source_location::current().column()); }
int unreflexpr_id("some_prefix_" + current_column_string());

Would be much cleaner I believe.
Either way tracking the column number would require significant changes to
GCC that they haven't been willing to do so far even though they have
source_location implemented (currently returning 0).

I also agree that allowing anonymous variables would better solution and
would even be simpler to implement seeing how most compilers already have
ways to produce anonymous names. We would just need to find some syntax or
keyword.

--
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/7b15114a-7a79-4407-8937-bb8d3d6df7f7%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, July 9, 2018 at 12:20:33 AM UTC+2, Just=
in Bassett 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">We have a __LINE__ macro which expands to the source file line number. =
Why not also have __COLUMN__ which expands to the column number?<div><br></=
div><div>There are some cases where a unique identifier is desirable, such =
as SCOPE_EXIT. Currently, this identifier has to be generated either by __L=
INE__ or by __COUNTER__, but both have drawbacks: __LINE__ means you can&#3=
9;t define two on the same line and __COUNTER__ is a recipe for ODR violati=
ons when used in inline functions in header files. Regardless, people do us=
e these:<br><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;word=
-wrap:break-word"><code><div><div><div><span style=3D"color:#0000ff"><span =
style=3D"color:#800">#define</span></span><span style=3D"color:#000"> </spa=
n><span style=3D"color:rgb(136,0,0);background-color:rgb(250,250,250)"><spa=
n style=3D"color:#000">CONCAT_IMPL</span></span><span style=3D"color:#660">=
(</span><span style=3D"color:#000">A</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> B</span><span style=3D"color:#660">)</span><=
span style=3D"color:#000"> A </span><span style=3D"color:#800">## B</span><=
/div><div><span style=3D"color:#0000ff"><span style=3D"color:#800">#define<=
/span></span><span style=3D"color:#800"> </span><span style=3D"background-c=
olor:rgb(250,250,250)"><span style=3D"color:#800">CONCAT</span></span><span=
 style=3D"color:#800">(A, B) </span><span style=3D"color:rgb(0,0,0);backgro=
und-color:rgb(250,250,250)"><span style=3D"color:#800">CONCAT_IMPL</span></=
span><span style=3D"color:#800">(A, B)</span></div></div><font color=3D"#66=
0066"><span style=3D"color:#000"><br></span></font><div><span style=3D"colo=
r:#0000ff"><span style=3D"color:#800">#define</span></span><span style=3D"c=
olor:#000"> UNIQUE_NAME </span><span style=3D"color:rgb(136,0,0);background=
-color:rgb(250,250,250)"><span style=3D"color:#000">CONCAT</span></span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">some_prefix_</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> __LINE__<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#800">// or</span></div><font color=3D"#660066"><s=
pan style=3D"color:#800">#define UNIQUE_NAME</span></font><span style=3D"co=
lor:#800"> CONCAT(some_prefix_, __COUNTER__)</span></div></code></div><br>A=
 __COLUMN__ macro would make unique identifiers possible with none of the d=
rawbacks of __LINE__ or __COUNTER__:</div><div><br></div><div><div style=3D=
"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-sty=
le:solid;border-width:1px;word-wrap:break-word"><code><div><font color=3D"#=
660066"><span style=3D"color:#800">// Given a ternary preprocessor CONCAT</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#800">#defi=
ne</span><span style=3D"color:#000"> UNIQUE_NAME </span></font><span style=
=3D"color:rgb(136,0,0)"><span style=3D"color:#000">CONCAT</span></span><fon=
t color=3D"#660066"><span style=3D"color:#660">(</span><span style=3D"color=
:#000">some_prefix_</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> __LINE__</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> __COLUMN__</span><span style=3D"color:#660">)</span></font=
></div></code></div></div><div><br></div><div>I know about std::experimenta=
l::source_<wbr>location, but it&#39;s not a macro, so it can&#39;t do this.=
</div></div></div></blockquote><div>I believe that we should be able to do =
something like this once we have reflection:</div><div><br></div><div><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">!</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">fixed_string current_column_string</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #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">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">to_fixed_string</span><font color=3D"#666600"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span></font><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">source_location</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">current</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">().</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">column</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">());</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> unreflexpr_id</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">&quot;some_prefix_&quot;</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"> current_column_string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">());</span></div></code></div><d=
iv><br></div><div>Would be much cleaner I believe.</div><div>Either way tra=
cking the column number would require significant changes to GCC that they =
haven&#39;t been willing to do so far even though they have source_location=
 implemented (currently returning 0).</div></div><div><br></div><div>I also=
 agree that allowing anonymous variables would better solution and would ev=
en be simpler to implement seeing how most compilers already have ways to p=
roduce anonymous names. We would just need to find some syntax or keyword.<=
/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/7b15114a-7a79-4407-8937-bb8d3d6df7f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b15114a-7a79-4407-8937-bb8d3d6df7f7=
%40isocpp.org</a>.<br />

------=_Part_12403_656073611.1531175784721--

------=_Part_12402_157338932.1531175784720--

.

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

This entire thread is daft.

Which column of the 10 columns taken up by the macro (or identifier)
__COLUMN__ should the macro __COLUMN__ evaluate to?

Words are written left to write (in english and c++). They occupy 1 line
and several columns.

If they were written in kanji, a __COLUMN__ would make sense and a __LINE__
would not.



On Tue, 10 Jul 2018 at 00:36, <bastienpenava@gmail.com> wrote:

>
>
> On Monday, July 9, 2018 at 12:20:33 AM UTC+2, Justin Bassett wrote:
>>
>> We have a __LINE__ macro which expands to the source file line number.
>> Why not also have __COLUMN__ which expands to the column number?
>>
>> There are some cases where a unique identifier is desirable, such as
>> SCOPE_EXIT. Currently, this identifier has to be generated either by
>> __LINE__ or by __COUNTER__, but both have drawbacks: __LINE__ means you
>> can't define two on the same line and __COUNTER__ is a recipe for ODR
>> violations when used in inline functions in header files. Regardless,
>> people do use these:
>>
>> #define CONCAT_IMPL(A, B) A ## B
>> #define CONCAT(A, B) CONCAT_IMPL(A, B)
>>
>> #define UNIQUE_NAME CONCAT(some_prefix_, __LINE__)
>> // or
>> #define UNIQUE_NAME CONCAT(some_prefix_, __COUNTER__)
>>
>> A __COLUMN__ macro would make unique identifiers possible with none of
>> the drawbacks of __LINE__ or __COUNTER__:
>>
>> // Given a ternary preprocessor CONCAT
>> #define UNIQUE_NAME CONCAT(some_prefix_, __LINE__, __COLUMN__)
>>
>> I know about std::experimental::source_location, but it's not a macro, so
>> it can't do this.
>>
> I believe that we should be able to do something like this once we have
> reflection:
>
> constexpr! std::fixed_string current_column_string() { return std::
> to_fixed_string(std::source_location::current().column()); }
> int unreflexpr_id("some_prefix_" + current_column_string());
>
> Would be much cleaner I believe.
> Either way tracking the column number would require significant changes to
> GCC that they haven't been willing to do so far even though they have
> source_location implemented (currently returning 0).
>
> I also agree that allowing anonymous variables would better solution and
> would even be simpler to implement seeing how most compilers already have
> ways to produce anonymous names. We would just need to find some syntax or
> keyword.
>
> --
> 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/7b15114a-7a79-4407-8937-bb8d3d6df7f7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b15114a-7a79-4407-8937-bb8d3d6df7f7%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/CALvx3hb54SH%3DONsWzuJpveELPNck2rqXMFQN4XhG2nRuX2dvUw%40mail.gmail.com.

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

<div dir=3D"ltr">This entire thread is daft.<div><br></div><div>Which colum=
n of the 10 columns taken up by the macro (or identifier) <font face=3D"mon=
ospace, monospace">__COLUMN__</font> should the macro <font face=3D"monospa=
ce, monospace">__COLUMN__</font> evaluate to?</div><div><br></div><div>Word=
s are written left to write (in english and c++). They occupy 1 line and se=
veral columns.=C2=A0</div><div><br></div><div>If they were written in kanji=
, a <font face=3D"monospace, monospace">__COLUMN__</font> would make sense =
and a <font face=3D"monospace, monospace">__LINE__</font> would not.</div><=
div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, 10 Jul 2018 at 00:36, &lt;<a href=3D"mailto:bastienpenava@=
gmail.com">bastienpenava@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, July 9, 2018 at 12:20:33=
 AM UTC+2, Justin Bassett wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">We have a __LINE__ macro which expands to the source file lin=
e number. Why not also have __COLUMN__ which expands to the column number?<=
div><br></div><div>There are some cases where a unique identifier is desira=
ble, such as SCOPE_EXIT. Currently, this identifier has to be generated eit=
her by __LINE__ or by __COUNTER__, but both have drawbacks: __LINE__ means =
you can&#39;t define two on the same line and __COUNTER__ is a recipe for O=
DR violations when used in inline functions in header files. Regardless, pe=
ople do use these:<br><div><br></div><div><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code><div><div><div><span style=3D"color:#0000=
ff"><span style=3D"color:#800">#define</span></span><span style=3D"color:#0=
00"> </span><span style=3D"color:rgb(136,0,0);background-color:rgb(250,250,=
250)"><span style=3D"color:#000">CONCAT_IMPL</span></span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">A</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> B</span><span style=3D"color:#660"=
>)</span><span style=3D"color:#000"> A </span><span style=3D"color:#800">##=
 B</span></div><div><span style=3D"color:#0000ff"><span style=3D"color:#800=
">#define</span></span><span style=3D"color:#800"> </span><span style=3D"ba=
ckground-color:rgb(250,250,250)"><span style=3D"color:#800">CONCAT</span></=
span><span style=3D"color:#800">(A, B) </span><span style=3D"color:rgb(0,0,=
0);background-color:rgb(250,250,250)"><span style=3D"color:#800">CONCAT_IMP=
L</span></span><span style=3D"color:#800">(A, B)</span></div></div><font co=
lor=3D"#660066"><span style=3D"color:#000"><br></span></font><div><span sty=
le=3D"color:#0000ff"><span style=3D"color:#800">#define</span></span><span =
style=3D"color:#000"> UNIQUE_NAME </span><span style=3D"color:rgb(136,0,0);=
background-color:rgb(250,250,250)"><span style=3D"color:#000">CONCAT</span>=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">some_p=
refix_</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
 __LINE__</span><span style=3D"color:#660">)</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#800">// or</span></div><font color=3D"#=
660066"><span style=3D"color:#800">#define UNIQUE_NAME</span></font><span s=
tyle=3D"color:#800"> CONCAT(some_prefix_, __COUNTER__)</span></div></code><=
/div><br>A __COLUMN__ macro would make unique identifiers possible with non=
e of the drawbacks of __LINE__ or __COUNTER__:</div><div><br></div><div><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><font =
color=3D"#660066"><span style=3D"color:#800">// Given a ternary preprocesso=
r CONCAT</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
800">#define</span><span style=3D"color:#000"> UNIQUE_NAME </span></font><s=
pan style=3D"color:rgb(136,0,0)"><span style=3D"color:#000">CONCAT</span></=
span><font color=3D"#660066"><span style=3D"color:#660">(</span><span style=
=3D"color:#000">some_prefix_</span><span style=3D"color:#660">,</span><span=
 style=3D"color:#000"> __LINE__</span><span style=3D"color:#660">,</span><s=
pan style=3D"color:#000"> __COLUMN__</span><span style=3D"color:#660">)</sp=
an></font></div></code></div></div><div><br></div><div>I know about std::ex=
perimental::source_location, but it&#39;s not a macro, so it can&#39;t do t=
his.</div></div></div></blockquote><div>I believe that we should be able to=
 do something like this once we have reflection:</div><div><br></div><div><=
div class=3D"m_9073357245542908367prettyprint" style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code class=3D"m_9073357245542908367prettyprint=
"><div class=3D"m_9073357245542908367subprettyprint"><span style=3D"color:#=
008" class=3D"m_9073357245542908367styled-by-prettify">constexpr</span><spa=
n style=3D"color:#660" class=3D"m_9073357245542908367styled-by-prettify">!<=
/span><span style=3D"color:#000" class=3D"m_9073357245542908367styled-by-pr=
ettify"> std</span><span style=3D"color:#660" class=3D"m_907335724554290836=
7styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_9073357=
245542908367styled-by-prettify">fixed_string current_column_string</span><s=
pan style=3D"color:#660" class=3D"m_9073357245542908367styled-by-prettify">=
()</span><span style=3D"color:#000" class=3D"m_9073357245542908367styled-by=
-prettify"> </span><span style=3D"color:#660" class=3D"m_907335724554290836=
7styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_90733572=
45542908367styled-by-prettify"> </span><span style=3D"color:#008" class=3D"=
m_9073357245542908367styled-by-prettify">return</span><span style=3D"color:=
#000" class=3D"m_9073357245542908367styled-by-prettify"> std</span><span st=
yle=3D"color:#660" class=3D"m_9073357245542908367styled-by-prettify">::</sp=
an><span style=3D"color:#000" class=3D"m_9073357245542908367styled-by-prett=
ify">to_fixed_string</span><font color=3D"#666600"><span style=3D"color:#66=
0" class=3D"m_9073357245542908367styled-by-prettify">(</span></font><span s=
tyle=3D"color:#000" class=3D"m_9073357245542908367styled-by-prettify">std</=
span><span style=3D"color:#660" class=3D"m_9073357245542908367styled-by-pre=
ttify">::</span><span style=3D"color:#000" class=3D"m_9073357245542908367st=
yled-by-prettify">source_location</span><span style=3D"color:#660" class=3D=
"m_9073357245542908367styled-by-prettify">::</span><span style=3D"color:#00=
0" class=3D"m_9073357245542908367styled-by-prettify">current</span><span st=
yle=3D"color:#660" class=3D"m_9073357245542908367styled-by-prettify">().</s=
pan><span style=3D"color:#000" class=3D"m_9073357245542908367styled-by-pret=
tify">column</span><span style=3D"color:#660" class=3D"m_907335724554290836=
7styled-by-prettify">());</span><span style=3D"color:#000" class=3D"m_90733=
57245542908367styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_9073357245542908367styled-by-prettify">}</span><span style=3D"color:#=
000" class=3D"m_9073357245542908367styled-by-prettify"><br></span><span sty=
le=3D"color:#008" class=3D"m_9073357245542908367styled-by-prettify">int</sp=
an><span style=3D"color:#000" class=3D"m_9073357245542908367styled-by-prett=
ify"> unreflexpr_id</span><span style=3D"color:#660" class=3D"m_90733572455=
42908367styled-by-prettify">(</span><span style=3D"color:#080" class=3D"m_9=
073357245542908367styled-by-prettify">&quot;some_prefix_&quot;</span><span =
style=3D"color:#000" class=3D"m_9073357245542908367styled-by-prettify"> </s=
pan><span style=3D"color:#660" class=3D"m_9073357245542908367styled-by-pret=
tify">+</span><span style=3D"color:#000" class=3D"m_9073357245542908367styl=
ed-by-prettify"> current_column_string</span><span style=3D"color:#660" cla=
ss=3D"m_9073357245542908367styled-by-prettify">());</span></div></code></di=
v><div><br></div><div>Would be much cleaner I believe.</div><div>Either way=
 tracking the column number would require significant changes to GCC that t=
hey haven&#39;t been willing to do so far even though they have source_loca=
tion implemented (currently returning 0).</div></div><div><br></div><div>I =
also agree that allowing anonymous variables would better solution and woul=
d even be simpler to implement seeing how most compilers already have ways =
to produce anonymous names. We would just need to find some syntax or keywo=
rd.</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/7b15114a-7a79-4407-8937-bb8d3d6df7f7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b15114a-7a79-=
4407-8937-bb8d3d6df7f7%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/CALvx3hb54SH%3DONsWzuJpveELPNck2rqXMF=
QN4XhG2nRuX2dvUw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb54SH%3D=
ONsWzuJpveELPNck2rqXMFQN4XhG2nRuX2dvUw%40mail.gmail.com</a>.<br />

--000000000000c76ee7057098f0b8--

.

--00000000000097f858057098febc
Content-Type: text/plain; charset="UTF-8"

I thought this would potentially be easier to get through than reflection
and anonymous variables. But it appears not.

Either way tracking the column number would require significant changes to
> GCC that they haven't been willing to do so far even though they have
> source_location implemented (currently returning 0).
>

That definitely settles this for me. I feel no need to push this idea
further.

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

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

<div dir=3D"auto"><div>I thought this would potentially be easier to get th=
rough than reflection and anonymous variables. But it appears not.</div><di=
v dir=3D"auto"><br><div class=3D"gmail_quote" dir=3D"auto"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Either way tracking the column number =
would require significant changes to GCC that they haven&#39;t been willing=
 to do so far even though they have source_location implemented (currently =
returning 0).<br></div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"></div><div dir=3D"auto">That definitely settles th=
is for me. I feel no need to push this idea further.</div><div dir=3D"auto"=
><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/CAPuuy5f1678OKwDdFKV7N2c7RqF1usPDiw7Q=
QXdsBneLfuu05g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5f1678OKwDd=
FKV7N2c7RqF1usPDiw7QQXdsBneLfuu05g%40mail.gmail.com</a>.<br />

--00000000000097f858057098febc--

.

On 10 July 2018 at 02:01, Justin Bassett <jbassett271@gmail.com> wrote:
>> Either way tracking the column number would require significant changes to
>> GCC that they haven't been willing to do so far even though they have
>> source_location implemented (currently returning 0).
>
>
> That definitely settles this for me. I feel no need to push this idea
> further.

You shouldn't be so quick to make decisions based on unsubstantiated
claims about what developers
of a certain implementation might or might not be willing to do.

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

.

------=_Part_122464_297903427.1531262891755
Content-Type: multipart/alternative;
 boundary="----=_Part_122465_1606199565.1531262891755"

------=_Part_122465_1606199565.1531262891755
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 10, 2018 at 1:01:34 AM UTC+2, Justin Bassett wrote:
>
> I thought this would potentially be easier to get through than reflection
> and anonymous variables. But it appears not.
>
> Either way tracking the column number would require significant changes to
>> GCC that they haven't been willing to do so far even though they have
>> source_location implemented (currently returning 0).
>>
>
> That definitely settles this for me. I feel no need to push this idea
> further.
>
> Hi,

I'd like to apologize for my remark, I was actually wrong about it
requiring "significant change".
It requires so much change that I have made fairly quickly a functioning
implementation and put it on a compiler explorer here:
 http://column.gcc-future.tk/# <http://column.gcc-future.tk/#>
I've also managed to make source_location return a "better value",
the only issue being that the newly created __builtin_COLUMN function
returns the location of the opening parenthesis of the function call
instead of the beginning of the function name.
From what I've seen the implementation of source_location was just a patch
submitted in 2015 that was later (2017) published as is and was only a
library patch.
That was mostly the point of my comment (little interest shown by the GCC
team).

--
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/3dd6733f-b195-40a7-9ee8-4d49717c686f%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 10, 2018 at 1:01:34 AM UTC+2, Justin Bass=
ett 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"auto"><d=
iv>I thought this would potentially be easier to get through than reflectio=
n and anonymous variables. But it appears not.</div><div dir=3D"auto"><br><=
div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>Either way tracking the column number would require signif=
icant changes to GCC that they haven&#39;t been willing to do so far even t=
hough they have source_location implemented (currently returning 0).<br></d=
iv></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"></div><div dir=3D"auto">That definitely settles this for me. I feel no=
 need to push this idea further.</div><div dir=3D"auto"><br></div></div></b=
lockquote><div>Hi,</div><div><br></div><div>I&#39;d like to apologize for m=
y remark, I was actually wrong about it requiring &quot;significant change&=
quot;.</div><div>It requires so much change that I have made fairly quickly=
 a functioning implementation and put it on a compiler explorer here:<a hre=
f=3D"http://column.gcc-future.tk/#">=C2=A0http://column.gcc-future.tk/#</a>=
</div><div>I&#39;ve also managed to make source_location return a &quot;bet=
ter value&quot;,</div><div>the only issue being that the newly created __bu=
iltin_COLUMN function returns the location of the opening parenthesis of th=
e function call instead of the beginning of the function name.<br></div><di=
v>From what I&#39;ve seen the implementation of source_location was just a =
patch submitted in 2015 that was later (2017) published as is and was only =
a library patch.</div><div>That was mostly the point of my comment (little =
interest shown by the GCC team).</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/3dd6733f-b195-40a7-9ee8-4d49717c686f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3dd6733f-b195-40a7-9ee8-4d49717c686f=
%40isocpp.org</a>.<br />

------=_Part_122465_1606199565.1531262891755--

------=_Part_122464_297903427.1531262891755--

.