Ales Katona wrote:
> I think that pascal typesystem requires a bit overhaul when it comes to
> integers.
>
> First of all Integer should be size independent, that is, xy bits
> depending on the platform. All others should be specific.
I agree with an application wide integer/cardinal type, but t
> Vinzent Hoefler wrote / nap?sal (a):
> >>In a few years when 64 bits are normal, what will cardinal become?
> >>who knows..
> >>
> >>
> >
> >That's why Pascal has range types. Define the range you need, and don't
> >use "just some type" which has the range you think you will need.
> >
> And
Vinzent Hoefler wrote / napísal (a):
On Sunday 17 April 2005 10:45, Ales Katona wrote:
First of all Integer should be size independent, that is, xy bits
depending on the platform.
I second that.
Second, we should "force people in a friendly way" to use more
readible names like:
sint32,
On Monday 18 April 2005 10:32, Marco van de Voort wrote:
> > On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > >
> > > I typically use enums. They suffer from the same to-disk problem
> > > though, but that can be remedied using the proper directives.
> >
> > Well, I don't think I will e
> On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > Well, and I actually do this in a major app at work. Not on
> > > everything, of course, but it can heavily simplify some stuff, for
> > > instance because I can use the Low and High-attribu^Wfunctions on
> > > the type which is safer
On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > > That's why Pascal has range types. Define the range you need,
> > > > and don't use "just some type" which has the range you think
> > > > you will need.
> > >
> > > I actually tried this in a major app at work.
> >
> > Well, and I a
On Monday 18 April 2005 08:46, Jonas Maebe wrote:
> They are, but ptrint and ptruint are just regular types. The compiler
> cannot know they are properly defined in each RTL unit, and you can
> override them to be something completely different. That's why it
> gave and still gives a warning.
Yep
> > > That's why Pascal has range types. Define the range you need, and
> > > don't use "just some type" which has the range you think you will
> > > need.
> >
> > I actually tried this in a major app at work.
>
> Well, and I actually do this in a major app at work. Not on everything,
> of course
> Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
> PtrUInt/Address-Conversion isn't portable:
>
> | WriteLn ('Runtime error ', ExitCode,
> | ' at 16#',
> | SysUtils.IntToHex (PtrUint(ErrorAddr),
> |
On 18 apr 2005, at 10:40, Vinzent Hoefler wrote:
Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
PtrUInt/Address-Conversion isn't portable:
| WriteLn ('Runtime error ', ExitCode,
| ' at 16#',
| SysUtils.IntToHex (PtrUint(ErrorAddr),
|
On Monday 18 April 2005 07:29, Peter Vreman wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> >> First of all Integer should be size independent, that is, xy bits
> >> depending on the platform.
> >
> > I second that.
>
> This is useless. Your code
That doesn't matter. If I'd want the
On Monday 18 April 2005 07:22, Marco van de Voort wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> > > First of all Integer should be size independent, that is, xy bits
> > > depending on the platform.
> >
> > I second that.
>
> It is now. It just happens to be the same.
:) Ok, good
Some notes.
> This is useless. Your code and runtime checks will then vary for the kind
> of processor (32 or 64bit) you are compiling for. Even 'int' in C is
> always 4 bytes.
This is not true. Most recent 64-bit machines indeed are LP64, but e.g.
several Crays are ILP64. Moreover, the C stand
> On Sunday 17 April 2005 10:45, Ales Katona wrote:
>
>> First of all Integer should be size independent, that is, xy bits
>> depending on the platform.
>
> I second that.
This is useless. Your code and runtime checks will then vary for the kind
of processor (32 or 64bit) you are compiling for. Ev
> On Sunday 17 April 2005 10:45, Ales Katona wrote:
> > First of all Integer should be size independent, that is, xy bits
> > depending on the platform.
>
> I second that.
It is now. It just happens to be the same. However keep in mind that the
strict integer=wordsize bond of the past no longer g
On Sunday 17 April 2005 10:45, Ales Katona wrote:
> First of all Integer should be size independent, that is, xy bits
> depending on the platform.
I second that.
> Second, we should "force people in a friendly way" to use more
> readible names like:
> sint32, uint64, etc. than "cardinal"
No. Su
Ales Katona wrote:
I think that pascal typesystem requires a bit overhaul when it comes
to integers.
First of all Integer should be size independent, that is, xy bits
depending on the platform. All others should be specific.
Second, we should "force people in a friendly way" to use more
readib
Jonas Maebe wrote / napísal (a):
On 17 Apr 2005, at 09:38, Yury B. wrote:
for 32-bit x86... or does 64-bit platform also uses 32-bit integers
as default, so that longint would be good?
JM> It would break a lot of existing code if we did that. You can
perfectly
JM> define integer to be whatev
On 17 Apr 2005, at 09:38, Yury B. wrote:
for 32-bit x86... or does 64-bit platform also uses 32-bit integers
as default, so that longint would be good?
JM> It would break a lot of existing code if we did that. You can
perfectly
JM> define integer to be whatever you want yourself.
I want a kin
Hello Jonas,
Saturday, April 16, 2005, 10:33:06 PM, you wrote:
>> for 32-bit x86... or does 64-bit platform also uses 32-bit integers
>> as default, so that longint would be good?
JM> It would break a lot of existing code if we did that. You can perfectly
JM> define integer to be whatever
On 16 Apr 2005, at 17:04, Yury B. wrote:
Why integer is 16-bit in default (FPC) mode?
It's ok to define it as 16-bit in BP-compatibility mode, but in FPC
it should be like in delphi - natural to the platform, i.e. 32-bit
for 32-bit x86... or does 64-bit platform also uses 32-bit integers
Hello fpc-devel,
Why integer is 16-bit in default (FPC) mode?
It's ok to define it as 16-bit in BP-compatibility mode, but in FPC
it should be like in delphi - natural to the platform, i.e. 32-bit
for 32-bit x86... or does 64-bit platform also uses 32-bit integers
as default, so that lon
22 matches
Mail list logo