Sven Barth schrieb am Sa., 14. Dez. 2019,
18:18:
> Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru:
> >
> > @Jonas: Has the team decided on the amended syntax for C-block
> > references? I am ready to start implementing whichever.
> >
> In r43684 the syntax was now adjusted, so that an
On 14/12/2019 20:18, Ryan Joseph via fpc-devel wrote:
>> On Dec 14, 2019, at 12:18 PM, Sven Barth via fpc-devel
>> wrote:
>>
>> In r43684 the syntax was now adjusted, so that an additional "cblock"
>> directive is required (in addition to the calling convention which for macOS
>> can be cdecl
> On Dec 14, 2019, at 12:18 PM, Sven Barth via fpc-devel
> wrote:
>
> In r43684 the syntax was now adjusted, so that an additional "cblock"
> directive is required (in addition to the calling convention which for macOS
> can be cdecl or mwpascal).
can you please post an example snippet of
Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru:
@Jonas: Has the team decided on the amended syntax for C-block
references? I am ready to start implementing whichever.
In r43684 the syntax was now adjusted, so that an additional "cblock"
directive is required (in addition to the calling
Am 12.12.2019 um 23:24 schrieb Ryan Joseph via fpc-devel:
On Dec 12, 2019, at 11:13 AM, Martin Frb wrote:
I brought an example, where actually the "drop [] for last param" would break
code.
Therefore it no longer matters if it is or is not against good design. Dropping
the [], (in the new
> On Dec 12, 2019, at 11:13 AM, Martin Frb wrote:
>
> I brought an example, where actually the "drop [] for last param" would break
> code.
> Therefore it no longer matters if it is or is not against good design.
> Dropping the [], (in the new case, for last param) will break code that
>
On 12/12/2019 17:05, Sven Barth via fpc-devel wrote:
For array of const it is not allowed, but any other open array
parameter allows it.
Ah, interesting.
So then there stands my point from the first mail I wroth in this thread:
IIRC
- the "do not drop []" arguments, where based on design
On Thu, 12 Dec 2019, Michael Van Canneyt wrote:
On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote:
Michael Van Canneyt schrieb am Do., 12. Dez. 2019,
15:34:
It was already mentioned, that the [] can be dropped if the array has
*exactly one* element.
Not sure what you mean here, but
On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote:
Michael Van Canneyt schrieb am Do., 12. Dez. 2019,
15:34:
It was already mentioned, that the [] can be dropped if the array has
*exactly one* element.
Not sure what you mean here, but even if there is only 1 argument, today
the []
Michael Van Canneyt schrieb am Do., 12. Dez. 2019,
15:34:
> > It was already mentioned, that the [] can be dropped if the array has
> > *exactly one* element.
>
> Not sure what you mean here, but even if there is only 1 argument, today
> the [] cannot be dropped:
>
> home:~> cat tf.pp
> program
On 12/12/2019 15:34, Michael Van Canneyt wrote:
On Thu, 12 Dec 2019, Martin Frb wrote:
That still would not break, but it actually is the base for something
that would break.
The point was to demonstrate that array of const is 1 argument. It is
not equal to a variable number of arguments.
On Thu, 12 Dec 2019, Martin Frb wrote:
It does gain something: it tells you it is NOT a varargs, but an
array of
const, which is a different beast altogether.
But it's a syntax equivalent for "a variable amount of arguments",
i.e. varargs. ;) I guess others don't see it this way however.
On 12/12/2019 08:51, Michael Van Canneyt wrote:
On Wed, 11 Dec 2019, Ryan Joseph via fpc-devel wrote:
On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt
wrote:
It does gain something: it tells you it is NOT a varargs, but an
array of
const, which is a different beast altogether.
But
On Wed, 11 Dec 2019, Ryan Joseph via fpc-devel wrote:
On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt wrote:
It does gain something: it tells you it is NOT a varargs, but an array of
const, which is a different beast altogether.
But it's a syntax equivalent for "a variable amount of
Am 11.12.2019 um 23:40 schrieb Ryan Joseph via fpc-devel:
On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt wrote:
It does gain something: it tells you it is NOT a varargs, but an array of
const, which is a different beast altogether.
But it's a syntax equivalent for "a variable amount of
> On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt
> wrote:
>
> It does gain something: it tells you it is NOT a varargs, but an array of
> const, which is a different beast altogether.
But it's a syntax equivalent for "a variable amount of arguments", i.e.
varargs. ;) I guess others don't
Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru:
On 08.12.2019 22:30, Sven Barth wrote:
there is no official way to access such parameters
1) At the time of providing that answer on Stack Overflow, Barry Kelly
worked as a DCC developer. While it is not truly official, it is
pretty close,
On Wed, 11 Dec 2019, Ryan Joseph via fpc-devel wrote:
On Dec 10, 2019, at 5:14 PM, Sven Barth via fpc-devel
wrote:
From the view of the *caller* you are mostly right. Though the square brackets
can't be left away, cause we're talking about an array parameter here. If it
would be
> On Dec 10, 2019, at 5:14 PM, Sven Barth via fpc-devel
> wrote:
>
> From the view of the *caller* you are mostly right. Though the square
> brackets can't be left away, cause we're talking about an array parameter
> here. If it would be allowed for array of const then it would also need to
Ryan Joseph via fpc-devel schrieb am Di.,
10. Dez. 2019, 22:29:
>
>
> > On Dec 10, 2019, at 11:38 AM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> >
> > First of Object Pascal supports "array of const" which is safer due to a
> added type field for each entry.
> >
>
>
> On Dec 10, 2019, at 11:38 AM, Sven Barth via fpc-devel
> wrote:
>
> First of Object Pascal supports "array of const" which is safer due to a
> added type field for each entry.
>
From the users standpoint only real difference is the [] syntax and if the
array of const is the last (or
Op 2019-12-08 om 22:08 schreef Ryan Joseph via fpc-devel:
On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel
wrote:
And no, your patch WILL NOT allow that. We've consciously decided AGAINST
implementing varargs functions in Pascal (see
Ryan Joseph via fpc-devel schrieb am So.,
8. Dez. 2019, 23:26:
>
>
> > On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> >
> > And no, your patch WILL NOT allow that. We've consciously decided
> AGAINST implementing varargs functions in Pascal (see
On 09.12.2019 11:18, Jonas Maebe wrote:
replying to almost every line of every mail how every different way of saying
more or less the same thing is wrong.
I take issue with that description. Sven was not "saying more or less the same thing" in
"different way". Instead, on every next step,
On 2019-12-09 01:03, bla...@blaise.ru wrote:
there is no stock implementation in Delphi for *any* platform
You remind me of a certain Rudy from the old EMBT forums. It is one
thing to not know something due to the lack of experience (with DCC),
but to keep insisting despite being repeatedly
On 08.12.2019 22:30, Sven Barth wrote:
there is no official way to access such parameters
1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC
developer. While it is not truly official, it is pretty close, and satisfies my criterion
of "fully conforming to
> On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel
> wrote:
>
> And no, your patch WILL NOT allow that. We've consciously decided AGAINST
> implementing varargs functions in Pascal (see
> https://wiki.freepascal.org/User_Changes_2.6.0#Array_of_const_parameters_and_cdecl_routines
> )
Am 07.12.2019 um 22:46 schrieb bla...@blaise.ru:
On 07.12.2019 21:39, Sven Barth wrote:
I'm arguing that there is no builtin way to *access* the parameters
passed in such a way.
You are arguing that /now/, but it is not what you said earlier. You
said, verbatim:
one can not access VarArgs
On 07.12.2019 21:39, Sven Barth wrote:
I'm arguing that there is no builtin way to *access* the parameters passed in
such a way.
You are arguing that /now/, but it is not what you said earlier. You said,
verbatim:
one can not access VarArgs parameters inside a Delphi function (without
Am 07.12.2019 um 14:31 schrieb bla...@blaise.ru:
your argument with VarArgs does not count either: one can not access
VarArgs parameters inside a Delphi function (without resorting to
assembly)
Again, you are misinformed.
I understand that you may not use DCC as much or at all, but you have
On 07.12.2019 14:21, Sven Barth wrote:
I stand by my point that the combination of anonymous function variables with
calling conventions and cblocks occurs very, very seldomly.
I am not necessarily disputing that point, I am disputing your design decision,
which was misinformed, but you
On Sat, 7 Dec 2019, Sven Barth via fpc-devel wrote:
Am 07.12.2019 um 10:28 schrieb Jonas Maebe:
If there is a consensus that this is a blocker, I am ready to do the
work ASAP. provided we select the syntax. Personally, I am inclined
towards these three:
type M = procedure (const N:
Am 07.12.2019 um 10:28 schrieb Jonas Maebe:
If there is a consensus that this is a blocker, I am ready to do the
work ASAP. provided we select the syntax. Personally, I am inclined
towards these three:
type M = procedure (const N: Integer) with var;
type M = procedure (const N:
Am 07.12.2019 um 01:00 schrieb bla...@blaise.ru:
Beforehand, to provide a context, here are some excerpts from private
correspondence:
On 11.12.2016 22:00:37 +0300, bla...@blaise.ru wrote in
1c51a35a-bbbc-c99d-232f-0bf6529df...@blaise.ru:
my progress thus far
9) Method reference directives
On 2019-12-07 01:00, bla...@blaise.ru wrote:
3) My first example back in 2016 intentionally featured a valid use
case: CDECL is crucial for VARARGS. (Somehow, not only that case, but
the whole point that DCC accepts calling conventions went unnoticed.)
I indeed did not know that.
I wonder
On Sat, 7 Dec 2019, bla...@blaise.ru wrote:
Beforehand, to provide a context, here are some excerpts from private
correspondence:
If there is a consensus that this is a blocker, I am ready to do the work
ASAP. provided we select the syntax. Personally, I am inclined towards these
three:
36 matches
Mail list logo
