Am 30.11.19 um 20:41 schrieb J. Gareth Moreton:
My programming buddy has been asking me this question as well, and I can
only say "I don't know". Do we have a release candidate though?
No. https://bugs.freepascal.org/roadmap_page.php has still open entries.
On 30/11/2019 13:04, Marco van
My programming buddy has been asking me this question as well, and I can
only say "I don't know". Do we have a release candidate though?
On 30/11/2019 13:04, Marco van de Voort wrote:
Op 2019-11-30 om 09:29 schreef Gabor Boros:
2019. 05. 30. 9:05 keltezéssel, Michael Van Canneyt írta:
I
Op 2019-11-30 om 09:29 schreef Gabor Boros:
2019. 05. 30. 9:05 keltezéssel, Michael Van Canneyt írta:
I would not count on it before september, and even that is "iffy".
Any news/update in this subject?
The fixes_3_2 branch created more than a year ago and the latest
stable (3.0.4) released
2019. 05. 30. 9:05 keltezéssel, Michael Van Canneyt írta:
I would not count on it before september, and even that is "iffy".
Any news/update in this subject?
The fixes_3_2 branch created more than a year ago and the latest stable
(3.0.4) released 2 years ago.
Gabor
> On Jun 2, 2019, at 4:36 PM, Sven Barth via fpc-devel
> wrote:
>
> Am 02.06.2019 um 16:39 schrieb Ryan Joseph:
>> I just tried to declare these 2 procedures in 3.3.1 and got an error. You
>> can declare them in the reverse order with no problem. A bug?
>>
>> generic procedure DoThis(msg:
Am 02.06.2019 um 16:39 schrieb Ryan Joseph:
I just tried to declare these 2 procedures in 3.3.1 and got an error. You can
declare them in the reverse order with no problem. A bug?
generic procedure DoThis(msg: T);
begin
end;
procedure DoThis(msg: TObject); // Overloaded identifier "DoThis"
I just tried to declare these 2 procedures in 3.3.1 and got an error. You can
declare them in the reverse order with no problem. A bug?
generic procedure DoThis(msg: T);
begin
end;
procedure DoThis(msg: TObject); // Overloaded identifier "DoThis" isn't a
function
begin
end;
Regards,
On Sat, 1 Jun 2019, Ben Grasset wrote:
On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
I personally consider it a worthwhile addition.
What version did Delphi add that in? I honestly had no idea it was a thing.
Makes it seem especially
Ben Grasset schrieb am Sa., 1. Juni 2019, 22:49:
> On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
>
>> I personally consider it a worthwhile addition.
>>
>
> What version did Delphi add that in? I honestly had no idea it was a thing.
>
I
> On Jun 1, 2019, at 6:00 AM, Michael Van Canneyt
> wrote:
>
> I don't think this syntax is a good idea.
>
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
Currently the non-generic gets called in this situation. That’s because
non-generic procedures
I would personally consider this a
compiler error because there's too much
ambiguity and assumption involved when
choosing one over the other. In my eyes,
the correct choice is too unclear.
Gareth aka. Kit
On Sat 01/06/19 21:41 , Ben Grasset
operato...@gmail.com sent:
> On Sat, Jun 1, 2019
On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> I personally consider it a worthwhile addition.
>
What version did Delphi add that in? I honestly had no idea it was a thing.
Makes it seem especially strange that they still don't have
On Sat, Jun 1, 2019 at 6:00 AM Michael Van Canneyt
wrote:
> I don't think this syntax is a good idea.
>
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
>
> How do I know which one will be called ?
>
I think it would have to work like: if something is a
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
14:13:
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
specialize ClearMem(pt);
With implicit specialization:
ClearMem(pt); // :)
I don't think this syntax is a good
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
14:13:
>
>
> On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
>
> >>>
> >>> specialize ClearMem(pt);
> >>>
> >>> With implicit specialization:
> >>>
> >>> ClearMem(pt); // :)
> >>
> >> I don't think this syntax is a good idea.
> >>
> >
>
>> Really ?
>> I wonder what kind of code you write to make this 'super buggy' statement.
>>
>> I myself write lots of code, and never encountered an issue.
>> But then, I normally don't use dubious constructs to begin with.
> In fact, we already have several bug reports related to
On Sat, 1 Jun 2019, denisgolovan wrote:
Really ?
I wonder what kind of code you write to make this 'super buggy' statement.
I myself write lots of code, and never encountered an issue.
But then, I normally don't use dubious constructs to begin with.
In general of course I agree 100% with
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
specialize ClearMem(pt);
With implicit specialization:
ClearMem(pt); // :)
I don't think this syntax is a good idea.
It's required for Delphi compatibility.
Indeed. It gets worse by the day :(
Michael.
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
12:00:
>
>
> On Fri, 31 May 2019, Ryan Joseph wrote:
>
> >
> >
> >> On May 30, 2019, at 4:18 PM, Ryan Joseph
> wrote:
> >>
> >> I didn’t realize generic functions were in the trunk. I’m not sure I
> got this implemented properly so it requires
> Really ?
> I wonder what kind of code you write to make this 'super buggy' statement.
>
> I myself write lots of code, and never encountered an issue.
> But then, I normally don't use dubious constructs to begin with.
>
> In general of course I agree 100% with your statement that we need a
On Sat, 1 Jun 2019, Martok wrote:
What with overloads ?
Procedure MyProc(a:T);
Procedure MyProc(a : TObject);
How do I know which one will be called ?
Once again: FPC needs a defined method resolution order, *and stick with it*.
The current ad-hoc inheritance/typeconv/:=
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
>
> How do I know which one will be called ?
Once again: FPC needs a defined method resolution order, *and stick with it*.
The current ad-hoc inheritance/typeconv/:= overload/overload/operator overload
mess is
On Fri, 31 May 2019, Ryan Joseph wrote:
On May 30, 2019, at 4:18 PM, Ryan Joseph wrote:
I didn’t realize generic functions were in the trunk. I’m not sure I got this
implemented properly so it requires some code review but can we try to include
“implicitfunctionspecialization” mode
Now I can see how that can be very useful, and certainly a lot cleaner
and less error-prone. I do wonder what it will do in regards to
suppressing that annoying "uninitialized variable" warning though when
passing said variable into FillChar to, you know, actually initialise it!
Admittedly,
Op 2019-05-31 om 18:36 schreef Alexander Grotewohl:
can't you just use an untyped parameter in a clearmem procedure you
make yourself?
procedure ClearMem(var m);
You don't get size that way, and you have to pass it separately (see
e.g. blockread/write).
It was one of the setbacks when I
can't you just use an untyped parameter in a clearmem procedure you make yourself?procedure ClearMem(var m);--Alexander Grotewohlhttp://dcclost.com___
fpc-devel maillist - fpc-devel@lists.freepascal.org
> On May 30, 2019, at 4:18 PM, Ryan Joseph wrote:
>
> I didn’t realize generic functions were in the trunk. I’m not sure I got this
> implemented properly so it requires some code review but can we try to
> include “implicitfunctionspecialization” mode switch in the next release
> along the
On Thu, 30 May 2019, Marco van de Voort wrote:
Op 2019-05-30 om 11:43 schreef Michael Van Canneyt:
The branch has been made, I am slowly bringing the documentation
up-to-date,
Speaking of which, I enabled unit bufdatatset in the FCL docs
yesterday. I thought the stale references were a
Op 2019-05-30 om 11:43 schreef Michael Van Canneyt:
The branch has been made, I am slowly bringing the documentation
up-to-date,
Speaking of which, I enabled unit bufdatatset in the FCL docs
yesterday. I thought the stale references were a bug in fpdoc/chm,
turned out the unit was simply
On Thu, 30 May 2019, Marco van de Voort wrote:
Op 2019-05-30 om 09:05 schreef Michael Van Canneyt:
The branch has been made, I am slowly bringing the documentation
up-to-date,
Speaking of which, I enabled unit bufdatatset in the FCL docs yesterday.
I thought the stale references were a
Op 2019-05-30 om 09:05 schreef Michael Van Canneyt:
The branch has been made, I am slowly bringing the documentation
up-to-date,
Speaking of which, I enabled unit bufdatatset in the FCL docs yesterday.
I thought the stale references were a bug in fpdoc/chm, turned out the
unit was simply
On Thu, 30 May 2019, J. Gareth Moreton wrote:
Hi everyone,
This might not be the best place to ask, but my programming buddy keeps
bugging me about it, since he wants access to generic functions and the
volatile intrinsic. When will the next version of FPC be officially
released?
No
Hi everyone,
This might not be the best place to ask, but my programming buddy keeps
bugging me about it, since he wants access to generic functions and the
volatile intrinsic. When will the next version of FPC be officially
released?
Gareth aka. Kit
---
This email has been checked for
33 matches
Mail list logo
