What is assignment-compatible with a bytebool etc.?

My reading of the manual suggested that it should be possible to assign numeric zero or non-zero, but

fPB1L: bytebool;
..
fPB1L := 0;
b5500centralcontrol.pas(119,18) Error: Incompatible types: got
"ShortInt" expected "ByteBool"

Am 03.01.2014 09:59 schrieb "Mark Morgan Lloyd" <

: What is assignment-compatible with a bytebool etc.?

True, False and a Boolean variable of any other of the Boolean types.

My reading of the manual suggested that it should be possible to assign

numeric zero or non-zero, but

expected "ByteBool"

You need to cast nevertheless. It's just that they can be used in place of e.g. BOOL parameters for WinAPI functions whereby the argument value is passed like the underlying non-Boolean datatype.

Regards,
Sven

Thanks Sven, noted and understood. In practice I've changed them all to qwords since this is the native size of the system being emulated, which leads to another question. If I have a field and property like

fPB1L: qword;
..
property PB1L: qword read: fPB1L write SetPB1L;
procedure ...SetPB1L(p: qword);
begin
   Assert((p = 0) or (p = 1));
   fPB1L := p
end;

is there an unobtrusive way of changing the property to effectively be

property PB1L: qword read fPB1L write fPB1L;

when assertions aren't being generated? The obvious way would be to use lots of $IFOPT C+ but is there anything more concise and maintainable? Can methods be inlined, and could the compiler successfully optimise-out a method which was a simple assignment?

Can methods be inlined, and could the compiler successfully optimise-out a

method which was a simple assignment?

Why don't you just try and see the generated assembly?

Am 04.01.2014 00:17 schrieb "Mark Morgan Lloyd" <

qwords since this is the native size of the system being emulated, which leads to another question. If I have a field and property like

And why don't you use Boolean64? That's a 64 bit Boolean type with True being 1 and False being 0 (like the normal 1 Byte one).

lots of $IFOPT C+ but is there anything more concise and maintainable? Can methods be inlined, and could the compiler successfully optimise-out a method which was a simple assignment?

As long as you don't declare the getter/setter methods as "virtual", but as "inline" I *think* that it should work. Just test it and look at the generated assembler code (using -al option). If it works then then there should be no "call" instruction.

Regards,
Sven

Sorry about my lousy threading, our gateway rejects the occasional message (Florian, I'm sure this is nothing to do with your announced server change).

Because I'm still finding my way through the code I'm transcribing, which is in Javascript despite the author being an ALGOL user of many years standing, and I haven't entirely got my head around his bit-extraction and comparison stuff. Also, albeit simplistically, settling on a single type makes it a bit easier to approximate the C-style conditional which he's using heavily... his idea of bit manipulation is to use lots of / and % operators which I'll try to improve but only once I've got the emulator running the MCP (and preferably its test tape, even if I have to transcribe that as well).

Thanks, I'll play with it. Although I think it might be some while before I dare to remove the assertions.

leledumbo wrote

> Can methods be inlined, and could the compiler successfully optimise-out a method which was a simple assignment? Why don't you just try and see the generated assembly?

I will presently, but I'm also interested in any warnings that something is of dubious stability or that a feature will be added to the compiler shortly.