On 11/21/2013 01:03 AM, Sieghard wrote:
the values you assign to the symbols (bit patterns, in this case) are
just convention. And don't matter as long as no calculation can return
a result outside of the base set.
Yep. And for casting them to bigger types (also implicitly when doing
On 11/19/2013 09:20 PM, Sieghard wrote:
Yep. The highest order bit in a number in the 2's complement encoding
is the sign bit.
Ok, let's look at it this way. Then, what's the value of this lone sign bit?
This is obvious.
Take a look at the predecessor of zero as done by the algorithm any
Hallo Michael,
Du schriebst am Wed, 20 Nov 2013 11:22:41 +0100:
Ok, let's look at it this way. Then, what's the value of this lone sign
bit?
This is obvious.
Then give the value.
Take a look at the predecessor of zero as done by the algorithm any
(modern) ALU does
That's simply the
On 11/18/2013 10:51 PM, Sieghard wrote:
Hallo Michael,
Could you please keep sufficient context so even a casual reader can
surmise what was meant? Thank you.
Nope.
That is what message threads do.
So you say a single bit can be signed?
Yep. The highest order bit in a number in the 2's
On 11/18/2013 11:03 PM, Sieghard wrote:
Even if it is larger than any of the other operands?
Yep. That is how it usually is done. Extend or sign-extend after the
operation if the target is larger, truncate if it is smaller.
Size extend always at runtime?
Yep (If necessary): Adding leading
Hallo Michael,
Du schriebst am Tue, 19 Nov 2013 12:40:11 +0100:
[about constant folding]
I sure hope you'll never get to working on a compiler (and fear you might
have already...)
--
--
(Weitergabe von Adressdaten, Telefonnummern u.รค. ohne Zustimmung
nicht gestattet, ebenso Zusendung von
Hallo Michael,
Du schriebst am Tue, 19 Nov 2013 12:32:40 +0100:
Could you please keep sufficient context so even a casual reader can
surmise what was meant? Thank you.
Nope.
Alright. I'll not respond to such garbage then.
So you say a single bit can be signed?
Yep. The highest order
On 11/15/2013 08:28 PM, Sieghard wrote:
_What_ bit count should it use if you use it within an expression
where operands of different
I already did mention this.
The obvious definition is
- neglect the size of the variable to store the result in
- for constants use the smallest bit count
Hallo Michael,
Du schriebst am Mon, 18 Nov 2013 12:30:09 +0100:
[min/max constants]
_What_ bit count should it use if you use it within an expression
where operands of different
I already did mention this.
The obvious definition is
Obvious to whom?
- neglect the size of the
Hallo Michael,
Du schriebst am Mon, 18 Nov 2013 11:25:36 +0100:
I.e. there's no difference, you say?
Could you please keep sufficient context so even a casual reader can
surmise what was meant? Thank you.
So you say a single bit can be signed?
Yep. This is how binary operations work in all
On 11/14/2013 09:28 PM, Sieghard wrote:
It might not be very neccessary if these types aren't compatible among each
other. Range checking has to be done only on coercion then, i.e. when
assigning a value cast from a - any - different type.
I understand that Martin is (IMHO) correctly assuming
On 11/14/2013 08:12 AM, Martin Schreiber wrote:
I don't like it.
Or with reserved words:
type
boolty = max: 8; //bool8
cardty = 0 to max: 8;//card8
intty = smin to smax: 8; //int8
charty = #max: 8;//char8
floatty = -.max to .max: 64; //flo64
On Friday 15 November 2013 09:37:29 Michael Schnell wrote:
On 11/14/2013 08:12 AM, Martin Schreiber wrote:
I don't like it.
Or with reserved words:
type
boolty = max: 8; //bool8
cardty = 0 to max: 8;//card8
intty = smin to smax: 8; //int8
charty =
On Friday 15 November 2013 09:33:32 Michael Schnell wrote:
On 11/14/2013 09:28 PM, Sieghard wrote:
It might not be very neccessary if these types aren't compatible among
each other. Range checking has to be done only on coercion then, i.e.
when assigning a value cast from a - any -
On Friday 15 November 2013 13:46:48 Michael Schnell wrote:
On 11/15/2013 10:21 AM, Martin Schreiber wrote:
That is not enough, keywords for boolean, character and float types are
necessary too.
Boolean: of course it needs to be possible to define 1 Bit booleans, so
using the same syntax
On 11/15/2013 02:08 PM, Martin Schreiber wrote:
How do you define char8/char16/char32 float32/float64 then if you don't want
to be forced to write the range?
Neither a bit limitation nor a range makes sense for floats.
Bits: you would need to specify a bit count as well for the Mantissa and
Compile time range checks already have a benefit.
==
Sure. Anyaway specifing (or assuming) bitlength is range check as well
:) Also if range is 2pwrN then overflow check may rely on CPU hardware
(checking its Overflow flag with a single JNO ASM ibstruction).
Hallo Martin,
Du schriebst am Fri, 15 Nov 2013 07:18:59 +0100:
could you do this if the values depend on some unspecified type?
Use something like max (boolty) or min (l)?
No, max (or another keyword) denotes maximum of the value with the given
bit count.
Fine. _What_ bit count should
Hallo Michael,
Du schriebst am Fri, 15 Nov 2013 09:33:32 +0100:
It might not be very neccessary if these types aren't compatible among
^^^
I understand that Martin is (IMHO) correctly assuming that range
restricted numerical
Hallo Martin,
Du schriebst am Fri, 15 Nov 2013 07:33:08 +0100:
type
boolty = :8;//bool8
cardty = :+8; //card8
intty = :-8;//int8
charty = :#8; //char8
What's the difference between # and +? Why do you think it should be
neccessary?
What's the difference between booln and
On 11/14/2013 09:16 AM, Michael Schnell wrote:
x6: unsigned : 2;
This syntax would allow for
x7: unsigned : 1024;
It would be a nice and consequent to provide arbitrary precision
integer arithmetic :-) .
-Michael
Hallo Michael,
Du schriebst am Thu, 14 Nov 2013 09:16:18 +0100:
Do you intend to implement runtime range checking with any of these
types ?
It might not be very neccessary if these types aren't compatible among each
other. Range checking has to be done only on coercion then, i.e. when
Hallo Martin,
Du schriebst am Thu, 14 Nov 2013 08:12:45 +0100:
The range could default to the maximum of the bit size:
...
What an awkward syntax.
My suggestion: don't.
I don't like it.
Thank you.
Or with reserved words:
You would have to devise a way to do the calculations, and you might
On Thursday 14 November 2013 21:39:05 Sieghard wrote:
Or with reserved words:
You would have to devise a way to do the calculations, and you might even
get forced to provide a way to request the actual values - how could you do
this if the values depend on some unspecified type?
Use
On Thursday 14 November 2013 08:12:45 Martin Schreiber wrote:
The range could default to the maximum of the bit size:
type
boolty = : 8; //bool8
cardty = 0 to: 8; //card8
intty = -to: 8;//int8
charty = #0 to: 8; //char8
floatty = -. to .: 64; //flo64
On 11/13/2013 02:27 PM, Martin Schreiber wrote:
therefore int64: 2; is invalid, i
I don't agree that this is sensible, but it's up to you.
how would you define a bitpacked record filed with two bits that is
intended to be handled as a signed integer ?
ty tr = ??;
r : tr;
i: int32
r.x2
On Wednesday 13 November 2013 15:39:27 Michael Schnell wrote:
On 11/13/2013 02:27 PM, Martin Schreiber wrote:
therefore int64: 2; is invalid, i
I don't agree that this is sensible, but it's up to you.
how would you define a bitpacked record filed with two bits that is
intended to be
On 11/13/2013 05:19 PM, Martin Schreiber wrote:
type
recordty = bitpacked record
x2: -2 to 1;
x3: -2 to 1: 2; //same as above
x4: 0 to 5: 4; //subrange in 4 bits
end;
While I don't like to be forced to calculate the range manually from the
intended bit count, this of
On Wednesday 13 November 2013 17:29:11 Michael Schnell wrote:
On 11/13/2013 05:19 PM, Martin Schreiber wrote:
type
recordty = bitpacked record
x2: -2 to 1;
x3: -2 to 1: 2; //same as above
x4: 0 to 5: 4; //subrange in 4 bits
end;
While I don't like to be forced to
Hallo Martin,
Du schriebst am Wed, 13 Nov 2013 06:47:11 +0100:
On Tuesday 12 November 2013 20:24:07 Sieghard wrote:
[...]
As said above, that depends on the implementation or rather the likings
of the implementor. If more people than just the implementor are to use
it, it just needs to
On Wednesday 13 November 2013 17:29:11 Michael Schnell wrote:
On 11/13/2013 05:19 PM, Martin Schreiber wrote:
type
recordty = bitpacked record
x2: -2 to 1;
x3: -2 to 1: 2; //same as above
x4: 0 to 5: 4; //subrange in 4 bits
end;
While I don't like to be forced to
On 11/11/2013 11:00 AM, Ivanko B wrote:
That signedness isn't more than just a old (and not obvious) assumption.
Thus -1 is greater than 1 as the representation of -1 is all bits set ?
-Michael
--
November Webinars for
Hallo Martin,
Du schriebst am Tue, 12 Nov 2013 08:33:29 +0100:
The C-like syntax
FIELDNAME ':' FIELDTYPE [':' BITSIZE] ';'
is accepted?
It's much more broadly used than just with C. In fact, C seems to have it
adopted only recently. You might use alternate delimiters, though.
Is a
Hallo Martin,
Du schriebst am Tue, 12 Nov 2013 10:19:38 +0100:
Is a record with BITSIZE automatically bitpacked?
I gather this does make sense.
I am not sure. I don't like implicit things much.
That's right - but bitsize specifications aren't really useful without
packing. But you
Hallo Michael,
Du schriebst am Tue, 12 Nov 2013 09:30:11 +0100:
On 11/11/2013 11:00 AM, Ivanko B wrote:
That signedness isn't more than just a old (and not obvious) assumption.
Thus -1 is greater than 1 as the representation of -1 is all bits set ?
You may define an ordering relation where
Hallo Martin,
Du schriebst am Tue, 12 Nov 2013 08:09:42 +0100:
MSEide editor is not limited to fixed pitch fonts so column blocks may be
Column blocks simply don't make sense with proportional fonts.
Source code can in principle be written with proportional fonts, but even
that doesn't make
On Tuesday 12 November 2013 20:24:07 Sieghard wrote:
[...]
As said above, that depends on the implementation or rather the likings of
the implementor. If more people than just the implementor are to use it, it
just needs to be documented. After all, endiandness issues are notoriously
tricky,
On 11/08/2013 05:32 PM, Martin Schreiber wrote:
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
So why invent new names instead of using the really well known names
such as uint8_t, int16_t
-Michael
--
On 11/09/2013 08:27 PM, Sieghard wrote:
C-ish type
IMHO C-ish stuff only should be avoided if there is not already a really
decent alternative in well known Pascal dialects.
In fact C-ish naming _should_ be used if the most well known (GNU) C
dialect or the most well known C-Libraries (glibc
On 11/08/2013 07:46 PM, Martin Schreiber wrote:
One probably would write
Register = bitpacked RECORD
Field_1: $..$007f;
Field_2: $..$0003;
Field_3: $..$001f;
Field_4: $..$0001;
Field_5:
So why invent new names instead of using the really well known names
such as uint8_t, int16_t
==
Sounds reasonable.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance
Why not something like
bitpacked RECORD
Filed_1: integer: 7;
Filed_2: integer: 2;
Filed_3: integer: 5;
Filed_4: integer: 1;
Filed_5: integer: 1;
end
===
For non-2^N ranging.
This is not limited on a single hardware Word, but can define
to arbitrary length memory areas.
==
Really, it's important for bitpacked data.
--
November Webinars for C, C++, Fortran Developers
Accelerate
Definitions like
-
var1: 0..22;
or
var1: integer from 0 to 22;
might by useful multiarch programming since compiler may select needed
internal (arch-specific) type - emulated 64bit even for 8-bit arch for
instance so that programs work in
On Monday 11 November 2013 10:02:39 Michael Schnell wrote:
On 11/08/2013 05:32 PM, Martin Schreiber wrote:
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
So why invent new names instead of using the really well known names
such as uint8_t, int16_t
Because if there is a u for
But int is already signed (as Sieghard pointed out) so sint is bad.
==
That signedness isn't more than just a old (and not obvious) assumption.
--
November Webinars for C, C++, Fortran Developers
Accelerate
On 11/11/2013 10:53 AM, Martin Schreiber wrote:
Because if there is a u for unsigned there must be a s for signed
(orthogonality). But int is already signed (as Sieghard pointed out)
so sint is bad.
While I do see you point, IMHO this is trading strictness vs
readability, and thus a matter of
On 11/11/2013 10:34 AM, Ivanko B wrote:
Why not something like
bitpacked RECORD
Filed_1: integer: 7;
Filed_2: integer: 2;
Filed_3: integer: 5;
Filed_4: integer: 1;
Filed_5: integer: 1;
end
===
For non-2^N ranging.
I don't
On Monday 11 November 2013 11:42:58 Michael Schnell wrote:
On 11/11/2013 10:53 AM, Martin Schreiber wrote:
Because if there is a u for unsigned there must be a s for signed
(orthogonality). But int is already signed (as Sieghard pointed out)
so sint is bad.
While I do see you point, IMHO
On 11/11/2013 12:15 PM, Martin Schreiber wrote:
card32, int32 is based on Pascal types and unambiguous too. cardinal,
integer - recommended type, card, int - size of the CPU registers.
Yep.
As said: mater of taste. So it's up to you.
-Michael
Hallo Ivanko,
Du schriebst am Mon, 11 Nov 2013 15:00:12 +0500:
But int is already signed (as Sieghard pointed out) so sint is bad.
==
That signedness isn't more than just a old (and not obvious) assumption.
It's a mathematical convention. The set of integer numbers usually
comprises
On Monday 11 November 2013 21:38:18 Sieghard wrote:
BTW, I like to use copy paste for such repetitive stuff as declarations
or such. When I have to create a table, I might even change editors when
there's one around that can do column block manipulations, build the table,
and possibly switch
On Monday 11 November 2013 22:25:07 Sieghard wrote:
My previous egregious example
Register = RECORD
Field_1: 0..77;
Field_2: 1..3;
Field_3: 5..25;
Field_4: 111..112;
Field_5: -2..-1;
END;
might
Hallo Martin,
Du schriebst am Sat, 9 Nov 2013 20:31:58 +0100:
Your suggestion how to define the bit size of a type?
Well, specify the requested number of bits together with the bitfield's
identifier. There's a host of notations in use, e.g. the C-ish
name: bits, or a functional expression name
Hallo Martin,
Du schriebst am Sun, 10 Nov 2013 08:00:07 +0100:
After all, a programmer should not type most of the time, but _think_
^
about the structures his typing is to describe. Shouldn't he?
BTW, how does your
On Sunday 10 November 2013 14:14:26 Sieghard wrote:
Hallo Martin,
Du schriebst am Sun, 10 Nov 2013 08:00:07 +0100:
After all, a programmer should not type most of the time, but _think_
^
about the structures his
Hallo Martin,
Du schriebst am Sun, 10 Nov 2013 15:47:30 +0100:
Can you describe how typing easy with your editor program works so it
is as easy to enter cardinal32 as typing card32?
Yes. It doesn't, as I don't _want_ to have such a feature. I _do_ want to
type myself, without interference
On Monday 11 November 2013 00:07:54 Sieghard wrote:
Hallo Martin,
Du schriebst am Sun, 10 Nov 2013 15:47:30 +0100:
Can you describe how typing easy with your editor program works so it
is as easy to enter cardinal32 as typing card32?
Yes. It doesn't, as I don't _want_ to have such a
So card32 instead of cardinal32
=
Sure, all shortened types should have similar length shortened parts :
integer = int
cardinal = card
word = (no need to shorten)
--
November Webinars for C, C++, Fortran
Hallo Martin,
Du schriebst am Fri, 8 Nov 2013 19:46:05 +0100:
Register = bitpacked RECORD
Field_1: $..$007f;
Field_2: $..$0003;
Field_3: $..$001f;
Field_4: $..$0001;
Field_5: $..$0001;
On Saturday 09 November 2013 19:56:55 Sieghard wrote:
Disregarding that it's identical to my example, I don't think it looks any
_better_, it in fact adds a lot of fuzz (the $ signs and the many zeros)
that effectively hide the real information from immediate recognition.
I still maintain
Hallo Martin,
Du schriebst am Fri, 8 Nov 2013 19:23:43 +0100:
Currently I prefer cardinal - cardXX and integer - intXX because of the
Pascal types. It would be even better if the two had same count of
characters. carXX? :-
Adding confusion to obscurity? Why insist on foreshortening
Hallo Martin,
Du schriebst am Fri, 8 Nov 2013 06:46:55 +0100:
You might opt to spell it out as integer, I think.
That is not better IMHO. uint, sint - uinteger, sinteger.
What about unum, snum?
I rather thought about using integer as a name for the signed int C-ish
type _only_. The
On Saturday 09 November 2013 20:37:11 Sieghard wrote:
Which means, there's not much to gain with foreshortened identifiers, when
the editors make typing easy anyway.
After all, a programmer should not type most of the time, but _think_ about
the structures his typing is to describe. Shouldn't
On Friday 08 November 2013 08:56:23 Ivanko B wrote:
two syntaxes for same thing
Which should be avoided.
---
Why ? Just shortcuts (short/simplified notations) for user convinience :)
From the Wiki:
The design goals
1. Simple.
Reduce the language concepts
Reduce the language concepts one has to learn to the minimum
==
Typedefs aren't language complications - they just use the language.
Shortcuts are very handy for instance @ instaed of addr()/
--
November
Ranging for integers may also help to build not yet hardware suported types,
like :
-
var
i1: integer from 0 to 2^^256; // 2prw256
i2: integer:256;
---
Sure, with emulated access to them.
--
On 11/08/2013 11:30 AM, Ivanko B wrote:
Ranging for integers may also help to build not yet hardware suported types,
Somewhat similar, but IMHO by far not as useful as Records defining
bit-field variables.
-Michael
--
On Friday 08 November 2013 06:46:55 Martin Schreiber wrote:
On Friday 08 November 2013 00:08:09 Sieghard wrote:
Hallo Martin,
Du schriebst am Thu, 7 Nov 2013 06:27:46 +0100:
BTW, int(eger) already does imply signedness, usually
(mathematically).
Yup. What could be used instead
On Friday 08 November 2013 17:32:56 Martin Schreiber wrote:
You might opt to spell it out as integer, I think.
That is not better IMHO. uint, sint - uinteger, sinteger.
What about unum, snum?
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
Or card8, card16, card32, card64,
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
MS Or card8, card16, card32, card64, int8, int16, int32, int64?
MS :-)
Why ordXX, not wordXX? Look at Context language by Andrey Hohlov.
--
WBR,
Vladislav Javadov
On Friday 08 November 2013 19:14:31 Vladislav Javadov wrote:
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
MS Or card8, card16, card32, card64, int8, int16, int32, int64?
MS :-)
Why ordXX, not wordXX? Look at Context language by Andrey Hohlov.
We need a base name for unsigned
On Friday 08 November 2013 00:39:58 Sieghard wrote:
Suppose there's some part having a 16 bit register that's subdivided into 5
fields, bits 0 through 6, 7...8, 9...13, 14 and 15 (the latter are 1-bit
fields, of course).
Your construct might then look like:
Register = RECORD
Why do you suggest word for unsigned number?
==
word - longword(=dword = cardinal) - qword..
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable
On Friday 08 November 2013 20:19:54 Ivanko B wrote:
Why do you suggest word for unsigned number?
==
word - longword(=dword = cardinal) - qword..
Yes, but word in Pascal is fixed 16bit. I more like card - cardinal.
Martin
Cardinal is 32 bits only as long as word expresses unsiged types
of 2,4,8 so on bytes length.
That's currently in Pascal : *int=signed and *word=unsigned (with
aliaces shortint=int8,integer=int16, byte=1/2word,
cardinal=dword).
On Friday 08 November 2013 22:48:28 Ivanko B wrote:
Cardinal is 32 bits only as long as word expresses unsiged types
of 2,4,8 so on bytes length.
Not in TP mode. From Delphi 7 manual:
The generic integer types are Integer and Cardinal.
Martin
integer = sint32;
What for ? How about longest harware supported type (found by compiler
automatically for target architcture ) ?
--
November Webinars for C, C++, Fortran Developers
Accelerate application
On Thursday 07 November 2013 09:53:48 Ivanko B wrote:
integer = sint32;
What for ? How about longest harware supported type (found by compiler
automatically for target architcture ) ?
{$if REGISTERSIZE = 64}
integer = sint64;
{$else}
integer = sint32;
{endif}
Why do you
Why do you want that integer has different sizes on different platforms?
==
The BASE (no user attention about range) integer. Not ranged one.
{$if REGISTERSIZE = 64}
==
User attention about range. Knowing underlying arch. Can be (and will
be) done by compliler
On Thursday 07 November 2013 10:24:38 Ivanko B wrote:
Why do you want that integer has different sizes on different platforms?
==
The BASE (no user attention about range) integer. Not ranged one.
The user *must* have an attention about range. So this type can not be the
base.
On Thursday 07 November 2013 14:01:07 Ivanko B wrote:
The user *must* have an attention about range. So this type can not be the
base.
Why ? Both my large projects PODPISKA ROZNITSA don't care about
value ranges - they just rely on the default INTEGER type LONGINT (or
Both my large projects PODPISKA ROZNITSA don't care about
value ranges - they just rely on the default INTEGER type LONGINT (or
CARDINAL for unsigned data) fits any data of these projects.
Compile in default TP mode and you will be surprised. ;-)
What for ? It's hardly
Hallo Martin,
Du schriebst am Thu, 7 Nov 2013 07:10:56 +0100:
BTW, float sounds awfully C-ish to me. No reals any more, really?
Because there could be a complex datatype which has two float fields.
Oh, I see, you think of the real/imaginary components. Indeed, that mighht
be distracting to
On Friday 08 November 2013 00:08:09 Sieghard wrote:
Hallo Martin,
Du schriebst am Thu, 7 Nov 2013 06:27:46 +0100:
BTW, int(eger) already does imply signedness, usually
(mathematically).
Yup. What could be used instead of int?
You might opt to spell it out as integer, I think.
That
On Friday 08 November 2013 08:01:05 Ivanko B wrote:
by subrange should be changed to define signed/unsigned and bit count.
or extended to define :) Anyway specifying bitcount even defining as
typesize are ranging as well but rougher (inexact).
That means two
two concepts
===
If handled in same manner by compiler - two syntaxes for same thing ?
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable
two syntaxes for same thing
Which should be avoided.
---
Why ? Just shortcuts (short/simplified notations) for user convinience :)
--
November Webinars for C, C++, Fortran Developers
Accelerate application
For new language, why not to leave only one size per type - of max
register length of target arch (may be controled by compiler options)
?
X86_32 X86_64: bool(=bool32), uint(=uint64), sint(=sint64),
float(=float64) ...
ARM-32 boxes: bool(=bool32), uint(=uint32), sint(=sint32), float(=float32)
On Wednesday 06 November 2013 11:42:22 Ivanko B wrote:
For new language, why not to leave only one size per type - of max
register length of target arch (may be controled by compiler options)
?
Why?
--
November
On Wednesday 06 November 2013 12:04:21 Ivanko B wrote:
To be readable as letter :) So that user don't have to think worry
about value limitations ( AV in runtine) unless they (range checks)
are defined explicitly by some keyword/clause (a new compiler feature
BTW).
If you like you can define
type
integer = sint64;
===
Not portable between architectures.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques
On Wednesday 06 November 2013 12:19:46 Ivanko B wrote:
type
integer = sint64;
===
Not portable between architectures.
Isn't the idea So that user don't have to think worry
about value limitations?
Otherwise write
type
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer = sint32;
{$endif}
==
It's the deal of compiler swicthes which should be done automatically
by build environment.
--
November Webinars for
var
i1: integer from 1 to 10; // assigned to UINT8 by compiler
i2: cardinal; // assigned to UINT(max_len) by compiler
i3: integer; // assigned to SINT(max_len) by compiler
begin
i1:= 0; // compile time error
i1:= 12; // compile time error
i1:= 3; // OK
On Wednesday 06 November 2013 12:41:25 Ivanko B wrote:
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer = sint32;
{$endif}
==
It's the deal of compiler swicthes which should be done automatically
by build environment.
You miss the point. In FPC one has to
Run-time range checking (it can slow down target program) might be
switched on/of by a compiler option or $ifdef.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable
In daily work the size of the base types should be unambiguously visible.
==
How about its replacement by explicit range defining/checking
(possibly with the mention reversal typedef for simplier syntax) ?
The same + some more (compiler) functionality.. And reading letter
by default
On Wednesday 06 November 2013 13:22:31 Ivanko B wrote:
In daily work the size of the base types should be unambiguously visible.
==
How about its replacement by explicit range defining/checking
(possibly with the mention reversal typedef for simplier syntax) ?
The same + some more
What is wrong to read in a letter the word sint32 instead of integer?
===
Means CPU architecture knowledge etc special skills. Specifying a
range instead is more meaningful. And the range supplies all needed
info to the compiler so that it makes proper
1 - 100 of 114 matches
Mail list logo
