Strings.IntToStringForm: convert a number to Oberon format

[Zorko]

I propose to increase the functionality of the procedure Strings.IntToStringForm.

There is an input parameter MinWidth, which is responsible for the minimum number of output characters of a converted number. Any the number can take up one or more characters. But still, ASSERT inside this procedure also allows the value of MinWidth = 0

Code: Select all

		ASSERT(minWidth >= 0, 22);

Here, when MinWidth = 0, nothing terrible happens, but it will be the same as 1.

I was recently forced to write such code:

Code: Select all

	PROCEDURE WriteHex(i: INTEGER);
		VAR minWidth: INTEGER;
	BEGIN
		IF i > 9FFFH THEN minWidth := 5
		ELSIF i > 9FFH THEN minWidth := 4
		ELSIF i > 9FH THEN minWidth := 3
		ELSIF i > 9H THEN minWidth := 2
		ELSE minWidth := 1
		END;
		W.WriteIntForm(i, TextMappers.hexadecimal, minWidth, "0", FALSE)
	END WriteHex;

This procedure outputs a hexadecimal value in the Oberon format, i.e. if a hexadecimal literal starts with a letter, it is preceded by an insignificant zero.

And this behavior can be demanded quite often, so I suggest that with MinWidth = 0, implement exactly this behavior as encoded in my procedure: a hexadecimal number with an insignificant zero is output if this number starts with a letter. What do you think, colleagues?

[Zinn]

Sorry I don't understand your problem. You can optimize your procedure to

Code: Select all

  PROCEDURE WriteHex(i: INTEGER);
      VAR minWidth: INTEGER;
   BEGIN
      minWidth := 1;
      W.WriteIntForm(i, TextMappers.hexadecimal, minWidth, "0", FALSE)
   END WriteHex;

and have the same behaviour.
- Helmut

[Josef Templ]

Sorry I don't understand your problem. You can optimize your procedure to

Code: Select all

  PROCEDURE WriteHex(i: INTEGER);
      VAR minWidth: INTEGER;
   BEGIN
      minWidth := 1;
      W.WriteIntForm(i, TextMappers.hexadecimal, minWidth, "0", FALSE)
   END WriteHex;

and have the same behaviour.
- Helmut

Helmut, I think this is not the same as required by Zorko. It does not precede the output with an insignificant 0.
Test for example with the value 10. It will be output as A but expected is 0A.

@Zorko
In general, I would suggest NOT to change existing behavior as proposed by the initial posting.
A clean solution may be to add another form constant for the Component-Pascal notation of hex numbers if it is agreed to be an important feature.

- Josef