<div dir="ltr"><div>See: <a href="http://tutorial.modernpascal.com/?DataTypes">http://tutorial.modernpascal.com/?DataTypes</a><br><br></div>I implemented INTEGER as 32bit, but, if FPC makes it 16bit only, I will go make the change right now. My end-users all know *DO NOT USE INTEGER* it's even in the license agreement. "It is only there for make code compatible w/ Delphi and FPC." I am still spending all my spare time to get MPC's tutorial site up to par with FPC - as I promote MPC as FPC's Script Engine.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 26, 2017 at 8:50 AM, Ozz Nixon <span dir="ltr"><<a href="mailto:ozznixon@gmail.com" target="_blank">ozznixon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I like the concept, I would like to ask that we do not support INTEGER as a type, and be more specific by limiting to SHORTINT, SMALLINT, LONGINT, INT64. That way code snippets are not confusing when you implement 16bit INT logic on a 32bit INT environment. Because I do a lot of documentation for n00bs in Pascal - the interchangeable INTEGER is probably one of Borland's biggest mistakes with the grammar! I would love to see FPC make the statement that the type INTEGER is 16bit only - deal with people freaking out for a year or two, and move the language forward. Even the INTEGER example here is assuming 16bit - which would be incorrect on 32bit platforms in specific $MODE. (may have picked wrong wording, however, I think everyone see's the point).<br><br></div>Other than that, if FPC adds this, I will add it to Modern Pascal, so at least the two products are supporting "BASED".<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 26, 2017 at 8:27 AM, Mark Morgan Lloyd <span dir="ltr"><<a href="mailto:markMLl.fpc-devel@telemetry.co.uk" target="_blank">markMLl.fpc-devel@telemetry.<wbr>co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26/12/17 12:45, Giuliano Colla wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/In short the BASED construct makes the C-style dereferencing operator unnecessary, by moving dereferencing from code to declaration.<span><br>
<br>
In fpc this translates into code looking like this, in this trivial example:<br>
<br>
var<br>
I: BYTE;<br>
I1: INTEGER;<br>
ItemPtr: Pointer;<br>
Item: BYTE BASED ItemPtr;<br>
IntegerItem: INTEGER BASED ItemPtr;<br>
....<br>
ItemPtr := @I;<br>
Item := $41;<br>
....<br>
ItemPtr := @I1;<br>
IntegerItem := -32767;<br>
<br>
This code will load the BYTE value $41 into the variable I, and the INTEGER value -32767 into the variable I1.<br>
</span></blockquote>
<br>
What does gdb (and possibly other debuggers) make of this? Is it really appropriate to declare Item as a variable, when it's really more akin to a macro?<span class="m_4104939328501276881HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mark Morgan Lloyd<br>
markMLl .AT. <a href="http://telemetry.co" rel="noreferrer" target="_blank">telemetry.co</a> .DOT. uk<br>
<br>
[Opinions above are the author's, not those of his employers or colleagues]<br>
______________________________<wbr>_________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" rel="noreferrer" target="_blank">http://lists.freepascal.org/cg<wbr>i-bin/mailman/listinfo/fpc-dev<wbr>el</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>