> As to the C-style += operator, I have one question, will it makes code
slightly faster? because if you use Inc() or Dec() there will be a function
call? or, the compiler will always try to inline Inc or Dec?
No, as been explained, it's internally translated to the equivalent non-C
style by the
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
Same here.
M
On Mar 28, 2013, at 6:21 PM, leledumbo wrote:
Good point. So to be consistent, don't turn it on :-)
NEVER turn it on for me :-)
If only I'm the core dev, I would mark the C operator feature as
deprecated
and remove it in the next major version.
--
View this message in contex
> Good point. So to be consistent, don't turn it on :-)
NEVER turn it on for me :-)
If only I'm the core dev, I would mark the C operator feature as deprecated
and remove it in the next major version.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Feature-pr
In our previous episode, Benito van der Zander said:
> > 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 +=
Good point. So t
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
Once upon a time, Flávio Etrusco said:
> On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto wrote:
>
>> Hello,
>>
>> Just quoting the RFC1952 about .gz format:
>>
>> --- http://tools.ietf.org/html/rfc1952
>>
>> 2.2. File format
>>
>> A gzip file consists of a series of "members" (compress
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
Once upon a time, José Mejuto said:
> El 28/03/2013 1:06, Ewald escribió:
>> Sorry to just drop in on this quite late, but isn't gzip a
>> compression algorithm and not a file format as such? gzip (the
>> command line utility) only compresses one file and *doesn't* put this
>> in a multi-file cont
> Same benefit as += to := ... +
> You do not need to rewrite/compute the left side
Save typing only then, the same mistake the C style operator support have
done.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Feature-proposal-function-based-assignment-oper
On 28 Mar 2013, at 17:50, Benito van der Zander wrote:
>> What's the benefit?
> Same benefit as += to := ... +
>
> You do not need to rewrite/compute the left side
+= does *not* prevent re-evaluating the left side. It is internally translated
to "x:=x+y" and then evaluated like normal. So if "
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
What's the benefit?
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
How will it affect existing code?
Not at all, since old code using this, would not compile
Last but not least, will you implement it?
I can try
On 03/28/2013 04:20 PM, leledumbo wrote:
Hmm..
Flávio Etrusco wrote:
"Members" refer to each available section according to the flags.
Re-read this whole paragraph you posted and a few following you'll
realize only one "file" is allowed in a gzip file/blob.
I think this confusion comes from the fact that
http://www.gnu.org/software/gzip/m
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
In our previous episode, Anthony Walter said:
> What is causing warnings for "crti.o" and "crtn.o" as described below?
The fact that they don't exist :-)
Which in turn is probably due to the fact that the system hasn't been
prepared for C development, and you are linking to C libs.
Probably you
https://blogs.oracle.com/ahl/entry/the_mysteries_of_init
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Warning-crti-o-and-crtn-o-not-found-tp5713867p5713871.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
_
Hmm... Haskell? Or Nimrod? Or something else? What's the benefit? How will it
affect existing code? Last but not least, will you implement it?
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Feature-proposal-function-based-assignment-operators-tp5713868p5713870
On Thu, March 28, 2013 15:30, Anthony Walter wrote:
> What is causing warnings for "crti.o" and "crtn.o" as described below?
>
> I just got the latest fpc and lazarus from svn, and after build everything
> I wrote a "Hello World" Gtk2 test project on Ubuntu 12.04 (32 bit) with
> the
> following mes
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 minimum.
For example:
array1[ar
What is causing warnings for "crti.o" and "crtn.o" as described below?
I just got the latest fpc and lazarus from svn, and after build everything
I wrote a "Hello World" Gtk2 test project on Ubuntu 12.04 (32 bit) with the
following messages ...
Options changed, recompiling clean with -B
hello.lpr
On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto wrote:
> El 28/03/2013 1:06, Ewald escribió:
>
>
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/
El 28/03/2013 1:06, Ewald escribió:
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to wor
29 matches
Mail list logo
