> On Apr 24, 2024, at 4:59 PM, Bart via fpc-devel
> wrote:
>
> In such instances it would really be helpfull if you could just
> overload the assignment operator like:
> operator := (Src: TRec): TRec;
> begin
> Result := AssignRec(Src);
> end;
I agree this seems reasonable but maybe the
> On Feb 16, 2024, at 4:06 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
>
> I don't have HTML support in my mail program. My mail program is text based.
>
> HTML in mail is for 99.99% of cases a waste of bandwidth. I care about the
> content of a message, not about the markup.
which
His email looks good to me. Much easier to see code with formatting.
Who doesn't have email clients with HTML support these days? I can't imagine
how old your system must be to not have this.
> On Feb 15, 2024, at 4:10 PM, Tomas Hajny via fpc-devel
> wrote:
>
> Apart from that, I'd suggest
> On Jan 30, 2024, at 8:53 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> 'yes I do' what exactly ?
>
> I thought I understood after your previous mail. Now I read your sentence as
> an argument for not having a "final" at all, so this is again confusing for
> me :/
I stepped in the
> On Jan 30, 2024, at 8:01 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> It's probably more correct to say that you don't want there to be an override
> in a descendent class. Offhand I can't think of a use-case, but why not...
yes you do, because the descendent doesn't know the class
> On Jan 30, 2024, at 3:56 AM, Michael Van Canneyt via fpc-devel
> wrote:
>
> Unfortunately I still don't understand after your explanation what adding
> 'final' is supposed to accomplish. It may well be legitimate, but I have
> currently no opinion as I don't understand it.
Final means
> On Jan 29, 2024, at 3:53 PM, Sven Barth via fpc-devel
> wrote:
>
> A person that overrides virtual methods does not always have control over
> whether the method had been declared as virtual. With "final" the user can
> tell the compiler that this method won't be overriden anymore and
> On Jul 23, 2023, at 7:13 AM, Benito van der Zander via fpc-devel
> wrote:
>
> with my patch, "copy" can be inlined!
> initialize and finalize some times, too.
Amazing!
>
> There are two places that call them. compiler/nld.pas and
> compiler/ngenutil.pas where it creates the call
Nice work, I have no answer for you though. :)
What is the performance improvement here and why was it done the old way?
Another question I had about them is why they can't be inlined. Does anyone
have the answer for that? Not being able to be inlined is the biggest
performance problem I
> On Apr 11, 2023, at 4:02 PM, Marco van de Voort via fpc-devel
> wrote:
>
> That's what I thought, yes. But the whole analysis stays the same:
>
> - you don't have a list of all possible polymorphic types in the application
> when you compile the average dispatch point, that is in the
> On Apr 11, 2023, at 2:58 PM, Marco van de Voort via fpc-devel
> wrote:
>
> But the core problem is that you don't have an overview of all other
> descendants in the compiler. Those can be fragmented over multiple units, and
> then you touch the problem that whole program optimization like
> On Apr 11, 2023, at 2:58 PM, Marco van de Voort via fpc-devel
> wrote:
>
>> case animal.type of
>>TDog: TDog(animal).DoSomething;
>>TCat: TCat(animal).DoSomething;
>>TMouse: TMouse(animal).DoSomething;
>> end;
>
> This doesn't happen. There is no class that is TDog,Cat and
Strange question but I heard it brought up during a discussion and I was very
curious what compiler people think about it.
The question is, instead of using a virtual method table would it be feasible
to use a case statement on the real class type and make a dispatch routine for
each method
> On Feb 22, 2023, at 8:11 PM, Sven Barth via fpc-devel
> wrote:
>
> Some additional constraints might be added. However I have none of them
> planned currently and enough other things to do.
Btw, which constraints were you considering?
Regards,
Ryan Joseph
> On Feb 22, 2023, at 8:11 PM, Sven Barth via fpc-devel
> wrote:
>
> Some additional constraints might be added. However I have none of them
> planned currently and enough other things to do.
>
I think Delphi basically has the same constraints as C# so FPC is in that same
category. Swift
As a follow up to my other question, why doesn’t FPC support more types for
generic type constraints, like Pointer, Integer, String etc...? Especially
since we have implicit function specialization now allowing the user to
constrain the types more precision would help.
For example my other
The function Bind is specialized with two types which are identical
(TState) and the compiler can’t determine which to call.
Is there anyway to resolve this? In my mind I want the more “explicit” overload
with the var parameter but there’s really no way for the compiler to know this,
that I
I’ve somewhat forgotten the order things happen when resolving overloads but is
it even possible to make this example work with implicit function
specialization?
Right now it fails and I suspect that’s because the operator overload is not
considered in the correct order (or at all) but is this
> On Feb 2, 2023, at 3:57 PM, Adriaan van Os via fpc-devel
> wrote:
>
> - under what circumstances (and in what compiler mode) does FPC pass large
> (say 1 MB or 1 GB) "const" parameters by value (which is extremely
> inefficient) ?
> - for what reasons ?
>
> As long as these questions are
> On Feb 2, 2023, at 8:41 AM, Adriaan van Os via fpc-devel
> wrote:
>
> On debate, see FPC issue 17442.
https://gitlab.com/freepascal.org/fpc/source/-/issues/17442
Yes this is what I remember learning.
What I think should be documented is what you should do for records that over a
certain
> On Feb 2, 2023, at 4:38 AM, Sven Barth wrote:
>
> Which types are passed by-value or by-reference when using const is
> determined by the size of the record and the types of the fields based on
> whatever the corresponding ABI defines (e.g. the x86_64 Sys V ABI is rather
> explicit about
> On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> That's exactly what Adriaan is saying. With const the compiler can choose.
> With constref, you force it not to copy. But this is not so efficient for
> small parameter sizes.
So const will always pass records that
> On Feb 1, 2023, at 8:16 PM, Adriaan van Os via fpc-devel
> wrote:
>
> Because, if e.g. the byte-size of a parameter is such that it fits into a CPU
> register, then passing the parameter itself is more efficient than passing a
> reference to it. For large byte-size parameters, const and
> On Feb 1, 2023, at 5:56 PM, Adriaan van Os via fpc-devel
> wrote:
>
> "A const parameter is be passed by reference or (for small-sized parameters)
> by value, whatever is most efficient. A constref parameter is guaranteed to
> be passed by reference in all cases. The latter is therefore
> On Jan 9, 2023, at 8:35 PM, Hairy Pixels wrote:
>
> https://gitlab.com/genericptr/free-pascal/-/commits/generic_helpers
Fixed said merge errors, added tests and made a merge request at
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/367
Regards,
Ryan Joseph
Hey guys, I was thinking about how nice generic type helpers would be today
and remembered I did a mostly functional branch over 6 months ago so I fixed it
up and posted it on gitlab. There’s a nasty merge error with main I need to fix
but you can test it anyways.
For the helper type I
> On Sep 22, 2022, at 6:52 AM, Richard Hyman via fpc-devel
> wrote:
>
> b. Does FPC support Mac system APIs? This is a general question since API
> support in any one of several areas (beyond graphics for example) would be
> beneficial.
What system APIs? Many frameworks are not ported to
> On Jun 23, 2022, at 11:52 PM, Sven Barth wrote:
>
> As you can see at the end (see below) it falls back to 3.2.2 at the end. What
> commands did you execute to build FPC itself?
>
I have no idea what it did that. I’ve done this many times so I’m confused as
to what changed.
I used a
I usually solve this by deleting the units folder but for some reason after
pulling from main it simply won’t build. Can anyone explain why the PPU version
is wrong? It’s all building from the same source directory so the PPU version
in ppu.pas should be the same. Before I tried this I did
Me and Sven had planned this a couple years ago and I finally got around to it
this weekend since it was pretty trivial. The reason for this being we wanted a
way to disable the generic keywords in ObjFPC mode. The solution is to decouple
the keywords from the ObjFPC mode and put them under a
Over the weekend I did some work on how to implement generic helpers since this
is something I wanted to do for a while and Sven said it was on the agenda.
It’s "low hanging fruit” kind of feature since all the pieces are there
(helpers and generics) just not put together, kind of multi helpers
Basically it looks like multi helpers don’t actually work with overloaded
methods and simply choses the last helper declared. Should I fix this? Seems
unlikely we would not notice this before but maybe we did.
{$modeswitch typehelpers}
{$modeswitch multihelpers}
type
TMyHelper1 = type helper
Before if you tried to use a generic function without specialization you would
get this error:
Generics without specialization cannot be used as a type for a variable
Now since adding implicit function specialization I get this error:
Wrong number of parameters specified for
> On Apr 26, 2022, at 8:58 AM, J. Gareth Moreton via fpc-devel
> wrote:
>
> It's just a "make all" in the RTL directory on x86_64-darwin, right? I can
> only do x86_64-linux, which I hope is nearly the same, but I'll let you know.
Ok I think this was because I was using the wrong build
realconst(hp).realtyp
> value. Did I break things again?!
>
> Gareth aka. Kit
>
> On 26/04/2022 02:32, Hairy Pixels via fpc-devel wrote:
>
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https:
I’m doing a make all in the RTL and getting this internal error. Can anyone
else replicate this?
/Users/ryanjoseph/Developer/fpc-gitlab/rtl/inc/genmath.inc:77:7: warning: Local
variable "one" not used
/Users/ryanjoseph/Developer/fpc-gitlab/rtl/inc/genmath.inc:78:7: warning: Local
variable
> On Mar 24, 2022, at 7:21 AM, Michael Van Canneyt via fpc-devel
> wrote:
>
> I am all for merging the implementation of Ryan, but this is not my domain,
> so one of the compiler people needs to look at it.
>
FPC badly needs another reviewer or someone with authority otherwise. I’ve been
> On Mar 24, 2022, at 8:14 AM, Hairy Pixels wrote:
>
> Search for "Case statement for class introspection” and you see can the
> little discussion we had about a potential speed up and why it wasn’t viable
> so for now it’s just using a if-else statement with A.ClassType = B.ClassType
>
> On Mar 23, 2022, at 10:09 PM, Stefan Glienke via fpc-devel
> wrote:
>
> JEP 420 is hardly a misnomer because it is so much more than just type
> checking in a switch statement - hence pattern matching.
> You can see in the various examples that you can combine all kinds of boolean
>
> On Mar 23, 2022, at 10:35 PM, Mattias Gaertner via fpc-devel
> wrote:
>
> Forget Java. The point is, that its "case" can be more than mere
> syntactic sugar. It could give a nice speed up and the compiler warns
> about unreachable statements.
Search for "Case statement for class
> On Mar 23, 2022, at 10:13 PM, Mattias Gaertner via fpc-devel
> wrote:
>
>> Lol I just implemented this and made a merge request but I haven’t
>> heard back from anyone yet so it’s just sitting there….
>>
>> I basically just copied the structure used for “case of string” in
>> that it makes
I just remembered now I tried to follow the procedure to rebase the branch like
they wanted but I made a big mess of things (notice how it says 400+ changes).
I don’t know went wrong but you can see the changes I made in the commit
history but I’m not sure how to isolate them to make a diff.
Lol I just implemented this and made a merge request but I haven’t heard back
from anyone yet so it’s just sitting there….
I basically just copied the structure used for “case of string” in that it
makes if a big if-else statement.
43 matches
Mail list logo
