Perhaps:
var
Buffer: array[0..255] of Byte = Default;
could be supported as shortcut for:
type
TByteBuffer = array[0..255] of Byte;
var
Buffer : TByteBuffer;
begin
Buffer := Default(TByteBuffer);
> -Original Message-
> From: fpc-devel On Behalf
> Of wkitt...@windstream.net
I don't think it's called anywhere in the source. It's called by the compiler
after the destructor has finished. The same way that InitInstance is run before
the constructor is called.
This way the memory for the object is already allocated before the first
constructor is run (and not only afte
From: fpc-devel On Behalf Of Marcos
Douglas B. Santos
Sent: Monday, 30 July 2018 22:25
To: FPC developers' list
Subject: Re: [fpc-devel] Why/how does the compiler have a non-trivial number
ofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 9:14 AM, Sven Barth via
type
TMyClass = class of TMyObject;
TMyObject = class
procedure InstanceMethod; //Self = TMyObject, can be virtual
class procedure ClassMethod; //Self = TMyClass, can be virtual
class procedure StaticClassMethod; static; //no Self, really just a global
procedure in a scoped na
> -Original Message-
> From: fpc-devel On Behalf Of
> Max Nazhalov via fpc-devel
> Sent: Tuesday, 10 July 2018 02:25
>
> Just one question: doesn't all this new stuff introduce another kind
> of mess during cross-compiling?
>
> E.g. some complex nested const.expr. "sin(cos(0.12345))" eva
with system
functions if the project is undergoing a full build).
Gareth
On Mon 09/07/18 01:21 , Dmitry Boyarintsev skalogryz.li...@gmail.com
<mailto:skalogryz.li...@gmail.com> sent:
On Sun, Jul 8, 2018 at 7:18 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote:
May
47 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote:
You are thinking about something like:
const
x = FunctionCall(42);
In which case, yes, the compiler could possibly see that as in implicit “check
if that function is pure”.
But “constant expressions” can also be som
it would fail right away.
From: fpc-devel On Behalf Of Dmitry
Boyarintsev
Sent: Monday, 9 July 2018 08:39
To: FPC developers' list
Subject: Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote:
Peopl
> -Original Message-
> From: fpc-devel On Behalf Of
> R0b0t1
> Sent: Monday, 9 July 2018 07:22
>
> There were some other comments touching on reasons for or against a
> keyword, and I apologize for not speaking to them precisely. But,
> this is why I would like to avoid a keyword - it is
> > Probably I am the only one who thinks that the code below is
> ridiculous...
> >
> > procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p:
> pchar;
> > len: longint);
> >var
> > s: ansistring;
> >begin
> > MaybeAddLinePrefix;
> > s:=''; // <<
> -Original Message-
> From: fpc-devel On Behalf Of
> Mattias Gaertner
>
> > [...] COM interface methods can't logically not be virtual,
>
> I think you are confusing things here. They can be virtual or not
> virtual in COM and CORBA.
I think a lot of people simply don't understand how
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Saturday, 30 June 2018 03:15
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> Okay, then why does the calling convention change matters so much?
>
> Maybe a COM/CORBA
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 03:11
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
>
> Please explain. Exactly how does it demonstrate this ?
>
> What is the expected o
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 01:07
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> what does this demo actually demonstrate other than that the compiler
> functions ?
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Friday, 29 June 2018 23:55
> To: fpc-devel@lists.freepascal.org
> Interface functions are always virtual and implemented by the
> actually instantiated class. The "override" keyword is neither
> allowed nor needed,
With
> -Original Message-
> From: fpc-devel On Behalf
> Of Mattias Gaertner
>
> You forgot the case where the loop was not entered:
>
> for i:=2 to 1 do ;
>
> i is now undefined.
>
> Same for
>
> for i in emptyset do ;
Both are cases of "the loop run to completion". Just because "completio
> It is *not* undefined when the loop is left with break or exit,
> that's the point. The ISO is not a very good reference for modern-
> ish Pascal.
I think based on both documented and observed behaviour, the following
definition would be appropriate:
The for-loop variable is undefined after th
From: fpc-devel On Behalf Of Wolf
Sent: Friday, 18 May 2018 07:27
This is the disassembly of function GetProcessorUsed: longint;inline;
Unless you advise me otherwise, I take the absence of function
GetProcessorUsed: longint;inline; mentioned anywhere in this screen print
that GetProc
> -Original Message-
> From: fpc-devel On Behalf
> Of Florian Klaempfl
> Sent: Monday, 30 April 2018 04:28
> > That ended up making things worse in some cases.
>
> Can you take a look at the generated machine code if delphi uses
> proper multi byte nops. If not, the align might make thi
> From: fpc-devel On Behalf
> Of J. Gareth Moreton
> For functions with a stack frame, either LEAVE or MOV RSP, RBP; POP
> RBP must precede it.
It's not quite that simple, at least under windows:
https://docs.microsoft.com/en-us/cpp/build/prolog-and-epilog
But yes, this documents that there can
> From: fpc-devel On Behalf Of J.
> Gareth Moreton
> Sent: Sunday, 29 April 2018 12:36
> As an extra point, removing the 'skip' check (i.e. cmp ax, $3FE0, jbe @@skip)
> removes 6 bytes from the code size and shaves about 2 to 3 nanoseconds off
> the execution time in most cases, and it could b
> -Original Message-
> From: fpc-devel On Behalf
> Of Florian Klämpfl
> So something like
>
> cmp edx, $4330
> jge @@zero
> cmp edx, $3FE0
> .align 16
> jbe @@skip
>
> might be much better.
That ended up making things worse in some cases.
Here
> -Original Message-
> From: fpc-devel On Behalf
> Of wkitt...@windstream.net
> > Code address:
> > Frac1: 00536430 (48)
> > Frac2: 00536480 (0)
> > Frac3: 005364D0 (80)
> > Frac4: 00536520 (32)
> > Frac5: 00536570 (112)
> > Frac6: 005365C0 (
> -Original Message-
> From: fpc-devel On Behalf
> Of Sven Barth via fpc-devel
> Thorsten, do you have tests that could go with the new
> Frac() implementation? Something simply that checks the results and
> does a Halt() if something is wrong would be sufficent.
I was using the followin
Basically that.
For doubles that don't fit into an Int64, any fraction is beyond the
significant number of digits that the double can store anyway, so 0 is the
valid and correct result for Frac in that case.
> -Original Message-
> From: fpc-devel On Behalf
> Of Mattias Gaertner
> Sent:
jmp @@skip
@@zero:
xorpd xmm0, xmm0
@@skip:
end;
Cheers,
Thorsten
From: fpc-devel On Behalf Of Thorsten
Engler
Sent: Saturday, 28 April 2018 15:37
To: 'FPC developers' list'
Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in
FPC
I’ve only tested it in Delphi, so you’ll have to convert it to the right syntax
for fpc, but either of these should do:
function Frac1(const X: Double): Double;
asm
.align 16
.noframe
movq rdx, xmm0
shl rdx, 32
and edx, $7FF0
cmp edx, $4330
-devel On Behalf
> Of Mattias Gaertner
> Sent: Saturday, 28 April 2018 03:39
> To: fpc-devel@lists.freepascal.org
> Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Broken frac
> function in FPC3.1.1 / Windows x86_64
>
> On Sat, 28 Apr 2018 02:48:14 +1000
> "Thorsten E
before you use the SSE instructions.
From: fpc-devel On Behalf Of Sven
Barth via fpc-devel
Sent: Saturday, 28 April 2018 03:33
To: FPC developers' list
Cc: Sven Barth
Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Broken frac function in
FPC3.1.1 / Windows x86_64
Thorsten E
3.1.1 / Windows x86_64
Thorsten Engler mailto:thorsten.eng...@gmx.net> >
schrieb am Fr., 27. Apr. 2018, 17:47:
> That's true for i386. But on x86_64 cvt(t)sd2si instuctions can
> deal with int64 range, if destination register is a 64-bit one.
You are still going to be
> That's true for i386. But on x86_64 cvt(t)sd2si instuctions can
> deal with int64 range, if destination register is a 64-bit one.
You are still going to be at least 960-bit short...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://list
Highest integer that fits in a Int64:
9223372036854775808
1e20:
1
Your Int is overflowing.
You can’t implement Frac by going through an Integer, that will never work.
Except if you have an integer that can hold 1.8E308 (which would be a 1024 bit
integer, or thereabo
> Note that "reporter" means that somebody's not a manager of the bug
> tracker. The designation covers a lot of people who are regular
> contributors to- and testers of- the core FPC code, and it's
> probably unfair for somebody to accuse one of them of trolling
> without considering that.
"repor
> But the only responses are by a reporter named Thaddy de Koning,
> which are for me totally useless and IMO he did miss the point.
It's not the first time the person has been less than helpful...
After looking through other issues he has commented on, I don't think he has
contributed anything b
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Saturday, 21 April 2018 21:39
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF
>
> Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny:
> > Sven (or anybody else), could you pl
A zero length dynamic array is represented by a nil pointer instead of a
pointer to the heap with the information that the length of the array is 0.
arr := nil;
is equivalent to:
SetLength(arr, 0);
And the nil assignment variant is pretty much ubiquitous in any code involving
dynamic arrays t
begin
>
> to me reads more accurately than
>
> if a is 3..10 then begin
>
> is the keyword is implies 1, just like the English language,
> whereas, in and are implies multiple or in this case range.
>
> > On Apr 14, 2018, at 9:02 AM, Thorsten Engler
> wrote:
>
my point, not arguing
> against, however, sharing a way I could see a value of it. Other
> than that, I am against...
>
> Ozz
>
> > On Apr 14, 2018, at 8:38 AM, Thorsten Engler
> wrote:
> >
> > Eh, Ozz? Did you actually read this thread?
> >
> >
;{… your if is comparisons …}
> end;
>
> This opens your method to be used for all types for param1.
>
> Ozz
>
> > On Apr 14, 2018, at 5:51 AM, Thorsten Engler
> wrote:
> >
> > I haven't checked out the changes you made to the compiler, so
> yo
nt: Saturday, 14 April 2018 19:03
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF
>
> On 14.04.2018 10:39, Thorsten Engler wrote:
> > How about following the same schema as with classes?
> >
> > If 1 is TMyEnum then
&g
How about following the same schema as with classes?
If 1 is TMyEnum then
//use hard cast here
> -Original Message-
> From: fpc-devel On Behalf
> Of Ondrej Pokorny
> Sent: Saturday, 14 April 2018 18:32
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Dangerous optimizat
rg] On
> Behalf Of Karoly Balogh (Charlie/SGR)
> Sent: Wednesday, 27 December 2017 03:43
> To: FPC developers' list
> Subject: Re: [fpc-devel] *** GMX Spamverdacht *** An extension of
> fpc language: the BASED construct
>
> HI,
>
> On Tue, 26 Dec 2017, Thorsten En
> Item: BYTE BASED ItemPtr;
Ignoring any other considerations for now, I would have at least used a
logical extension derived from already supported syntax:
Item: Byte absolute ItemPtr^;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
It's been a few years since I looked at the relevant code in the FPC
compiler and RTL, so my knowledge may be woefully out of date and/or
degraded by time, but IIRC:
- Copy was called with a source and target pointer and is responsible for
copying everything that's needed from the source to the ta
Hi,
Independent of what Delphi may support or not (and I agree that at a minimum in
$mode Delphi fpc should not require that IFDEF)…
in a modern compiler I would expect the generic type parameter to be optional
in this specific scenario and the compiler infer it from the type of the
par
Sven Barth wrote:
> In that specific example you would be right, but units are seldomly used
in
> isolation and once both unit1 and unit2 are used in more units it isn't
that
> clear (to the user) anymore which unit is initialized first.
I've always found the rules about this very clear in Delphi
> >> Are you sure with the strings?
> >
> > Yes. Any function that returns a string is supplied with one more
> > argument than it was declared. After calling the function, register
> > eax (which is used to contain the non-parameter result) is not used.
> > Here is a simple example:
>
> I'am n
> IMO borland screwed up here when they introduced IInterface =
> IUnknown.
No they didn't.
> It was IMo cleaner (and you can mix interface types)
There are no different "types" of interfaces in Delphi/Kylix. Even if there
were (like there are in FPC) you can never ever mix them.
> when they de
> > AObject as ICorbaInterface ?
>
> And how does the underlying code do the lookup in the
> interfaces table?
There is no "lookup" required for this. An "as" cast from object to
interface is only allowed (at least in Delphi) if the compiler can
statically at compiletime determine that the type
> I then wrote the following code to see if I could query for a
> supported interface.
>
> ...
> Well, the 'It worked' never appears and the cmd.Execute is
> never fired, so it's still a mystery how CORBA interfaces
> work. I'll see if Delphi help maybe mentions something.
You can assign fr
> I used RTTI to avoid defining an additional constant array of
> strings to have a unit output debug information for
> enumerated types. Otherwise I never did see any use of this.
>
> Could you give a real world example ?
Do you want a real world example for what better RTTI in general is us
> Private and protected are not your business in the first
> place, exposing it through RTTI or whatever is bad design. Public, OK.
The class itself should have access to that information. It can then use it
to e.g. stream the contents of all/some of it's private fields to/from a
stream.
> > No
> Easy: look up the method in RTTI - you'll get the address.
> Push all arguments on the stack (see Remobjects/Innerfuse
> PascalScript on how to do this, you need some assembler for
> it), and return result value.
>
> 2 days, tops.
You are funny.
First, the RTTI can only give you the address
> > Apart from the custom attributes and the Invoke, I don't see what
> > there is extra ?
Sorry, forgot: No RTTI whatsoever for pointer types.
Cheers,
Thorsten
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mail
> Apart from the custom attributes and the Invoke, I don't see
> what there is extra ?
No usable RTTI for records
No usable RTTI for arrays
No RTTI for private, protected and public(!) members (only published)
No usable RTTI for published methods (param and return types are just given
as strings,
> You forgot to complete: (...) but 99% of time the it just
> makes for useless bloat ;-)
The type information required to make this work is required anyway to a)
support the compilation of IL into machine code b) to allow verification of
type safety and c) support the garbage collector. As such
> I'm wondering if anybody has sufficient knowledge in this (I don't).
> Many developers that moved over to the dark side (.NET) using
> Delphi.Net or C# always rave about .Net Reflection and how
> much better it is to RTTI.
> Anybody actually know what is better? What limits are they
> talkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Actually this is the whole core of the matter: Microsoft's
> developers though they could save the task switch time by not
> storing the fpu.
>
> However, later they discovered it was a huge security leak,
> and added the fpu store code.
For wh
> Thanks. That seems to give me a clue. I have no idea what
> "creates a try" means but maybe I'll find out.
Should have been "an entry".
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
That is the result of what is happening. Most of it is done by the
library (the compiler can't do this by itself), and I am trying to use some
home-brew library functions here.
What I wanted to know is how the compiler does this (or how I can
find out what exactly it
> Here is an interesting reading:
> http://blogs.codegear.com/abauer/archive/2006/11/01/28852.aspx
> Maybe, the suggested FreeAndNil implementation can be
> usefull. See in comments.
Feel free to take it... But it's x86 specific asm code...
> BTW: Is the bellow afirmation also valid for fpc??
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> So instead you'd put a & ?
>
> Hardly more readable, I'd say. On the contrary. _ is used
> already, & is not.
And that's exactly the reason for using & and not _. It's not part of a
valid identifier.
If you look at:
&class
You see directly i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > The _ trick is widely used indeed, but imho those underscores make
> > code slightly less readable and also less aesthetic.
>
> Less readable than & ? What is the exact aesthetic ranking of
> [EMAIL PROTECTED]&*()_+ then? :-)
& is an proper esc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What could be a rood reason to escape a keyword? Why do you
> as programmer insist on the use of a keyword? Why do you
> insist that your property is called 'unit'? It's just
> obfuscating the code. With this you can mangle your code completely...
While playing around with the compiler source to familiarize myself I've
produced the attached patch. While I didn't set out to produce anything for
inclusion into the official codebase at least some of the changes might be
generally useful.
a) now modeswitch: m_ident_escape
Allows escaping of id
65 matches
Mail list logo
