Date: Sat, 22 Oct 2022 18:55:29 -0300
If you automatically generate the source code, can't you automatically
generate initialization?
Or maybe automatically generate the array such that you can iterate to
initialize?
This feature looks very very specific. So I wonder how applicable it would
be outside of your use case.
Em sáb., 22 de out. de 2022 16:24, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:
> 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[] = {
> nullptr,
> &::stage1,
> &::SomeNameSpace::stage2,
> &stage3,
> nullptr,
> &::stage5,
> };
> }
> }
>
>
> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
generate initialization?
Or maybe automatically generate the array such that you can iterate to
initialize?
This feature looks very very specific. So I wonder how applicable it would
be outside of your use case.
Em sáb., 22 de out. de 2022 16:24, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:
> 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[] = {
> nullptr,
> &::stage1,
> &::SomeNameSpace::stage2,
> &stage3,
> nullptr,
> &::stage5,
> };
> }
> }
>
>
> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-10-22 21:55:40