August Karlstrom wrote:
> Michael van Acken wrote:
>> Beforehand, you can't. What you can do is check if the result
>> maxes out the array, and call again with a larger array if this
>> is the case. Repeat until not maxed out. Not very elegant, I
>> know :-)
>
>
> OK, I see. This is (of course) a general problem in Oberon. In C we can
> just return a pointer to a constant string so there is no need to either
> allocate a buffer or know the size of it. In defense of Oberon, a C
> program may crash if we inadvertently try to write to a constant string.
> Still a bit annoying though.
The method returns a string which is constructed from a template and a
set of attributes. In this sense its a little more complicated than
something like strerror(), which could indeed return a pointer to a
constant string.
In Oberon-2, string constants are treated as ARRAY OF CHAR, so the
convention is to represent strings in this way. Its true that the API
could have returned a POINTER TO ARRAY OF CHAR, which would get around
the size limitation. I guess it is for simplicity that people usually
use the same type (ARRAY OF CHAR) for inputs and outputs to functions
that deal with strings.
OOC also has its own STRING type (Object.String) which has a
concatenation operator and many other utility methods. It abstracts over
the different underlying characters sets (allowing 8-, 16- or 32-bit
characters). Most of the newer APIs use this type of string, and it is
possible to convert between the different representations.
Cheers,
Stewart
|
