__COLUMN__ macro to parallel __LINE__

[Justin Bassett]

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.

[Nicol Bolas]

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.

[bastie...@gmail.com]

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.

[Richard Hodges]

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.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@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.

[Justin Bassett]

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.

[Ville Voutilainen]

On 10 July 2018 at 02:01, Justin Bassett <jbass...@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.

[bastie...@gmail.com]

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/#

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).