Am 25.04.2022 um 17:30 schrieb Michael Van Canneyt via fpc-pascal:
On Mon, 25 Apr 2022, Thomas Kurz via fpc-pascal wrote:
I cannot remember why, but a long time ago when learning Delphi 5 or
6, I
have learned not to call the destructor from within any method of the
class, only from outside.
On Mon, 25 Apr 2022, Thomas Kurz via fpc-pascal wrote:
I cannot remember why, but a long time ago when learning Delphi 5 or 6, I
have learned not to call the destructor from within any method of the
class, only from outside. If this is no longer true nowadays (or maybe,
has never been true b
EDIT: The code should be "TThread.ForceQueue", not "TThread.Synchronize"; I
have corrected that.
I cannot remember why, but a long time ago when learning Delphi 5 or 6, I have
learned not to call the destructor from within any method of the class, only
from outside. If this is no longer true n
I cannot remember why, but a long time ago when learning Delphi 5 or 6, I have
learned not to call the destructor from within any method of the class, only
from outside. If this is no longer true nowadays (or maybe, has never been true
before), I'd like to use this solution.
Just to be sure we'
On Mon, 25 Apr 2022, Thomas Kurz via fpc-pascal wrote:
This is a very elegant solution but it can only be used for Synchronize,
right? Because with ForceQueue I cannot know when it's done and freeing
within Run (i.e. "Self.Free") would fail.
Why would this fail according to you ?
I have
This is a very elegant solution but it can only be used for Synchronize, right?
Because with ForceQueue I cannot know when it's done and freeing within Run
(i.e. "Self.Free") would fail.
Using an advanced record would be fine, but it doesn't fit the declaration
"TThreadMethod = procedure of obj
On Mon, 25 Apr 2022 15:47:57 +0200
Thomas Kurz via fpc-pascal wrote:
>[...]
> As far as I have seen so far, the common solution is to use a
> variable inside the class to cache the parameters, then to use a
> DoCallSync procedure which takes no parameters but can use the cached
> values inside, a
Hello,
my question is about using the TThread.Synchronize, Queue and ForceQueue
methods. Unfortunately, the parameter they take is of type TThreadMethods which
allows calling only methods having no parameters at all. I assume this is done
to simplify the implementation on client-side but causes
> On Apr 25, 2022, at 7:14 PM, Sven Barth via fpc-pascal
> wrote:
>
> For some reason I don't get all mails by Ryan, so I reply here:
>
> Helpers currently can't be generic and even if they could be (which I do plan
> to add) it would require an explicit specialization of the helper to be u
Mattias Gaertner via fpc-pascal schrieb
am Mo., 25. Apr. 2022, 13:50:
>
> >[...]
> > type
> > generic TArrayHelper = type helper for array of T
> > procedure Add(value: T);
> > end;
> >
> > var
> > a: array of integer;
> > begin
> > a.Add(1); // specialize TArrayHelper since the comp
On Mon, 25 Apr 2022 10:15:26 +0700
Hairy Pixels via fpc-pascal wrote:
>[...]
> For the case of types I understand we must specialize because we’re
> creating a new type each time and there is nothing to infer from the
> context, but for functions it’s backwards, that is we know the types
> being
On 25-4-2022 11:11, Sven Barth via fpc-pascal wrote:
Then you don't think creative enough. Think about (de)serialization
code for binary data which needs to use the correct size. If done
correctly this can very well be handled with a generic.
Actually that's what I immediate thought of too,
> On Apr 25, 2022, at 4:11 PM, Sven Barth wrote:
>
> Then you don't think creative enough. Think about (de)serialization code for
> binary data which needs to use the correct size. If done correctly this can
> very well be handled with a generic.
>
Oh yes that’s right. I guess I would need
Hairy Pixels via fpc-pascal schrieb am
Mo., 25. Apr. 2022, 10:58:
>
>
> > On Apr 25, 2022, at 2:39 PM, Martin Frb via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Actually, it's dealing with SmallInt (or ShortInt). And if the
> programmer does not know that, then it might be an
> On Apr 25, 2022, at 2:39 PM, Martin Frb via fpc-pascal
> wrote:
>
> Actually, it's dealing with SmallInt (or ShortInt). And if the programmer
> does not know that, then it might be an issue...
>
> Imagine the generic code (something more complex than "Add") would somehow do
> something t
On 25/04/22 05:15, Hairy Pixels via fpc-pascal wrote:
generic function Add(left, right: T): T;
And the programmer intends to call it like:
Add(1,1);
Why should the programmer need to tell the compiler it’s dealing with Integer
when it’s so obvious from the types being used?
Actuall
16 matches
Mail list logo
