Re: Weird problem calling DLL

Paul E. Schoen wrote:
"Rob Kennedy" <me3@xxxxxxxxxxx> wrote in message news:712d9bFj2e0kU2@xxxxxxxxxxxxxxxxxxxxx
Marco van de Voort wrote:
On 2009-02-28, Benjamin <benja@xxxxxxxx> wrote:
function SaveAImage(fname, temp: pchar; tipo: integer; qual: byte; grayscale: boolean): integer ; stdcall; external IMAGEDLL;

extern "C" DDLL_API int SaveAImage(char* fname, char* temp, int tipo, BYTE qual, bool grayscale);
Besides the said callingconvention items, afaik a Delphi boolean is not
always equal to a bool also. Use Windows.BOOL instead of boolean
ByteBool would be a good choice. BOOL is a four-byte type; ByteBool is one byte like C++'s bool.

But Boolean is also a good choice. Neither Boolean nor bool can have any numeric values but 0 and 1 unless code has been doing funny things with type casts, which are not and never have been necessary. (So if the program stops working properly because of it, then, well, serves 'em right.)

I always thought a boolean True was -1, or $FF (binary all bits set). Zero is False in any language AFAIK. Usually any non-zero value is True.

In Delphi, Ord(True) is 1. In C++, bool's "usual arithmetic conversion" is the "integral promotion" that yields 1 for true.

Technically, *neither* language defines the binary representation of the types. Delphi merely defines what the Ord function does. C++ defines what happens when a bool expression occurs in a context where a number is expected. In either language, the door is open for arbitrary binary representations that the compiler inserts code to handle, to preserve the illusion that they're stored as 0 as 1.

Practically speaking, though, it would be foolish for language implementers to use anything other than 0 and 1, given how the languages need to work, not just internally, but with external libraries that have certain expectations for various data types.

You might be thinking of the OLE values. VB used all-bits-one for true. I suppose it was to make the "not" operator easy to implement. Besides that, though, I don't think there's much advantage to that representation.

For the most part, it doesn't really matter. The compiler generates code that checks for any non-zero value in a Boolean variable and treats them all as True.

Almost.

I have seen compiler-generated code that *masks out* the top bit as part of the comparison. That means that if you somehow go the value $80 into your variable it might be interpreted as False sometimes, but not all the time. Therefore, my advice continues to be that you should never type-cast to Boolean. If you have a numeric value, simply compare it with zero and store the result.

// No:
b := Boolean(x);
// Yes:
b := x <> 0;

--
Rob
.

Relevant Pages

  • [PATCH] drivers/block/DAC960: Converted boolean to bool
    ... Converts 'boolean' to 'bool' and removes the 'boolean' typedef. ... unsigned char CommandOpcode2, ... typedef struct DAC960_SCSI_RequestSense ...
    (Linux-Kernel)
  • [PATCH] drivers/video/sis: Convert to generic boolean
    ... BOOLEAN -> bool ... Have followed all function/variable paths who been converted to 'bool' ... SiS_GetModeID(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDisplay, ...
    (Linux-Kernel)
  • Re: bool or BOOL in MFC projects
    ... It says that a pointer is a bool. ... confusion of non-boolean values with boolean values to be really confusing. ... C came along and because they were defining a "minimal" language didn't think a boolean ...
    (microsoft.public.vc.mfc)
  • Re: Weird problem calling DLL
    ... afaik a Delphi boolean is ... always equal to a bool also. ... Zero is False in any language AFAIK. ... The compiler generates code ...
    (comp.lang.pascal.delphi.misc)
  • Re: missing xor Boolean operator
    ... When I was talking about such error prone form of boolean operations, ... is nothing in python that forces you to be "false" if you are empty, ... one should care more about how an object /behaves/ than ... you shouldn't care if you have a bool instance - it should ...
    (comp.lang.python)