J. David Bryan wrote:
On 12 Dec 2002 at 2:27, Frank Heckenbach wrote:
However, `Boolean (n)' cannot be done this way. It may be used for interfaces to other languages.
I acknowledge that it is helpful to have foreign (e.g., C) semantics for interfacing. But is there any need for a general Boolean size, or only for "Boolean (8)", "Boolean (16)", etc.? If so, then the latter might be predefined, and the general mechanism dropped.
I think only the latter -- or, more precisely, for types such as `WordBool' (int), `ByteBool' (char) etc. The difference may be small, but important. These types do not guarantee the size in bytes, but are guaranteed to be compatible with the mentioned C types on each platform. So, for C interfaces, they're the types of choice, and using `Boolean (8)' there would actually be slightly wrong (it would be right for a C bit-field like `int foo : 8', used as a Boolean, but then again, those who use bitfields in C do so usually for size reasons, and would consequently use a single bit for Booleans which corresponds to the regular Pascal Boolean type when used in a packed record/array).
Types such as `WordBool' are absolutely unproblematic (and also needed for BP/Delphi compatibility), so they won't be dropped.
Prof A Olowofoyeku (The African Chief) wrote:
And when, one day, someone needs "Boolean (64)", "Boolean (128)", or "Boolean (24)", etc., then?
"Boolean (8)" is only a convenience; using "packed 0..255" (i.e., eight-bit cardinal) and a "To_Boolean" function would be equivalent.
Perhaps - but not as straightforward to use ...
BTW, `To_Boolean' is just `<> 0'. I'm not sure we need a built-in function here. (And `From_Boolean' would be `Ord'.)
It is a little less convenient (than nothing), but since it's good practice to write a Pascal interface (wrappers) for C libraries, it should only affect small portions of code.
Frank