5 ms·

System.LongBool

41 points by surprisetalk 1y ago

azhenley 1y ago
I need some context… why?
- huflungdung 1y ago
  [dead]
- dale_glass 1y ago
  It says it right there: "Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries."
- beyondCritics 1y ago
  Turns out that old versions of Visual C++ used their own typedef of bool as int: https://stackoverflow.com/questions/4897844/is-sizeofbool-defined-in-the-c-language-standard https://stackoverflow.com/questions/4897844/is-sizeofbool-de...
  - bobmcnamara 1y ago
    There were risc platforms with int sized bool, usually where one byte math wasn't in the instruction set.
- bobmcnamara 1y ago
  In C, sizeof(bool) is implementation specific. Typical values are sizeof(char) and sizeof(int).
- keketi 1y ago
  In case you need a lot more than two boolean values some day.
knodi123 1y ago
I chuckled, but presumably it's useful for applications where you want data types to take up the same amount of space, like for matrices or database columns? Or maybe where you coerce different data types into boolean? The language offers WordBool and ByteBool too, so they're pretty consistent. And AFAIK, there aren't any languages where you can specifically allocate only a single bit for a single boolean.
- nneonneo 1y ago
  You kind of can in C with bit size specifications on struct members, but you’ll still face the problem that C’s minimum alignment is one byte - so a struct containing a single 1-bit field will still occupy a byte in memory. However, it does let you “allocate” different bits within a byte for different member fields. C++ has vector<bool>, which is supposed to be an efficient bit-packed vector of Booleans, but due to C++ constraints it doesn’t quite behave like a container (unlike other vector<T>s). Of course, if you make a vector<bool> of a single bit, that’s still going to occupy much more than one bit in memory. There are plenty of hardware specification languages where it’s trivial to “allocate” one bit, but those aren’t allocating from the heap in a traditional sense. (Simulators for these languages will often efficiently pack the bits in memory, but that’s more of an implementation detail than a language guarantee).
kevincox 1y ago
> Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries. Which makes sense. So these are really only intended to be used for FFI, not internal Delphi code. If you are bridging from C where bools are a byte you want to determine how you handle the other values. I think the one thing missing is specifying what the True and False constants map to. It is implied that False maps to 0 by "A WordBool value is considered False when its ordinality is 0" but it doesn't suggest that True has a predictable value which would be important for FFI use cases.
- stefs 1y ago
  I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?
  - kevincox 1y ago
    I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value". Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.
  - saurik 1y ago
    I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.
    - masfuerte 1y ago
      The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result. (Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)
1313ed01 1y ago
Also in Free Pascal? https://wiki.freepascal.org/Data_type#Boolean_types https://wiki.freepascal.org/Data_type#Boolean_types
nine_k 1y ago
This reply was wrong, removed. Please downvote it to oblivion.
- p_l 1y ago
  Every major CPU ISA still in use can, in fact, address individual bytes (C and C++ standards even demand atomic access). It's just inefficient, but sometimes needed (MMIO, inter-cpu visible byte changes, etc)
  - deleted 1y ago
    [deleted]
  - int_19h 1y ago
    C and C++ standards demand atomic access to individual chars. It is not a given that a C/C++ char is a "byte" in the conventional modern understanding of that word, though. sizeof(char)==sizeof(bool)===sizeof(int)==1 is a perfectly valid arrangement for an architecture that is only capable of addressing machine words, and there have been such architectures historically although I'm not sure any are still around today.
    - piperswe 1y ago
      Don't modern C and C++ standards mandate an 8-bit char now though? EDIT: never mind, guess I misremembered! it's just mandated to be at least 8 bits
- jonathrg 1y ago
  You can just make stuff up on this website
noir_lord 1y ago
Amazes me that Embarcadero/Delphi is still going - it's been 25ish years since I wrote a line of Object Pascal, it was a very nice language in its day with an even nicer IDE.
MarkSweep 1y ago
I assume this type is for compatibility with the 32-bit BOOL type on Windows. This is a common bugaboo when doing interoperability, as I think languages tend to define bool as a 8-bit value. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types https://learn.microsoft.com/en-us/windows/win32/winprog/wind... This must be a pretty slow news day for this to make the front page of Hacker News.
mastax 1y ago
Don’t they use int-size bools in Solaris? I think I remember seeing those in ZFS.
spyrja 1y ago
Next up: 64-bit booleans for the win!
- ray_v 1y ago
  I'd like to allocate memory for one mega-bool please.
tux3 1y ago
There was a proposal for a unit type for C++, it would be a zero-sized type just like void except that you could actually use it to declare a variable and pass around as a value, like other regular types. The less serious proposal: have it be `long void`
- magicalhippo 1y ago
  In Delphi, and possibly other Pascal variants, you can do this with a type that's just an empty record (struct). It'll have zero size, but you can declare variables of that type, pass it as parameters and such. IIRC things get a bit funky using this in certain situations, so I'm not sure the compiler devs actually considered this or if it's just a happy accident of sorts.
  - int_19h 1y ago
    The problem is that it's still a nominal type system, so each empty struct is still a different type. A proper unit type has a single value of that type, and it's the same throughout the entire program.
    - magicalhippo 1y ago
      > The problem is that it's still a nominal type system, so each empty struct is still a different type. Fair point, though for me that was a feature when I used it in Delphi. Allowed me to differentiate them when using them as type parameters (generics).
- kragen 1y ago
  Empty structs are supported in clang; I think it's a GCC extension to C. This program: #include <stdio.h> typedef struct {} unit; static unit f(unit *p) { return (unit){}; } static void g(unit u) { } int main() { unit a = {}, b = {}; a = b; f(&a); g(b); printf("a is at %lx, b is at %lx, " "sizeof unit is %d\n", (unsigned long)&a, (unsigned long)&b, (int)sizeof(unit)); return 0; } compiles without complaints on my cellphone and produces the output: a is at 7ffb39805b, b is at 7ffb39805a, sizeof unit is 0 So you can declare empty structs as variables, return them, assign them, pass them as parameters, take their addresses, create them in struct literals, and dereference pointers to them. clang is assigning different addresses to different empty-struct local variables, but presumably in an array all of them would have the same address, unlike in C++. I wouldn't be confident that you could malloc them, and I wouldn't be surprised if passing them by value uncovered compiler divergences in the interpretation of the ABI. (I spent most of last night tracking down a bug due to LuaJIT/GCC ABI differences in the implementation of parameter passing.)
hamonrye 1y ago
[dead]
isolay 1y ago
This looks so strange from a mathematical perspective. A Boolean type has exactly `true` and `false` as valid instances, but this one allows every 32-bit value. Par for the course of PLs that were arbitrarily invented instead of derived from maths.

System.LongBool

41 points by surprisetalk 1y ago

azhenley 1y ago

I need some context… why?

huflungdung 1y ago
[dead]
dale_glass 1y ago
It says it right there: "Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries."
beyondCritics 1y ago
Turns out that old versions of Visual C++ used their own typedef of bool as int: https://stackoverflow.com/questions/4897844/is-sizeofbool-defined-in-the-c-language-standard https://stackoverflow.com/questions/4897844/is-sizeofbool-de...
- bobmcnamara 1y ago
  There were risc platforms with int sized bool, usually where one byte math wasn't in the instruction set.
bobmcnamara 1y ago
In C, sizeof(bool) is implementation specific. Typical values are sizeof(char) and sizeof(int).
keketi 1y ago
In case you need a lot more than two boolean values some day.

knodi123 1y ago

I chuckled, but presumably it's useful for applications where you want data types to take up the same amount of space, like for matrices or database columns? Or maybe where you coerce different data types into boolean? The language offers WordBool and ByteBool too, so they're pretty consistent. And AFAIK, there aren't any languages where you can specifically allocate only a single bit for a single boolean.

nneonneo 1y ago
You kind of can in C with bit size specifications on struct members, but you’ll still face the problem that C’s minimum alignment is one byte - so a struct containing a single 1-bit field will still occupy a byte in memory. However, it does let you “allocate” different bits within a byte for different member fields. C++ has vector<bool>, which is supposed to be an efficient bit-packed vector of Booleans, but due to C++ constraints it doesn’t quite behave like a container (unlike other vector<T>s). Of course, if you make a vector<bool> of a single bit, that’s still going to occupy much more than one bit in memory. There are plenty of hardware specification languages where it’s trivial to “allocate” one bit, but those aren’t allocating from the heap in a traditional sense. (Simulators for these languages will often efficiently pack the bits in memory, but that’s more of an implementation detail than a language guarantee).

kevincox 1y ago

> Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries. Which makes sense. So these are really only intended to be used for FFI, not internal Delphi code. If you are bridging from C where bools are a byte you want to determine how you handle the other values. I think the one thing missing is specifying what the True and False constants map to. It is implied that False maps to 0 by "A WordBool value is considered False when its ordinality is 0" but it doesn't suggest that True has a predictable value which would be important for FFI use cases.

stefs 1y ago
I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?
- kevincox 1y ago
  I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value". Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.
- saurik 1y ago
  I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.
  - masfuerte 1y ago
    The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result. (Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)

1313ed01 1y ago

Also in Free Pascal? https://wiki.freepascal.org/Data_type#Boolean_types https://wiki.freepascal.org/Data_type#Boolean_types

nine_k 1y ago

This reply was wrong, removed. Please downvote it to oblivion.

p_l 1y ago
Every major CPU ISA still in use can, in fact, address individual bytes (C and C++ standards even demand atomic access). It's just inefficient, but sometimes needed (MMIO, inter-cpu visible byte changes, etc)
- deleted 1y ago
  [deleted]
- int_19h 1y ago
  C and C++ standards demand atomic access to individual chars. It is not a given that a C/C++ char is a "byte" in the conventional modern understanding of that word, though. sizeof(char)==sizeof(bool)===sizeof(int)==1 is a perfectly valid arrangement for an architecture that is only capable of addressing machine words, and there have been such architectures historically although I'm not sure any are still around today.
  - piperswe 1y ago
    Don't modern C and C++ standards mandate an 8-bit char now though? EDIT: never mind, guess I misremembered! it's just mandated to be at least 8 bits
jonathrg 1y ago
You can just make stuff up on this website

noir_lord 1y ago

Amazes me that Embarcadero/Delphi is still going - it's been 25ish years since I wrote a line of Object Pascal, it was a very nice language in its day with an even nicer IDE.

MarkSweep 1y ago

I assume this type is for compatibility with the 32-bit BOOL type on Windows. This is a common bugaboo when doing interoperability, as I think languages tend to define bool as a 8-bit value. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types https://learn.microsoft.com/en-us/windows/win32/winprog/wind... This must be a pretty slow news day for this to make the front page of Hacker News.

mastax 1y ago

Don’t they use int-size bools in Solaris? I think I remember seeing those in ZFS.

spyrja 1y ago

Next up: 64-bit booleans for the win!

ray_v 1y ago
I'd like to allocate memory for one mega-bool please.

tux3 1y ago

There was a proposal for a unit type for C++, it would be a zero-sized type just like void except that you could actually use it to declare a variable and pass around as a value, like other regular types. The less serious proposal: have it be `long void`

magicalhippo 1y ago
In Delphi, and possibly other Pascal variants, you can do this with a type that's just an empty record (struct). It'll have zero size, but you can declare variables of that type, pass it as parameters and such. IIRC things get a bit funky using this in certain situations, so I'm not sure the compiler devs actually considered this or if it's just a happy accident of sorts.
- int_19h 1y ago
  The problem is that it's still a nominal type system, so each empty struct is still a different type. A proper unit type has a single value of that type, and it's the same throughout the entire program.
  - magicalhippo 1y ago
    > The problem is that it's still a nominal type system, so each empty struct is still a different type. Fair point, though for me that was a feature when I used it in Delphi. Allowed me to differentiate them when using them as type parameters (generics).
kragen 1y ago
Empty structs are supported in clang; I think it's a GCC extension to C. This program: #include <stdio.h> typedef struct {} unit; static unit f(unit *p) { return (unit){}; } static void g(unit u) { } int main() { unit a = {}, b = {}; a = b; f(&a); g(b); printf("a is at %lx, b is at %lx, " "sizeof unit is %d\n", (unsigned long)&a, (unsigned long)&b, (int)sizeof(unit)); return 0; } compiles without complaints on my cellphone and produces the output: a is at 7ffb39805b, b is at 7ffb39805a, sizeof unit is 0 So you can declare empty structs as variables, return them, assign them, pass them as parameters, take their addresses, create them in struct literals, and dereference pointers to them. clang is assigning different addresses to different empty-struct local variables, but presumably in an array all of them would have the same address, unlike in C++. I wouldn't be confident that you could malloc them, and I wouldn't be surprised if passing them by value uncovered compiler divergences in the interpretation of the ABI. (I spent most of last night tracking down a bug due to LuaJIT/GCC ABI differences in the implementation of parameter passing.)

hamonrye 1y ago

[dead]

isolay 1y ago

This looks so strange from a mathematical perspective. A Boolean type has exactly `true` and `false` as valid instances, but this one allows every 32-bit value. Par for the course of PLs that were arbitrarily invented instead of derived from maths.