IMHO I see this feature implemented as part of the Reflection proposals.

So you could get facilities to list the defined entities of specific scopes.

You can use/write constexpr compile-time functions to parse their names and test for a specific prefix like 'stage' and return them as array of references to the variables.


As metaprogramming itself takes more time, you would take the constexpr result and store them as std::array member variable and access them with loops.


This would only work, if the future reflection proposals are powerful enough to list the variables for one scope or recursively and only if you can access their names and get references to them in a constexpr context.


The last bit may be the most farfetched for the first iteration (hopefully C++23).



[Another currently in parts available option for your specific usage could be the preprocessor (e.g. Boost preprocessor).]




-----Ursprüngliche Nachricht-----
Von: Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Sa 22.10.2022 21:24
Betreff: [std-proposals] operator __available initialises array with visible variables
An: std-proposals <std-proposals@lists.isocpp.org>;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
I propose that the following:

unsigned stage1;
unsigned stage2;
unsigned stage3;
unsigned stage5;

namespace SomeNameSpace {

   unsigned stage2;

   void Func(void)
       unsigned stage3;

       unsigned *const stage[] = __available(stage);

would be the same as:

unsigned stage1;
unsigned stage2;
unsigned stage3;
unsigned stage5;

namespace SomeNameSpace {

   unsigned stage2;

   void Func(void)
       unsigned stage3;

       unsigned *const stage[] = {

What I'm saying here is that the operator "__available(id)" yields at
compile-time an initialisation list of all the objects which are
visible within the current namespace and which begin with 'id'
followed by a number.

I got this idea when I was doing desktop GUI programming today with
wxWidgets, and I had several object names in an automatically-generate
source file as follows:

   class MyDialog : public wxDialog {
       wxCheckBox ckFeature1;
       wxCheckBox ckFeature2;
       wxCheckBox ckFeature3;
       wxCheckBox ckFeature4;
       wxCheckBox ckFeature5;
       wxCheckBox ckFeature6;
       wxCheckBox ckFeature7;
       wxCheckBox ckFeature8;
       wxCheckBox ckFeature9;
       wxCheckBox ckFeature10;
       wxCheckBox ckFeature11;
       wxCheckBox ckFeature12;
       wxCheckBox ckFeature13;
       wxCheckBox ckFeature14;
       wxCheckBox ckFeature15;
       wxCheckBox ckFeature16;

It would have been nice to be able to set all the tick boxes as follows:

   for ( wxCheckBox *p : __available(ckFeature) )
       if ( p ) p->SetValue(true);

To be more technical about it, here are the specifics:

1) The '__available' operator can only be used in two ways:
 1.a) Following the '=' operator in the initialisation of an array of pointers
 1.b) As the 'range-expression' in a 'range-based for loop' (but only
if the 'init-statement' is not 'auto' -- this restriction is in place
because we need to know the type)
2) When the '__available' operator is looking for objects visible
within the current namespace, it only finds objects that are the same
type as, or whose pointers are implicitly convertible to, the type
specified in either '1.a' or '1.b' above.

So for example, if you have:

   class Mammal {};

   class Dog : public Mammal {};

   Mammal obj1;
   Dog obj2;
   Mammal obj3;
   Dog obj4;

Then you do the following:

   for ( Mammal *p : __available(ob) )
       if ( p ) p->Eat();

then it will find obj1, obj2, obj3 and obj4. Specifically it will find
obj2 and obj4 because a Dog* can convert implicitly to a Mammal*.
Std-Proposals mailing list