OSDev.org

Ranged Numeric Types in C++

I've started writing a simple template class for automating range checking in specialized numeric types, inspired by the ranged types in languages such as Pascal and Ada. At the moment it is mainly meant for integer types, though I've made it flexible enough that it should work with floating-point types (I may need to revisit this later).

It is just a stub at this point, but it should make it easier to define numeric types which don't fit the usual 8/16/32/64 bit signed and unsigned sizes. It allow the client-programmer to select a base type define both a lower and an upper bound, and define how it should behave on either underflow or overflow (with the choices at the moment being to wrap around; to saturate at the boundary; or to throw an exception). The usual arithmetic operators will all be supported.

The question I have is this: is this really a useful class to write, and will others find it useful enough that it is worth providing publicly? Can you think of use cases where this would make things easier for someone working on a real-world project?

Schol-R-LEA wrote:The question I have is this: is this really a useful class to write, and will others find it useful enough that it is worth providing publicly? Can you think of use cases where this would make things easier for someone working on a real-world project?

In my day job (eww, thanks for making me think of my day job while I'm on vacation, Schol) this kind of stuff would help, but only incidentally. The thing is, the software system we are dealing with there saves tons of its settings in these huge arrays, where the indexes into the arrays are the identifiers of various things presented to the user.

In the code that runs that system, we also mainly throw these integer types around. It's like a stringly typed system without the readability. So the first problem there is (and we keep running into it), that we have to add 1 when presenting the number to the user. Or must subtract that 1 when indexing into the array. C doesn't care, it will let you convert these integer types among each other. Another problem we have is that an index for one array can be passed as an index to another. And the bad thing is, we have a lot of configurations where this stuff will keep working for a long time.

So your class templates would help there, if not for two things: For one, we mostly use C, and our C++ compiler is ultra-slow when dealing with templates. For two, some of those different numbers can happen to have the same limits, meaning that a typedef would resolve to the same type.

What I have started doing was to introduce structures containing only an integer and using that as the interface type in some functions. Now it is impossible to pass a program index to a function expecting a tool index and such. But this really doesn't scale well. You start at one point introducing this type and it infects a huge portion of the code, and the changeset keeps growing and growing... Well, that's why it is called technical debt.

On a different note, I know if I was at work, I would not even think of using third-party code for a problem as simple as this. It would just not cross my mind. So that's another thing that may limit the usability of your project.

nullplan wrote:

Schol-R-LEA wrote:The question I have is this: is this really a useful class to write, and will others find it useful enough that it is worth providing publicly? Can you think of use cases where this would make things easier for someone working on a real-world project?

In my day job (eww, thanks for making me think of my day job while I'm on vacation, Schol) this kind of stuff would help, but only incidentally. The thing is, the software system we are dealing with there saves tons of its settings in these huge arrays, where the indexes into the arrays are the identifiers of various things presented to the user.

In the code that runs that system, we also mainly throw these integer types around. It's like a stringly typed system without the readability. So the first problem there is (and we keep running into it), that we have to add 1 when presenting the number to the user. Or must subtract that 1 when indexing into the array. C doesn't care, it will let you convert these integer types among each other. Another problem we have is that an index for one array can be passed as an index to another. And the bad thing is, we have a lot of configurations where this stuff will keep working for a long time.

So your class templates would help there, if not for two things: For one, we mostly use C, and our C++ compiler is ultra-slow when dealing with templates. For two, some of those different numbers can happen to have the same limits, meaning that a typedef would resolve to the same type.

What I have started doing was to introduce structures containing only an integer and using that as the interface type in some functions. Now it is impossible to pass a program index to a function expecting a tool index and such. But this really doesn't scale well. You start at one point introducing this type and it infects a huge portion of the code, and the changeset keeps growing and growing... Well, that's why it is called technical debt.

On a different note, I know if I was at work, I would not even think of using third-party code for a problem as simple as this. It would just not cross my mind. So that's another thing that may limit the usability of your project.

Am I the only one who wishes your company just used Ada for that project? I mean, you then could've just created a subtype of Positive and everything would've lined up perfectly. And if you did need zero-array indexing you could just use Natural.

Ethin wrote:Am I the only one who wishes your company just used Ada for that project?

Yes, you are. I'm wishing they'd designed the system better, then the language almost doesn't matter. C has the facilities to deal with this problem systematically, they would just have needed to use them. OK, it doesn't help for array indexes (only solution there is to make the array local to a given source file and isolate accesses with functions. Which is the better design anyway, but hard to retrofit).

Anyway, bad programmers can turn any language into FORTRAN.

nullplan wrote:

Ethin wrote:Am I the only one who wishes your company just used Ada for that project?

Yes, you are. I'm wishing they'd designed the system better, then the language almost doesn't matter. C has the facilities to deal with this problem systematically, they would just have needed to use them. OK, it doesn't help for array indexes (only solution there is to make the array local to a given source file and isolate accesses with functions. Which is the better design anyway, but hard to retrofit).

Anyway, bad programmers can turn any language into FORTRAN.

Definitely agreed. I'm also probably a bit biased since Ada has been constantly overshadowed by other things and really hasn't had a chance to shine, and its history doesn't help either. I'm hoping though that Ada gets more popular sometime soon since AdaCore is cleaning up its (most likely deliberate) licensing confusion act. Hopefully that will make people less hesitant to learn it. Eh, I might be just one of those people who sees beauty where others don't though.