>
> No, there is no difference, because even if we would implement support for
> "function based operators" we would not implement any default ones or only
> provide them with an additional unit. So you either need to implement them
> yourself or use an additional unit anyway.
I mean, with the pr
On 29.03.2013 03:03, Xiangrong Fang wrote:
2013/3/29 Sven Barth mailto:pascaldra...@googlemail.com>>
There was already a discussion some time ago whether we should allow
operators like "or=" and such as well and the result was simple: no.
I consider this the same here.
You can a
2013/3/29 Sven Barth
> There was already a discussion some time ago whether we should allow
> operators like "or=" and such as well and the result was simple: no. I
> consider this the same here.
>
> You can achieve a similar effect through type helpers in 2.7.1 though:
>
Using type helper here
Am 28.03.2013 18:02 schrieb "Benito van der Zander" :
>>
>>
>> There was already a discussion some time ago whether we should allow
operators like "or=" and such as well and the result was simple: no. I
consider this the same here.
>
>
> But it would be more consistent with +=
Consistency does not
Sven Barth wrote:
type
TLongIntHelper = type helper for LongInt
procedure Min(aValue: LongInt);
end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
Self := Math.Min(Self, aValue);
end;
arr[15].Min(10); // arr[15] is passed as Self to Min
I thought there was something like
Now *that* is ugly. It would take me quite a while to find out what
happens here.
Perhaps :min= was better?
Why making Pascal look like C instead of using C?
C also does not support this :(
And it does not have arbitrary array index ranges
In the example case I would prefer the original
Benito van der Zander wrote:
array1[array2[i]] := min(array1[array2[i]], 42);
Now, you need to repeat all the array indices.
Which is very ugly.
So there should be an alternative syntax, similar to += :
I.e.:
array1[array2[i]] min= 42;
Now *that* is ugly. It would take me quite a while to fi
I would use Pascal (not C) and write
inc(array1[array2[i]],42);
well, that won't help with min
On 03/28/2013 06:14 PM, Jürgen Hestermann wrote:
Benito van der Zander wrote:
Luckily this can be written as
array1[array2[i]] += 42;
I would use Pascal (not C) and write
inc(array1[array2[i]
Benito van der Zander wrote:
Luckily this can be written as
array1[array2[i]] += 42;
I would use Pascal (not C) and write
inc(array1[array2[i]],42);
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/li
Declare a custom function and mark it inline for efficiency. That also
allows you to document it properly, have different implementations
depending on the parameter types and so on.
that's overkill if it is only an internal datastructure
our time would be better spent trying to persuade t
There was already a discussion some time ago whether we should allow
operators like "or=" and such as well and the result was simple: no. I
consider this the same here.
But it would be more consistent with +=
You can achieve a similar effect through type helpers in 2.7.1 though:
looks coo
Am 28.03.2013 16:23, schrieb Benito van der Zander:
Hi,
quite often you need to change a value relatively to another value.
For example:
array1[array2[i]] := array1[array2[i]] + 42;
Luckily this can be written as
array1[array2[i]] += 42;
Which is nice.
However, sometimes you do not need
Benito van der Zander wrote:
Hi,
quite often you need to change a value relatively to another value.
For example:
array1[array2[i]] := array1[array2[i]] + 42;
Luckily this can be written as
array1[array2[i]] += 42;
Which is nice.
However, sometimes you do not need addition, but the minim
13 matches
Mail list logo
