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).
> 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.
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
>
> 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).
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).
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?
>
> 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.
Thanks, I'll play with it. Although I think it might be some while
before I dare to remove the assertions.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
