Tap the shoulder of the person moderating the Boost dev list

[Frederick Gotham]

I posted my idea for a "static allocator" to the Boost dev mailing list 2 days ago. It's a moderated list and so I'd expect a delay in my posts showing up. Not two days though.

If any of you know who is moderating the Boost dev list, could you please tap them on the shoulder.

There was a long delay when I posted by last idea too for a limited input iterator.

(Also unrelatedly I posted to comp.std.c++ two days ago to tell them to put __COUNTER__ in the standard but again it hasn't shown up yet -- so if anyone knows that moderator then please tap them on the shoulder)

[Alf P. Steinbach]

On 09.01.2020 08:49, Frederick Gotham wrote:
>
> I posted my idea for a "static allocator" to the Boost dev mailing list 2 days ago. It's a moderated list and so I'd expect a delay in my posts showing up. Not two days though.
>
> If any of you know who is moderating the Boost dev list, could you please tap them on the shoulder.

He's not the maintainer, but in the worst case where this continues
contact Dave Abrahams, one of the two original founders of Boost.

> There was a long delay when I posted by last idea too for a limited input iterator.
>
> (Also unrelatedly I posted to comp.std.c++ two days ago to tell them to put __COUNTER__ in the standard but again it hasn't shown up yet -- so if anyone knows that moderator then please tap them on the shoulder)

comp.std.c++ is long dead.

After that the discussion moved to a couple of Google Group groups.

Now, a few months ago, it's moved again, to a couple of mailing lists.
See <url: https://isocpp.org> for details.


- Alf

[Frederick Gotham]

On Thursday, January 9, 2020 at 11:09:11 AM UTC, Alf P. Steinbach wrote:

> He's not the maintainer, but in the worst case where this continues
> contact Dave Abrahams, one of the two original founders of Boost.

I fired an email to David, Beman and Nicolai.


> comp.std.c++ is long dead.


Nostalgic anecdote: I remember when I was teenager posting to that group as I found an error in the 1998 Standard.

> After that the discussion moved to a couple of Google Group groups.
>
> Now, a few months ago, it's moved again, to a couple of mailing lists.
> See <url: https://isocpp.org> for details.

I'll take a look. Also I think two of three guys named above are on the Standards Committee. The preprocessor macros __COUNTER__ should really be in the standard.

[Paavo Helde]

On 9.01.2020 14:24, Frederick Gotham wrote:
>
> The preprocessor macros __COUNTER__ should really be in the standard.

If __COUNTER__ is used in header files, then it might easily produce
different values for the same usage point if headers are included in a
different order in different compilation units. This in turn may easily
violate ODR rules and produce other nasty bugs. This is especially
relevant for C++ where the tendency is to put yet more and more stuff in
the header files.

I believe we don't need yet another readily abusable misfeature in C++.

[David Brown]

Lots of features can be abused as well as used.

__COUNTER__ can be useful when you want an identifier within a macro
that must be different from any other identifier each time the macro is
invoked. But you should never depend on what the actual value is.

An example of where I have used it is for a "static_assert" macro for
pre-C11 or pre-C++11. Clearly this is no longer needed for modern
language standards, but it is very useful for C99 coding:

#define STATIC_ASSERT_NAME_(count) STATIC_ASSERT_NAME2_(count)
#define STATIC_ASSERT_NAME2_(count) assertion_failed_at_line_##count
#define static_assert(claim, warning) \
typedef struct { \
char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 1 : -1]; \
} STATIC_ASSERT_NAME_(__COUNTER__)


This lets you write, for example:

static_assert(sizeof(int) == 4, "Code assumes 4-byte int");

You can put it outside or inside functions, and no code is generated and
no code is wasted.


The alternative to __COUNTER__ is __LINE__. I used to use that, but if
you coincidentally have static_assert's at the same line number in two
headers (or a header and the C or C++ file) used in the same
compilation, you get a collision. __COUNTER__ avoids that.


Does this mean it would be nice to see __COUNTER__ standardised? Well,
there would be no point in doing it for this use-case. Maybe there are
other use-cases that benefit from it, where there are similar advantages
over __LINE__. I don't think there are many new possibilities for
errors or bad code that it would open up, compared to using the current
standard alternative of __LINE__.

(I have no idea what use Frederick has for __COUNTER__.)

[Jorgen Grahn]

On Thu, 2020-01-09, David Brown wrote:
> On 09/01/2020 14:01, Paavo Helde wrote:
>> On 9.01.2020 14:24, Frederick Gotham wrote:
>>>
>>> The preprocessor macros __COUNTER__ should really be in the standard.
>>
>> If __COUNTER__ is used in header files, then it might easily produce
>> different values for the same usage point if headers are included in a

...

>
> (I have no idea what use Frederick has for __COUNTER__.)

Presumably his proposal makes that clear; maybe he can repost it here?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Paavo Helde]

If you have this inside an inlined function in an header, then you
already may have violated the ODR if the inline function definition
happens to not consist of the same sequence of tokens in all TU-s.

Most probably the program still behaves as you would expect, but
formally you have UB.

[David Brown]

Good point.

As the declared struct is never used, it is unlikely to have any effect
- but you are right that it would technically be UB (unless, of course,
__COUNTER__ happens to match in all cases where the function is declared).

Another reason to use C11 or C++11 or greater!

[Cholo Lennon]

If you use slack, workspace "Cpplang" (cpplang.slack.com), channels
"boost" (or "general"), for sure you will get some kind of answer.

--
Cholo Lennon
Bs.As.
ARG

[Manfred]

Agreed.

1) It is a (predefined) macro. Wherever macros are going, C++ is going
the other way.

2) The way I see it, it may be useful mostly for debugging or early
development. So not really needed to release products.