Am 30.03.2016 10:37 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
> > At that time word size might vary dramatically from system to system (
> > https://en.wikipedia.org/wiki/Word_(computer_architecture) )
>
> Interesting. I never knew Word was platform dependant. I see even for
>
In our previous episode, Dmitry Boyarintsev said:
> > So I definitely see the benefit in using (U)Int style data types.
> > They are a lot more obvious [to the programmer] regarding data ranges
> > and byte size.
> >
>
> Does, it also make the code less high-level?
> Didn't high level use the plat
On Wed, Mar 30, 2016 at 4:37 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> In my case I'm specifically referring to the benefit of using (U)Int
> style data types for use in record structures when reading binary data
> files.
>
Makes sense.
> Does FPC follow that platform rule,
On 2016-03-30 02:24, Dmitry Boyarintsev wrote:
>
> Does, it also make the code less high-level?
In my case I'm specifically referring to the benefit of using (U)Int
style data types for use in record structures when reading binary data
files. In this case, no matter the platform, the data structu
Marco van de Voort wrote:
Moreover since shorter types are not always faster, I think it is better to
forget all this, and in new code use INTEGER for the variable types, where
range doesn't matter (much) and (u)int for the rest.
Seems eminently sensible to me.
--
Mark Morgan Lloyd
markMLl .A
On Tuesday 29 March 2016 21:54:22 Graeme Geldenhuys wrote:
>
> > I'm inclined to use the (U)IntX (with X being a element of [8,
> > 16, 32, 64]) types to avoid any confusion and surprises.
>
> That's not a bad idea either... I'll look into that for future code.
>
In MSElang the base types in unit "
Am 30.03.2016 um 03:06 schrieb Graeme Geldenhuys:
> Thanks Marco, interesting history lesson. ;-)
>
> On 2016-03-29 22:16, Marco van de Voort wrote:
>> Moreover since shorter types are not always faster, I think it is better to
>> forget all this, and in new code use INTEGER for the variable types
On Tue, Mar 29, 2016 at 9:06 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> So I definitely see the benefit in using (U)Int style data types.
> They are a lot more obvious [to the programmer] regarding data ranges
> and byte size.
>
Does, it also make the code less high-level?
Di
Thanks Marco, interesting history lesson. ;-)
On 2016-03-29 22:16, Marco van de Voort wrote:
> Moreover since shorter types are not always faster, I think it is better to
> forget all this, and in new code use INTEGER for the variable types, where
> range doesn't matter (much) and (u)int for the r
In our previous episode, Nikolay Nikolov said:
> compatible, changing Cardinal to 16-bit does more harm that good. Many
> FPC demos, such as fpctris and samegame now run unmodified on
> i8086-msdos.
(that's because parts of them, specially gameunit, have M2 origins)
In our previous episode, Sven Barth said:
> > types with fields of type Word, Smallint etc, than then some Cardinal
> > fields got mixed in too. I would normally use LongWord instead of
> > Cardinal to keep to a consistent naming convention. But from your
> > comments Cardinal has a long history in
On 03/29/2016 06:13 PM, Marco van de Voort wrote:
In our previous episode, Graeme Geldenhuys said:
Just curious. What is the history behind the Cardinal data type. As per
the FPC documentation, it is always mapped to the LongWord type. I
presume it is the same in Delphi.
Cardinal is the Wirth
Hi Michael,
On 2016-03-29 16:18, Michael Van Canneyt wrote:
> Longword used to be Cardinal.
> I guess it was changed for Delphi compatibility.
I really like Sven's idea of using (U)IntX data types where X is 8, 16,
32 or 64 bit. I think this is also future proof, considering Delphi's
data type m
On 2016-03-29 20:19, Sven Barth wrote:
>
> I usually use LongWord, too,
My preference is based on the fact that they often translate nicely from
C code examples and APIs. Plus I know those types and sizes pretty well
(at least when in comes to Free Pascal).
> but with the recent discovery that
Am 29.03.2016 17:27 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2016-03-29 16:13, Marco van de Voort wrote:
> > Cardinal is the Wirthian designation for the default unsigned integer,
> > just like "integer" is for signed.
>
> Thanks Marco, that fulfils my curiosity. :)
>
>
On Tue, Mar 29, 2016 at 11:31 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> On 2016-03-29 16:17, Dmitry Boyarintsev wrote:
> > In Delphi world LongWord is 64-bit on 64-bit iOS platform and it is
> 32-bit
> > on 64-bit Windows platform.
>
> So what happened when they introduced An
On 2016-03-29 16:13, Marco van de Voort wrote:
> Cardinal is the Wirthian designation for the default unsigned integer,
> just like "integer" is for signed.
Thanks Marco, that fulfils my curiosity. :)
On a side note:
The reason I asked this question. I'm working on code with many Record
types
On 2016-03-29 16:17, Dmitry Boyarintsev wrote:
> In Delphi world LongWord is 64-bit on 64-bit iOS platform and it is 32-bit
> on 64-bit Windows platform.
So what happened when they introduced Android support? Yet another
definition or copied one of the others?
Regards,
- Graeme -
_
On Tue, Mar 29, 2016 at 11:20 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>
> Which is quite confusing and a really bad decision.
> Basic integer types should not depend on the OS. On the CPU, yes.
>
> I guess they tried to make iOS platform a selling point and be more
C-like.
Just to
On 2016-03-29 16:17, Dmitry Boyarintsev wrote:
> In Delphi world LongWord is 64-bit on 64-bit iOS platform and it is 32-bit
> on 64-bit Windows platform.
>
> http://docwiki.embarcadero.com/RADStudio/XE8/en/What's_New#Changes_in_LongInt_and_LongWord_Size_for_64-bit_iOS_Platforms
>
Wow, that sound
On Tue, 29 Mar 2016, Dmitry Boyarintsev wrote:
On Tue, Mar 29, 2016 at 11:06 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
So why does the Object Pascal language have a Cardinal type? Why
couldn't LongWord be used instead?
In Delphi world LongWord is 64-bit on 64-bit iOS pl
On Tue, 29 Mar 2016, Graeme Geldenhuys wrote:
Hi,
Just curious. What is the history behind the Cardinal data type. As per
the FPC documentation, it is always mapped to the LongWord type. I
presume it is the same in Delphi.
It used to be opposite, if I recall correctly.
Longword used to be
On Tue, Mar 29, 2016 at 11:06 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> So why does the Object Pascal language have a Cardinal type? Why
> couldn't LongWord be used instead?
>
In Delphi world LongWord is 64-bit on 64-bit iOS platform and it is 32-bit
on 64-bit Windows platfor
In our previous episode, Graeme Geldenhuys said:
> Just curious. What is the history behind the Cardinal data type. As per
> the FPC documentation, it is always mapped to the LongWord type. I
> presume it is the same in Delphi.
Cardinal is the Wirthian designation for the default unsigned integer,
Hi,
Just curious. What is the history behind the Cardinal data type. As per
the FPC documentation, it is always mapped to the LongWord type. I
presume it is the same in Delphi.
So why does the Object Pascal language have a Cardinal type? Why
couldn't LongWord be used instead?
Regards,
- Graem
Bob Barry wrote:
> In the course of trying to compile fpc docs, I compared file msg2inc.pp
> of svn to that of the fpc-2.0.0 source tarball. No change whatsoever
> had been made to the code, but all the revision history has been
> removed since fpc-2.0.0. This means that users will henceforth be
In the course of trying to compile fpc docs, I compared file msg2inc.pp
of svn to that of the fpc-2.0.0 source tarball. No change whatsoever
had been made to the code, but all the revision history has been
removed since fpc-2.0.0. This means that users will henceforth be
unable to know who to tha
27 matches
Mail list logo
