Unsigned integers

[Wyzard]

I'm considering using Ice in a project, because it seems like a very nice alternative to CORBA. However, I disagree with the decision not to support unsigned integer types in Slice.

What's the chance that either a) support for unsigned types will be added in a future version, or b) if I were to implement it myself, my patch would be accepted into the official codebase? (I'm not saying that I definitely will implement it -- that depends a lot on how much time I have available -- but I'm a lot more likely to do it if it doesn't mean creating my own personal fork of Ice.)

[marc]

We do not want to add unsigned types to Ice. They do not map to languages such as Java, and we do also not believe that they are useful in general. Even the author of C++, Bjarne Stroustrup, warns about unsigned types in his book "The C++ Programming Language".

[Wyzard]

Before posting, I looked up "unsigned" in the index of my copy of TC++PL and followed the references I found there, and didn't see any such warning. If you can refer me to a page number, though, I'd be interested in seeing what he says. I also recently ordered a copy of "Large-Scale C++ Software Design", which is mentioned in this thread on the subject.

I like unsigned types because they express intent. Clean code is code which captures the programmer's intent as clearly and succinctly as possible; if the intent is that negative values are invalid for a particular variable, then they should be excluded from the domain of the data type used to store the variable. If a signed type is used, checking whether "x is less than 5" isn't enough -- you have to check whether "x is less than 5 and not less than 0", which just adds clutter and decreases readability, IMO.

I've read the paper that you linked to in the thread I mentioned above, and I disagree with the author's reasoning, but the explanation would take a few paragraphs so I won't go into that unless you'd like to hear it.

I recognize that mapping unsigned types into Java creates a problem, but leaving them out of Slice just offloads that problem onto users of the other languages Ice supports. Java users are free to choose not to use unsigned types in their interfaces, but when I'm writing C# code that talks to Python code, I see no good reason to be constrained by a limitation of Java.

Anyway, I don't want to sound like I'm ranting, but I do hope you'll consider adding the feature so it's available to people who do have a good reason to use it. Providing support doesn't force anyone to use it, but leaving it out forces people not to use it.

[matthew]

Originally posted by Wyzard
Before posting, I looked up "unsigned" in the index of my copy of TC++PL and followed the references I found there, and didn't see any such warning. If you can refer me to a page number, though, I'd be interested in seeing what he says.
...

I'm not sure what Marc was referring to in particular. However, section 4.4 issues a pretty clear warning about the use of unsigned types.

"... The unsigned integer types are ideal for uses that treat storage as a bit array. Using an unsigned instead of an int to gain one more bit to represent positive integers is almost never a good idea. Attempts to ensure that some values are positive by declaring variables unsigned will typically be defeated by the implicit conversion rules."

Our experience has taught us that unsigned types are typically unnecessary and quite often lead to hard to find bugs. In our opinion they don't have a place in interface specifications.

Regards, Matthew

[marc]

There was a long discussion about this subject in the comp.lang.c++.moderated newsgroup (you can search for it in Google, title "unsigned vs signed - Is Bjarne Mistaken?"). This discussion also contains references to what Bjarne wrote about this subject in The C++ Programming Language.

Not everyone agrees with Bjarne or other C++ experts such as Scott Meyers on this matter. However, we at ZeroC share the opinion of Bjarne and Scott on this subject, and have therefore decided not to add unsigned types to Slice.

If Slice would support unsigned types, Java developers might not always be free to choose not to use them. If a Java developer were given the task to develop an application based on an existing Slice specification with unsigned types, then it would be much more difficult for the Java developer to perform this task. (This is not just a theoretical scenario. I implemented many CORBA specifications with unsigned types, where I had to perform complicated type conversions in the Java code. It would have been much easier if the specifications wouldn't have had unsigned types.)

[Wyzard]

Originally posted by marc
If a Java developer were given the task to develop an application based on an existing Slice specification with unsigned types, then it would be much more difficult for the Java developer to perform this task. (This is not just a theoretical scenario. I implemented many CORBA specifications with unsigned types, where I had to perform complicated type conversions in the Java code. It would have been much easier if the specifications wouldn't have had unsigned types.)

Understood. However, in order to avoid the possibility of Java developers having to do "complicated type conversions", you force users of other languages to do the same "complicated type conversions" to fit their unsigned data into the signed Slice interface. It doesn't really solve anything, just changes who has to deal with the problem.

I guess it makes sense quantitatively, since only two of the six languages supported by Ice (C++ and C#) directly support unsigned integers. Still, as a user of C++ and C#, it bothers me to be unable to use the data type which most naturally represents my data.

Speaking more wishfully, I'd also go as far as to say that it'd be nice if programming languages supported a "positive integer" type whose range excludes zero. For example, a positive short would have values 1 through 65536 rather than 0 through 65535. Unfortunately, neither processor instruction sets nor programming languages do this.