Btw, here's point of reference for this other proposed syntax.
https://github.com/genericptr/freepascal/wiki/Default-Implements-Property
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.o
> On Feb 19, 2021, at 11:01 AM, Sven Barth via fpc-pascal
> wrote:
>
> Your example is not quite correct and it's also not really complete: if a
> class implements an interface there *must* be a parent class mentioned (at
> least TObject). Also your example should demonstrate that one can ca
> On Feb 19, 2021, at 3:14 PM, Sven Barth via fpc-pascal
> wrote:
>
> TObject *is* always the root, but the first entry of the inheritance list of
> a class *must* be a class as well.
I'm testing interface delegation now in ObjFPC mode and I don't see that
including TObject is required.
R
> On Feb 20, 2021, at 5:19 AM, Виктор Матузенко via fpc-pascal
> wrote:
>
> Hi,
>
> I am trying to write some generic routines for working with containers. For
> example, GetLength function:
>
>
>
> unit u;
>
> {$MODE FPC}
> {$MODESWITCH DEFAULTPARAMETERS}
> {$MODESWITCH OUT}
> {$MODESWI
> On Feb 20, 2021, at 7:52 PM, Виктор Матузенко via fpc-pascal
> wrote:
>
> And how do I write generic helper for all possible dynamic arrays?
By hand sadly. The RTL has added type helpers for many types but I don't think
they added these for dynamic arrays. I agree that dynamic arrays shoul
> On Feb 21, 2021, at 2:59 PM, Sven Barth wrote:
>
> You are supposed to use Length(X). There is no need for a "property". One
> doesn't need to objectify each and everything!
Yes but programmers tend to be neurotic and obsessive. :) I think many of us
would appreciate a matching "Count" met
> On Feb 19, 2021, at 8:50 AM, Ryan Joseph wrote:
>
> I just realized another potential problem. If we use the "default" keyword
> that means there could be multiple "defaults" unless we limit the property to
> 1 per class, which would kind of defeat the purpose of the feature (like the
> is
> On Feb 22, 2021, at 4:21 PM, Виктор Матузенко via fpc-pascal
> wrote:
>
> Example of such an algorithm is binary search. I am able to access elements
> with [] operator of both
> arrays and objects, but I cannot get length in a generic way.
>
Length(T) is what you want right?
Regards,
Ok my summary thus far with this syntax (default interface delegation) is that
composition is possible (which is very nice) but polymorphism is not really
possible so it's not exactly an alternative to multiple inheritance. Besides
the complications of implementing method resolution for classes
I came across a bug which was caused but a unicode character losing information
and narrowed it down to this. Why doesn't the chars[1] print the same character
as appeared in the string?
var
chars: UnicodeString;
begin
chars := '⌘⌥⌫⇧^';
writeln(chars);
writeln(chars[1]);
end.
Prints:
> On Mar 7, 2021, at 9:31 AM, Marco van de Voort via fpc-pascal
> wrote:
>
> Probably it is not in the BMP and thus needs more position than one.
Isn't char[1] a 2 byte wide char? Not sure I understand "more position than on"
though.
Regards,
Ryan Joseph
___
> On Mar 7, 2021, at 10:11 AM, Marco van de Voort via fpc-pascal
> wrote:
>
>
> Yes it is. And there are about 1114000 unicode codepoints, or about 17 times
> what fits in a 2-byte wide char.
>
> https://en.wikipedia.org/wiki/Code_point
>
> https://en.wikipedia.org/wiki/UTF-16
I thought u
> On Mar 7, 2021, at 10:21 AM, Ryan Joseph wrote:
>
> I thought unicode strings "just worked" but maybe that's UTF-8 and the
> character I want is maybe UTF-16. What are you supposed to do then?
> UnicodeString knows how to print the full string so all the data is there but
> I can't index t
So I was indeed able to solve the problem using {$codepage utf8} and using the
CWString unit. Does this do anything besides change the backend of the
UnicodeString/UnicodeChar type? I using other string types in that unit and I'm
curious if I've put some kind of performance burden on the other
This program compiles, but is it a bug? I would think the specialization should
fail because "S" in TArray is not specified.
{$mode objfpc}
type
generic TArray = array of T;
generic procedure DoThis(param: specialize TArray>);
begin
end;
begin
specialize DoThis(
> On Mar 15, 2021, at 12:42 AM, Sven Barth wrote:
>
> The TArray generic type is part of the ObjPas unit, so the compiler simply
> picks that instead of that of your program. ;)
Sneaky but that explains the issue.
Btw since we're on the topic of arrays. Are short strings and static arrays no
Is there a way to hide a warning for all files from the command line? The "not
inlined" warnings (6058) are too numerous to even be useful anymore so I'd like
to disable it.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.fre
I'm trying to see fields by name but TObject.FieldAddress doesn't seem to be
working. Do I have that correct I should be using FieldAddress to return the
pointer of the published property? Some how I can't seem to find an example of
FieldAddress on Google
type
TSomething = class(TPersiste
> On Apr 4, 2021, at 12:10 PM, Sven Barth via fpc-pascal
> wrote:
>
> FieldAddress only works on published fields. Just like MethodAddress only
> works on published methods.
>
> For private fields extended RTTI is required which is not yet implemented.
I don't understand this at all I guess
> On Apr 4, 2021, at 1:07 PM, Sven Barth via fpc-pascal
> wrote:
>
> Only classes or interfaces are supported as published *fields*.
>
> And the visibility of the *property* does not change the visibility of the
> *field*, after all the property could be provided by a method.
>
I know FPC
> On Apr 4, 2021, at 2:36 PM, Sven Barth via fpc-pascal
> wrote:
>
> The RTTI streaming relies on *published properties* (and published methods
> for the event handlers).
Sorry Sven, I'm not understand what I'm doing wrong. From original example
"scale" is a published property right? So Fie
With normal classes you can make aliases to other units but with generics you
get an error. Am I doing this wrong or is this not supported?
type
TList = UOther.TList; // Generics without specialization cannot be used as a
type for a variable
Regards,
Ryan Joseph
___
From the documentation: "An abstract class is a class that cannot be
instantiated directly. Instead, a descendent class must always be instantiated.
However, for Delphi compatibility, the compiler ignores this directive."
Why does this get ignored and what does this have to do with Delphi? I
pe
> On Apr 17, 2021, at 1:07 PM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Hi
>
> I'm looking at the wiki and official FPC language documentation. What was
> the reason for the decision to make the FPC syntax so verbose regarding
> Generics?
There is a plan to make these optional via a mod
> On Apr 17, 2021, at 3:09 PM, Sven Barth wrote:
>
> The compiler will generate a warning in case you instantiate a class that is
> abstract or has abstract methods. You can escalate these warnings to errors
> if you need:
It's probably not practical to put that warning into all potential fi
> On Apr 18, 2021, at 5:00 AM, Sven Barth wrote:
>
> As I have said: Delphi compatibility.
This would have been a good candidate to put behind the delphi mode switch but
I'm sure there is a reason for this also.
Regards,
Ryan Joseph
___
fp
> On Apr 18, 2021, at 11:28 PM, Sven Barth wrote:
>
> Nowadays: backwards compatibility.
backwards compatibility strikes again. :)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org
I have a question I was just curious about. From what I can tell TFPGMap uses
CompareByte to compare keys of arbitrary type, which is clever but how does
this work for ShortStrings? I have tried to use this method myself and I find
it always fails because short strings have garbage at the end an
> On Apr 20, 2021, at 3:10 PM, Sven Barth wrote:
>
> If you look at TFPSMap' code you'll see that BinaryCompareKey and
> BinaryCompareData are only used in the way of method pointers OnKeyPtrCompare
> and OnDataPtrCompare. In TFPGMap<,> these are then set to compare methods
> specific to the
> On Apr 27, 2021, at 9:58 AM, Michael Van Canneyt
> wrote:
>
> Wait.
>
> I asked Sven to make sure that nested functions are under ALL circumstances
> usable as closures or can be used instead of anonymous functions.
>
> Pas2js already supports this, and I want FPC and Pas2JS to be compatib
> On Apr 27, 2021, at 2:17 PM, Sven Barth via fpc-pascal
> wrote:
>
> It will *always* create an interface. It's just how the compiler will wrap it.
But why would it do that when we could use an alternate code path that uses
nested functions instead? Maybe I'm not being clear but we can do B
> On Apr 27, 2021, at 2:23 PM, Ryan Joseph wrote:
>
> But why would it do that when we could use an alternate code path that uses
> nested functions instead? Maybe I'm not being clear but we can do BOTH
> depending the situation when one is better than the other. This is just an
> optimizati
> On Apr 27, 2021, at 4:53 PM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Why must the anonymous function repeat all that information again,
> as shown in the quoted code above? Can't the compiler figure all
> that out simply by inference? All the developer should have to do
> is give the 2
> On Apr 27, 2021, at 11:36 PM, Sven Barth wrote:
>
> Anyway, it would in principle be possible to convert an anonymous function to
> a "is nested" function, but that will only come *after* the whole
> implementation is here so that the chance for messing that core functionality
> (!) up is
> On Apr 28, 2021, at 10:43 AM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Couldn't such verbose syntax be limited to {$mode delphi} behaviour,
> and then leave {$mode objfpc} free to experiment and introduce new
> less verbose syntax in the language.
Sven is having none of this and for go
> On Apr 29, 2021, at 12:01 AM, Sven Barth wrote:
>
> To be precise there are two more: function/procedure variables (no special
> designator) and method variables ("of object"). Depending on what a anonymous
> function captures (or for the sake of it a nested function) it would be
> possibl
Is this a bug in properties and I should be getting an error?
type
TPixel = record
components: array[0..3] of byte;
property R: byte read components[10] write components[10];
end;
Regards,
Ryan Joseph
___
fpc
> On Apr 29, 2021, at 11:22 PM, Sven Barth wrote:
>
> Well, there should *at least* be a warning and an error if range checks are
> enabled... Please file a bug report.
https://bugs.freepascal.org/view.php?id=38829
Regards,
Ryan Joseph
___
> On May 12, 2021, at 12:30 PM, Ralf Quint via fpc-pascal
> wrote:
>
> Thought this was kind of interesting, though it leaves short of mentioning
> the later Object Pascal evolution and thus Delphi and FreePascal...
Isn't Free Pascal and Delphi basically the only Pascal compilers left? I use
> On May 12, 2021, at 4:00 PM, Sven Barth wrote:
>
> There's also Oxygene as one of the current ones.
>
Oh that's right, that's a pretty cool one. I hope once closures are finished we
can use them to implement async/await like Oxygene or JavaScript. :)
Regards,
Ryan Joseph
___
> On Jun 1, 2021, at 12:20 PM, denisgolovan via fpc-pascal
> wrote:
>
> Hi all
>
> I am trying to implement Option type in FPC.
>
> type
> generic TOption = record
>case IsSome:boolean of
>true: ( some: T );
>false: ();
> end;
You need to use a constraint like:
type
generic
> On Jun 1, 2021, at 12:56 PM, denisgolovan wrote:
>
> That would limit supported types to class instances.
> I'll like to avoid that.
> Ideally TOption type should allow any type (primitives, strings, objects,
> class instances, etc).
What are you trying to make that requires a variant reco
> On Jun 1, 2021, at 5:05 PM, Henry Vermaak wrote:
>
> https://en.wikipedia.org/wiki/Option_type
Yeah just use Nullable then since it sounds like that's the closest we're
going to get in FPC.
Regards,
Ryan Joseph
___
fpc-pascal maillist
> On Jun 13, 2021, at 7:48 AM, denisgolovan via fpc-pascal
> wrote:
>
> Could anybody reply?
>
> Am I doing something wrong?
> Are management operators supported or not?
Maybe reduce the test down to a smaller footprint and isolate the memory leak?
That would be helpful to knowing what may
> On Jun 13, 2021, at 11:35 PM, Sven Barth via fpc-pascal
> wrote:
>
> I have not looked at your test case yet, but it *might* be related to issue
> #37164 ( https://bugs.freepascal.org/view.php?id=37164 ).
His tests didn't have an enumerator and for..in loop like in that bug report so
I'm
Is it possible something like this could work? Seems like it should but I get
an error (got MyRecord expected variant).
{$mode objfpc}
program unit_name;
type
TTuple = array of variant;
type
MyRecord = record
end;
var
t: TTuple;
r: MyRecord;
i
> On Jul 9, 2021, at 11:40 AM, Wayne Sherman via fpc-pascal
> wrote:
>
> Current standings at the time of this video
> Iterations per sec:
> Ada: 67
> Pascal: 143
> Fastest language: 7301
> Slowest language: 1
So Pascal failed pretty bad it looks like. ;)
Regards,
Ryan Joseph
_
> On Jul 10, 2021, at 4:16 AM, Guillermo via fpc-pascal
> wrote:
>
> Hi,
>
> I remember years ago a similar test in a web page. Pascal was way low
> in the list, even below Java and Python! but we (in a forum) found that
> it wasn't Pascal fault: most versons program were optimised in code
>
> On Jul 9, 2021, at 4:56 PM, Ryan Joseph wrote:
>
>> Current standings at the time of this video
>> Iterations per sec:
>> Ada: 67
>> Pascal: 143
>> Fastest language: 7301
>> Slowest language: 1
>
> So Pascal failed pretty bad it looks like. ;)
I just ran that unit with -O2 and got nearly ~
> On Jul 10, 2021, at 11:18 AM, Jonas Maebe via fpc-pascal
> wrote:
>
> A constexpr function means that it must be computable at compile time if
> all of its arguments are also constexpr.
So like the "pure" functions that Gareth was working on? Seems to have moved on
from the idea but I thou
I have some code the basically does:
while bytesRead > 0 do
bytesRead := process.Output.Read(buffer^, kBufferSize);
but bytesRead is only ever 512 per call to Read.
Is this a system imposed limit or something that's part of TProcess? Setting
kBufferSize to anything larger than 512 has n
> On Jul 15, 2021, at 3:07 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> Not of TProcess as far as I know, it probably depends on the OS pipe
> implementation and maybe the granularity that the processes that you run
> outputs data. (buffers its I/O iow calls write() in 512 byte incre
> On Jul 15, 2021, at 8:33 PM, Dennis Lee Bieber via fpc-pascal
> wrote:
>
> https://flylib.com/books/en/3.126.1.111/1/
>
> """
> Only writes below PIPE_BUF bytes in size are guaranteed to be atomic.
> PIPE_BUF is 512 bytes on Mac OS X. The fpathconf() system call can be used
> to retrieve th
FPC has a number of function pointer types and eventually will have another in
"reference to" closures. This presents a problem of how the programmer can make
a function that is type agnostic so that we can use different types of
callbacks.
Currently this is the best solution I can think of but
> On Aug 21, 2021, at 12:08 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> You can pass global functions to "is nested" procvars, so at least these
> two don't need to be separate.
>
> OTOH, there's another type: cblocks :)
So up to 4 types are needed: "is nested", "of object" and "reference to
> On Aug 21, 2021, at 1:30 PM, Michael Van Canneyt
> wrote:
>
> "Reference to" can be used for the others as well.
How do you mean? Reference to is currently only available for cblocks on macOS
I think so I'm not sure how this would look.
Regards,
Ryan Joseph
_
> On Aug 21, 2021, at 3:09 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> As in Delphi 'reference to' will also be used for all references where an
> anonymous functon can be used. But you can perfectly use methods and local
> functions for that. So it will function a like a catch-all pro
I'm trying to build a Lazarus project on Windows and I've ran into a problem.
Since I barely know Windows all I have known to do is download the latest
version of the compiler and Lazarus then install them via their installers. I
expected then to be able to use lazbuild like I do on macOS but I
> On Oct 16, 2021, at 5:18 AM, Anthony Walter via fpc-pascal
> wrote:
>
> Source code for the test scene is included on that page. If you want to help,
> I need to bounce ideas off people as well as test on Raspberry Pi, Mac, and
> Windows. Message me and maybe we can try to meet on a Discor
> On Oct 28, 2021, at 9:39 PM, Dennis Lee Bieber via fpc-pascal
> wrote:
>
> Are you actually running on a 32-bit system? You appear to have
> installed a 32-bit compiler.
I think I may have downloaded the 32 bit version of the compiler and then the
64 bit Lazarus! That would make sen
> On Oct 29, 2021, at 4:25 AM, Anthony Walter via fpc-pascal
> wrote:
>
> Thanks for the interest Ryan. I am preparing to push my code to a public git
> repository with a FOSS license. In order to get this out soon it will be
> broken into a few releases.
Nice let us know when it's finishe
Sorry I didn't look up high enough in the output to see this before. It looks
like lazbuild can't find the correct version of the compiler that is packaged.
I can confirm that path exists but I think the variable $Lazarusdir may be
wrong.
What could be wrong here? I got Lazarus via an installer
> On Oct 29, 2021, at 2:01 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Lazarus uses macros of the form $(LazarusDir) .
>
> Did you check the fpc path in Lazarus?
> Tools / Options / Environment
So what happened here is that I as a new user on Windows decided I needed the
compiler firs
> On Oct 31, 2021, at 10:50 AM, Alexander Grotewohl via fpc-pascal
> wrote:
>
> Because += is a mistake and hopefully it's irreparably broken.
>
> Does using just s:=s+';'; work?
>
I thought they were behind a mode switch called "c operators" or something but
either way I don't see why Win
> On Oct 31, 2021, at 2:53 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> The compiler itself does enable them by the default on any platform. However,
> the fpc.cfg file that gets installed with FPC on all platforms does enable
> them by default (it contains -Sgic). Compile with -vt and check
> On Oct 31, 2021, at 4:57 PM, Anthony Walter via fpc-pascal
> wrote:
>
> As mentioned before, this library will be released to a git repository soon
> with a FOSS license. It will be able to run on Windows, Mac, Linux, and Pi
> including the new Pi Zero 2 W.
>
Thanks, please post when it
> On Nov 1, 2021, at 5:12 PM, Anthony Walter via fpc-pascal
> wrote:
>
> I plan to add: Write a `redmond` win95 style theme. Write a few example
> custom controls. Add modal window support and dialog box functions.
>
How are you doing themes? I made a MacOS 8 theme by slicing up tons of old
> On Nov 3, 2021, at 8:17 PM, Bart via fpc-pascal
> wrote:
>
> Maybe use SomeString.Split([LineEnding'], ...)?
> Split has an overload that takes an array of string as first paramter.
Thanks, I guess I need to use a different way to work on all platforms.
Regards,
Ryan Joseph
__
> On Nov 6, 2021, at 7:09 AM, James Richters via fpc-pascal
> wrote:
>
> Do I need to use the source to re-install FPC every time I want to update it?
> If so how is this accomplished?
>
You need to rebuild the compiler every time it's updated. It can installed to a
"trunk" location so th
> On Nov 5, 2021, at 10:41 PM, Benjamin Rosseaux via fpc-pascal
> wrote:
>
> I'm curious to see how it compares with my vector-based UI framework stuff at
> PasVulkan ( https://youtu.be/YR0KruyQbx4 ), where the GPU itself renders
> everything by shader, where nothing is bitmap-based, if one i
Is there anyway a function parameter could be inlined in FPC? This would go a
long way in helping to parameterize functions that have tight loops in them.
If there isn't I wonder if this is an area where the proposed "pure" function
modifier could be used to make it possible.
===
t
> On Nov 7, 2021, at 2:17 PM, Jonas Maebe via fpc-pascal
> wrote:
>
>> Is there anyway a function parameter could be inlined in FPC? This would go
>> a long way in helping to parameterize functions that have tight loops in
>> them.
>
> It's theoretically possible through constant propagatio
> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal
> wrote:
>
> And there you have it (simplified obviously). As long as the compiler can
> determine *at compile time* the code of the function (and the function is
> inlineable) it should in theory be able to inline it. This is true no m
> On Nov 8, 2021, at 11:20 PM, Sven Barth via fpc-pascal
> wrote:
>
> I don't know what you mean with "new function body". If a function is inlined
> its code is contained within the surrounding function and if it's not inlined
> then nothing changes.
>
I mean if in theory you were to inl
> On Nov 9, 2021, at 1:09 PM, Sven Barth via fpc-pascal
> wrote:
>
> No, because the function that is called with a function pointer needs to be
> inlined itself (thus becoming part of its caller) so that constant
> propagation works at all for the parameters. If a function isn't inlined the
This was discussed before some years ago with no conclusion
(https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html)
but I'd like to bring it up again. Can we consider extending the variant
dispatch call named parameters to normal functions? The majority of the
infrastructur
> On Nov 26, 2021, at 3:31 PM, Michael Van Canneyt
> wrote:
>
> That seems like a fake argument: Of course you need to look, because you need
> the names ?
> Secondly, the IDE will simply tell you what the names are when the cursor is
> on them.
It's mainly useful when reading code so you do
> On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote:
>
> It's mainly useful when reading code so you don't need to review the function
> definition, using code tools or any other method. I've been enjoying it in
> other languages when it's not compulsory and FPC already supports the syntax
> so
> On Nov 27, 2021, at 5:00 PM, Sven Barth wrote:
>
> The compiler does not know which routine is called upon parsing the parameter
> declarations (which would mean that error reports would need to be deferred
> until the lookup of the routine failed).
My idea was to not actually have it affe
> On Nov 27, 2021, at 5:03 PM, Sven Barth wrote:
>
> candidates:=tcallcandidates.create(sym:=symtableprocentry,
> st:=symtableproc,ppn:=left,
> ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in
> flags),objcidcall:=cnf_objc_id_call in
> callnodeflags,explicitunit:=c
> On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> What do you mean? Is there already some call by arg names in some
> mode(switch)?
I mean all the plumbing is there so the feature could easily be extended from
IDispatch to work with normal function calls.
Regards,
> On Nov 28, 2021, at 7:01 PM, Sven Barth wrote:
>
> Anything that relates to picking functions *must* be part of the overload
> handling. You can easily see this with your named argument proposal when not
> all arguments are named (and then the compiler also needs to check that
> unnamed pa
> On Dec 1, 2021, at 4:56 AM, Sven Barth wrote:
>
> If you don't allow to skip parameters then this feature can be considered
> absolutely useless. Who would voluntarily write more when many users already
> cry about Pascal being so verbose?
I thought the option of improved readability made
> On Dec 24, 2021, at 8:13 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Our little contribution to a Merry Christmas for everyone...
Nice work. I have a hard time wrapping my head around this. Can you just write
plain HTML to STDOUT using writeln and that's enough?
Regards,
R
I saw a new syntax in Swift which I thought was clever and fits a pattern I've
seen before. Basically it's a case statement for class types which lets you
branch depending on which class type the class instance is at run time.
I wonder if this could be implemented in FPC? The syntax would be kin
> On Jan 15, 2022, at 8:30 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>> I saw a new syntax in Swift which I thought was clever and fits a pattern
>> I've seen before. Basically it's a case statement for class types which
>> lets you branch depending on which class type the class insta
> On Jan 15, 2022, at 3:24 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I don't see how an inline variable helps with the casting mess. You'll
> always need a cast.
>
> What I do is Var
> MyInstance : TObject;
> MyNeededClass : TMyNeededClass absolute myInstance:
Yes that's the best
> On Jan 16, 2022, at 9:21 AM, Ryan Joseph wrote:
>
> There is a possibility for using "as" operator also though
oops I mean "is" operator. Not sure if these are technically different from
ClassType = ClassType though...
Regards,
Ryan Joseph
_
> On Jan 16, 2022, at 2:35 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>
> They are.
>
> No "is", because then the order of the label will start to matter, and that
> runs contrary
> to the case statement's intent.
oh of course they are, I don't know why I forgot that. :P
Regards,
I had some fun today on my day off and managed to actually implement this based
on the if-statement based string case labels. Is the compiler team interested
in this feature? I think it's a clearly useful addition to OOP and an
appropriate new use of the case statement.
https://gitlab.com/gener
> On Jan 16, 2022, at 8:38 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> What does it print in this case? I mean tobject matches, and
> tinterfacedobject too.
>
> The most logic solution would be to only run the most specialized case?
It would print the name of the class if it didn't e
> On Jan 16, 2022, at 8:18 PM, Ryan Joseph wrote:
>
> https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref
I just realized too late that the way I implemented this may be not the best
idea. If the class type had an ordinal representation then you could use a
normal case st
> On Jan 16, 2022, at 9:01 PM, Ryan Joseph wrote:
>
> case PtrUInt(o.ClassType) of
>4500656856: writeln('TObject');
> end;
I may have spoken too soon and without thinking the through clearly (it's
getting late here!). For this to work we would need a unique ID in the RTTI,
right? I don
> On Jan 16, 2022, at 11:15 PM, Sven Barth wrote:
>
> The class type already is a unique "ID" for each class type when doing an
> equal comparison. You can essentially take the address of the VMT as the
> constant values that the loaded value is compared against.
Does that look something lik
> On Jan 17, 2022, at 1:55 PM, Sven Barth wrote:
>
> Question then is how you get the VMT address as a constant at compile time.
>
> I'll need to get back to you with that.
>
I didn't test yet but I think what you're saying is that VMT writer would need
to have generated this address in ad
> On Jan 17, 2022, at 5:09 PM, Sven Barth wrote:
>
> The VMT writer already does that, cause the VMT pointer is required for each
> constructor call.
>
The pointer to the VMT table is just PVmt(self) right? If I make a program and
do:
writeln(PtrUInt(TObject.ClassType));
the address chan
> On Jan 18, 2022, at 5:28 AM, Sven Barth wrote:
>
> The values will have the same differences between each other upon each start
> so ideally this would work anyway, but if one also throws dynamic packages
> into the mix things would get messed up. So better stay with the if-clauses.
Here's
> On Jan 19, 2022, at 1:26 PM, Sven Barth wrote:
>
> We also take merge requests. If you have a fork anyway, then a merge request
> is probably easier. Though you need to have your repository set up to use
> rebasing instead of merging, see here:
> https://wiki.freepascal.org/FPC_git#Update
> On Jan 19, 2022, at 4:15 PM, Michael Van Canneyt
> wrote:
>
> It's explained in the page that Sven referred to ?
>
> It's only when you merge into your feature branch from the main branch that
> you will see an effect.
Still not following this. Do you need me to do a pull-rebase from main
> On Jan 19, 2022, at 4:19 PM, Ryan Joseph wrote:
>
> Still not following this. Do you need me to do a pull-rebase from main and
> then make my pull request?
I used git at work everyday but I'm still a newbie in many ways. Reading this
now but I'm confused because it seems too late. Please p
301 - 400 of 424 matches
Mail list logo
