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. Such stuff
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
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 point.
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 same code on
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),
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),
| 2 *
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.
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 actually do this in a
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 ever use enums
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,
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 there
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
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
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
14 matches
Mail list logo
