I don't see how it makes anything compatible at all.. because it's NOT a 0 or a
-1 integer value, it's a STRING of '0' or '-1' so you can't even evaluate the
negative bit.. because there isn't one, it's a string of - and 1. You would
have to do StrToInt(BoolToStr(MyVariable)) to be able to evaluate the negative
bit... which again is useless because there is only one bit to check.. indeed
you would need to do StrToInt(BoolToStr(MyVariable)) just to evaluate the 0 as
a numeric value, but then this is a really round about way to do it when you
could make a simple BoolToInt function to just give you the numeric result.
Even if it is convenient to set the - flag for "All Bits Set" it doesn't apply
to BoolToStr, because we aren't evaluating a Nibble, or a Byte, or a Word, etc,
we are only evaluating a single bit Boolean variable.. so there are no, ALL
Bits, there is only THE Bit. I guess technically ALL one of it was set... but
making it a -1 makes it more difficult to stack a bunch of these bits together
into a word or something, and the - really serves no purpose if there is only
one bit.. in fact you can't even put it into a byte because -1 isn't a valid
Byte. You would have to do MyByte:=Abs(StrToInt(BoolToStr(True)));
I think it would be best to make BoolToStr always produce 'TRUE' or 'FALSE' as
the default because that is what is documented, and that is also what makes the
most sense.. after all you are asking for a STRING, so you are outputting to
something that wants a String, probably to be readable at some point, if you do
Writeln of a Boolean you get 'TRUE' or 'FALSE', and BoolToStr should do that
same thing... just like the documentation indicates.
An additional BoolToInt could be added that returned an integer, which I think
should return a 0 or a 1, but maybe retain the ability to customize the integer
output the same way BoolToStr does, then if you want to check the - flag
instead of checking the 1 bit, you could do that.. as silly as it is for a 1
bit test.
Anyway, I suppose such a change would break a whole pile of stuff at this
point, so it's probably not going to happen... but it would be nice if it made
more logical sense, and BoolToInt is what you need if you want to get a 0 and 1
(or 0 and -1 as the case may be) numerical value, but there doesn't appear to
be one in FPC.
I'm curious if there is a way to search the FPC version history of changes for
BoolToStr to see why it was changed, and see if there is a valid reason not to
change it back. it was obviously changed from the way the documentations is at
some point. It really seems to me that if it was that important that someone
had a function that output a 0 or a -1, the only way it makes sense is if it's
an integer, not a string.
If a special function is needed for some COM thing or weird Winapi thing, then
that function should be part of the unit that needs it, not modifying the
generic function intended to be used for general purpose applications output
something that does not conform to other Pascal Boolean datatypes and just
confuses everyone.
James
Op 8/28/2022 om 8:45 PM schreef Ralf Quint via fpc-pascal:
On 8/28/2022 8:23 AM, James Richters via fpc-pascal wrote:
Running "i:\booltostr.exe "
-1
0
Why true is -1 instead of 1 is beyond me, but anyway, I would consider this
BoolToInt, not BoolToStr, I want the Strings ‘TRUE’ or ‘FALSE’ as indicated in
the documentation
Very logical in fact. 0 is NO bit set in any given size of boolean data type,
-1 means ALL bits set on that same size boolean data type.
Pascal boolean datatypes only have 0 or 1 as defined values. But probably it
is for some COM or Winapi compatible purpose.
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
