Date: Thu, 02 Sep 2021 14:28:07 -0500
>
> To be honest, I could not your reserved range idea. Could explain more?
It is sometimes the case where I need my users to extend my enums in ways that I don't know ahead of time. QEvent is an example: there are a few hundred events supported, but it is likely that someone will want to send an application specific event. Thus they have QEvent::USER (which is = 1000), and have promised to never use anything past that range. Thus each application needing custom events can do "int myEvent=QEvent::USER; int mySecondEvent = QEvent::USER+2';" this works, but it is undefined behavior as the values are not in the legal range of the enum (as undefined behavior sanitizer reminds me - I think this has been fixed in later qt by making INT_MAX in range - though if I read the standard right it is still technically undefined behavior).
The other, bigger issue I have with this is I need to keep a global list of events that my large project will send just to ensure different groups don't reuse the same event for different purposes. We end up with a global header that needs special process control to ensure that people can add the event they need without using an event someone else does. This process of course slows everyone down. (conflicts are rarely a problem, but when they are debugging is hard because it is easy to show anything that should send the event in question didn't and yet it arrived)
What I want is a way that QEvent can say 1000-INT_MAX (or some other value) is reserved for users. In turn i want to sub-divide it to group A gets 1000-1999, group B gets 2000-2999... Some of those groups will want to subdivide that even farther along lines that make sense to their part of the projects.
Of course if you want to use a value from group C's allocation you need to include their header, but most of the time you don't need to know what the values mean: you just want to pass them through.
This won't solve the entire problem of course. The obvious problem is it would be possible for two different enums to both inherent from the same base reserved range - this should be a compile error when it is in the same compilation context, but otherwise I suppose it is just undefined behavior.
Even in a library as large as QT this only would apply to a couple enums. I'm not sure how valuable it actually is (not enough that I've felt it worthwhile to write a paper, but if someone encourages me)
> To be honest, I could not your reserved range idea. Could explain more?
It is sometimes the case where I need my users to extend my enums in ways that I don't know ahead of time. QEvent is an example: there are a few hundred events supported, but it is likely that someone will want to send an application specific event. Thus they have QEvent::USER (which is = 1000), and have promised to never use anything past that range. Thus each application needing custom events can do "int myEvent=QEvent::USER; int mySecondEvent = QEvent::USER+2';" this works, but it is undefined behavior as the values are not in the legal range of the enum (as undefined behavior sanitizer reminds me - I think this has been fixed in later qt by making INT_MAX in range - though if I read the standard right it is still technically undefined behavior).
The other, bigger issue I have with this is I need to keep a global list of events that my large project will send just to ensure different groups don't reuse the same event for different purposes. We end up with a global header that needs special process control to ensure that people can add the event they need without using an event someone else does. This process of course slows everyone down. (conflicts are rarely a problem, but when they are debugging is hard because it is easy to show anything that should send the event in question didn't and yet it arrived)
What I want is a way that QEvent can say 1000-INT_MAX (or some other value) is reserved for users. In turn i want to sub-divide it to group A gets 1000-1999, group B gets 2000-2999... Some of those groups will want to subdivide that even farther along lines that make sense to their part of the projects.
Of course if you want to use a value from group C's allocation you need to include their header, but most of the time you don't need to know what the values mean: you just want to pass them through.
This won't solve the entire problem of course. The obvious problem is it would be possible for two different enums to both inherent from the same base reserved range - this should be a compile error when it is in the same compilation context, but otherwise I suppose it is just undefined behavior.
Even in a library as large as QT this only would apply to a couple enums. I'm not sure how valuable it actually is (not enough that I've felt it worthwhile to write a paper, but if someone encourages me)
-- Henry Miller hank_at_[hidden]
Received on 2021-09-02 14:28:33