To clarify my stance on all of this... when enumerated types are
entirely internal within a program, then there is indeed no need for
constant range checks like with case blocks because the value is almost
always guaranteed to be valid unless you do something weird like Pointer
typecasting,
On 03/07/2019 01:13, Ondrej Pokorny wrote:
On 02.07.2019 23:34, Jonas Maebe wrote:
As to your patch itself: why do you not directly compare the
tconstexprint values directly, and use the svalue/uvalue fields instead?
Because I missed that they can be directly compared directly.
I dare say,
On 02.07.2019 23:34, Jonas Maebe wrote:
On 02/07/2019 22:31, Ondrej Pokorny wrote:
var
Value: TEnumType;
begin
Value := TEnumType(-1);
IsValid := Value is TEnumType; // IsValid gains false
The compiler may not do any optimizations here (like return always true
if the left side value
On 02.07.2019 23:34, Jonas Maebe wrote:
On 02/07/2019 22:31, Ondrej Pokorny wrote:
This is similar to the object-is operator that gets evaluated as well
even if the type of the left-side value is the type at right side:
var
Value: TPersistent;
begin
Value := TPersistent(TObject.Create);
The main problem, Jonas, is that there will be times where the
enumeration will take on a value that is outside of its domain, and
often through ways that we cannot help, such as external data being in
the wrong format. I'm all for compiler optimisations assuming that the
value is in range
Am 02.07.2019 um 20:54 schrieb Ondrej Pokorny:
> The conversation is more than a year old and I already posted a patch -
> also more than a year ago. I haven't received any feedback from the
> compiler developers since I uploaded the patch. Maybe you will have more
> luck.
FWIW: I've been
On 02/07/2019 22:31, Ondrej Pokorny wrote:
> var
> Value: TEnumType;
> begin
> Value := TEnumType(-1);
> IsValid := Value is TEnumType; // IsValid gains false
>
> The compiler may not do any optimizations here (like return always true
> if the left side value is the enum type at the right
That is exactly how it should behave, because the left-side value may
not be valid, and the is operator is meant to help confirm that.
In the meantime, I've updated your patch to work with the current trunk:
https://bugs.freepascal.org/view.php?id=33603#c117040
Gareth aka. Kit
On
On Mon, 2019-07-01 at 21:52 +0200, Sven Barth via fpc-devel wrote:
> Hello together!
>
> For a project at work I need to run 16-bit x86 code on a bare x86
> hardware (more precisely a 8086 VM). Considering that i8086-embedded
> had
> been added to FPC nearly exactly 3 years ago I though I'd
On 02.07.2019 21:48, J. Gareth Moreton wrote:
I should probably test this myself, but if you, say, read a value from
a file directly into a variable of type TEnumType, will your patch
return False for "if (Value is TEnumType) then" if Value, despite
being TEnumType, contains an invalid value?
I should probably test this myself, but if you, say, read a value from a
file directly into a variable of type TEnumType, will your patch return
False for "if (Value is TEnumType) then" if Value, despite being
TEnumType, contains an invalid value? No problem if it isn't, just that
you would
I like the idea of using existing operators since that avoids extra
intrinsics and the risk of breaking code that uses a function with the
same proposed name.
The "as" operator is possible for assignment, although I'm not the
biggest fan of run-time errors (although they have their uses).
On 02.07.2019 20:57, Michael Van Canneyt wrote:
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
On 02.07.2019 19:53, J. Gareth Moreton wrote:
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help
On 02.07.2019 21:15, Michael Van Canneyt wrote:
Don't forget to check the post of Ondrej.
Personally, I think using 'as' to convert an integer to an enum with
range
check is still the best approach. It does not require new intrinsics (far
too many of those already) and does what it says. To
Don't forget to check the post of Ondrej.
Personally, I think using 'as' to convert an integer to an enum with range
check is still the best approach. It does not require new intrinsics (far
too many of those already) and does what it says. To simply check if an
integer is a valid enum, I
Aah, thank you.
On 02/07/2019 19:56, Michael Van Canneyt wrote:
On Tue, 2 Jul 2019, J. Gareth Moreton wrote:
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help patch up this problem.
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
On 02.07.2019 19:53, J. Gareth Moreton wrote:
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help patch up this problem.
The conversation is
On Tue, 2 Jul 2019, J. Gareth Moreton wrote:
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help patch up this problem.
As for the Delphi problem, it's second-hand information I heard
On 02.07.2019 19:53, J. Gareth Moreton wrote:
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help patch up this problem.
The conversation is more than a year old and I already posted a
I don't recall a conversation where such an intrinsic is seen as
desirable, but if such a construct is desirable, then that's a good
thing since it will help patch up this problem.
As for the Delphi problem, it's second-hand information I heard from a
friend who uses Delphi at work and
On Tue, 2 Jul 2019, J. Gareth Moreton wrote:
Hi everyone,
So there have been a lot of issues going back and forth regarding case blocks
when dealing with enumerations and what happens if the enum falls outside the
valid range of values for some reason, because the internal domain check is
Hi everyone,
So there have been a lot of issues going back and forth regarding case
blocks when dealing with enumerations and what happens if the enum falls
outside the valid range of values for some reason, because the internal
domain check is sometimes omitted for performance reasons, since
Op 2019-06-27 om 15:12 schreef George Bakhtadze:
Volatile (I assume you mean a C-like volatile) is usable in very rare
special cases. Such as work with hardware buffers.
(in embedded targets it is not that rare. E.g. variables/state shared
between interrupts handlers and main program)
Really, insofar as x86 is concerned, the only ones that are guaranteed
to be atomic are, I think, the ordinal types, but that still leaves
problems of code such as the following:
if GlobalCounter = 10 then
begin
DoSomething;
Break;
end else
Inc(GlobalCounter);
If two threads are running
Thank you Michael for pointing me to the headers - the problem was
indeed the missing headers.
INDY sends these 2 headers automatically:
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent=Mozilla/3.0 (compatible; Indy Library)
When I add both of them to
> On Jul 2, 2019, at 3:20 AM, Ondrej Pokorny wrote:
>
> This code is never executed for an array property. The "[" for an array
> property is processed directly in handle_propertysym:
>
> procedure handle_propertysym(propsym : tpropertysym;st : TSymtable;var p1
> : tnode);
> var
>
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
On 02.07.2019 09:10, Michael Van Canneyt wrote:
I had a quick peek in the compiler sources.
In pexpr.pas, before processing the [, the compiler calls this:
{ we need the resultdef }
do_typecheckpass_changed(p1,nodechanged);
In my
On 02.07.2019 09:10, Michael Van Canneyt wrote:
I had a quick peek in the compiler sources.
In pexpr.pas, before processing the [, the compiler calls this:
{ we need the resultdef }
do_typecheckpass_changed(p1,nodechanged);
In my opinion, this routine will/should error out if
On 02.07.2019 08:17, Michael Van Canneyt wrote:
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
I happened to study this part of FPC code back in 2015 when I worked
on issue #28820. I can say that FPC directly transfers indexed
properties
Stop... How does FPC decide it is an indexed property ?
Hi,
Am 28.06.19 um 11:24 schrieb George Bakhtadze:
If FPC somehow guarantees that a global field (even only of simple
types) can be atomically read and written from any thread for ANY
platform that is a very strong guarantee and worth mention in
documentation.
btw, how would you do that if
On Tue, 2 Jul 2019, Michael Van Canneyt wrote:
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
On 01.07.2019 23:25, Michael Van Canneyt wrote:
I understand. But all depends on how the compiler parses and evaluates
this.
Let me put brackets to make it more clear: is
MyTest.StringArray[i]
On Tue, 2 Jul 2019, Ondrej Pokorny wrote:
On 01.07.2019 23:25, Michael Van Canneyt wrote:
I understand. But all depends on how the compiler parses and evaluates
this.
Let me put brackets to make it more clear: is
MyTest.StringArray[i]
parsed & evaluated as
(MyTest.StringArray)([(i)])
32 matches
Mail list logo
