Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
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 work wit ObjectPascal streams). Hello, .gz is a quite simple format, but it can not be implemented as a TStream (only) descendant because in a single .gz file many files could be added so something like the class to handle .zip files should be used. 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 container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? 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 (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto joshy...@gmail.com 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/TDecompressionStream (no gzip format) or TGZFileStream (not able to work wit ObjectPascal streams). Hello, .gz is a quite simple format, but it can not be implemented as a TStream (only) descendant because in a single .gz file many files could be added so something like the class to handle .zip files should be used. 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 container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? 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 (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. -- 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. -Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Warning: crti.o and crtn.o not found
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(20,1) Warning: crti.o not found, this will probably cause a linking failure hello.lpr(20,1) Warning: crtn.o not found, this will probably cause a linking failure Project hello successfully built Curious TIA ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Feature proposal: function-based assignment operators
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[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; More generally, if func is a 2-ary function, of type type(a) = type(b) = type(a), the syntax a func= b should become a := func(a, b) (Or alternatively the syntax a : func = b; might be easier to parse) Benito ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Warning: crti.o and crtn.o not found
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 messages ... Options changed, recompiling clean with -B hello.lpr(20,1) Warning: crti.o not found, this will probably cause a linking failure hello.lpr(20,1) Warning: crtn.o not found, this will probably cause a linking failure Project hello successfully built What about providing information on contents of your hello.lpr? It might shed some light on why crti.o and crtn.o are considered as required by the compiler (although in the end they are not needed for linking apparently?). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature proposal: function-based assignment operators
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.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Warning: crti.o and crtn.o not found
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Warning: crti.o and crtn.o not found
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 need the relevant base library for C development for your distribution. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 minimum. For example: 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; 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. There really are limits to the extent that the underlying Pascal should be mangled further. Your time would be better spent trying to persuade the core developers to tolerate extra operators like ⌊ for floor(), and then working out how to implement them :-) array1[array2[i]] := array1[array2[i]] ⌊ 42; array1[array2[i]] ⌊= 42; -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
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/manual/gzip.html#Advanced-usage says clearly that Multiple compressed files can be concatenated. It doesn't mean that gzip is a good format to keep multiple-file archive (for this you should use tar), as multiple compressed files will be decompressed to a single stream on output. Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Feature proposal: function-based assignment operators
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... 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.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 addition, but the minimum.
For example:
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;
More generally, if func is a 2-ary function, of type type(a) =
type(b) = type(a), the syntax
a func= b
should become a := func(a, b)
(Or alternatively the syntax a : func = b; might be easier to parse)
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:
=== code begin ===
program mintest;
{$mode objfpc}
uses
Math;
type
TLongIntHelper = type helper for LongInt
procedure Min(aValue: LongInt);
end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
Self := Math.Min(Self, aValue);
end;
var
arr: array[0..20] of LongInt;
i: LongInt;
begin
for i := Low(arr) to High(arr) do
arr[i] := i;
for i := Low(arr) to High(arr) do
Write(arr[i], ' ');
Writeln;
arr[15].Min(10); // arr[15] is passed as Self to Min
for i := Low(arr) to High(arr) do
Write(arr[i], ' ');
Writeln;
end.
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Feature proposal: function-based assignment operators
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 x contains a function call with side effects, these side effects are still triggered twice. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature proposal: function-based assignment operators
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-operators-tp5713868p5713878.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
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 container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? 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 (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. Yeah, you're right indeed. Sorry for the noise. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 cool, but I only have 2.6.2...
type
TLongIntHelper = type helper for LongInt
procedure Min(aValue: LongInt);
end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
Self := Math.Min(Self, aValue);
end;
Perhaps that should be defined in the rtl
On 03/28/2013 05:47 PM, Sven Barth wrote:
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 addition, but the minimum.
For example:
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;
More generally, if func is a 2-ary function, of type type(a) =
type(b) = type(a), the syntax
a func= b
should become a := func(a, b)
(Or alternatively the syntax a : func = b; might be easier to parse)
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:
=== code begin ===
program mintest;
{$mode objfpc}
uses
Math;
type
TLongIntHelper = type helper for LongInt
procedure Min(aValue: LongInt);
end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
Self := Math.Min(Self, aValue);
end;
var
arr: array[0..20] of LongInt;
i: LongInt;
begin
for i := Low(arr) to High(arr) do
arr[i] := i;
for i := Low(arr) to High(arr) do
Write(arr[i], ' ');
Writeln;
arr[15].Min(10); // arr[15] is passed as Self to Min
for i := Low(arr) to High(arr) do
Write(arr[i], ' ');
Writeln;
end.
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 the core developers to tolerate extra operators like ⌊ for floor(), and then working out how to implement them :-) Or allow unicode identifier, and than defining ⌊ for ⌊= would just be a special case of func= On 03/28/2013 04:45 PM, Mark Morgan Lloyd wrote: 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 minimum. For example: 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; 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. There really are limits to the extent that the underlying Pascal should be mangled further. Your time would be better spent trying to persuade the core developers to tolerate extra operators like ⌊ for floor(), and then working out how to implement them :-) array1[array2[i]] := array1[array2[i]] ⌊ 42; array1[array2[i]] ⌊= 42; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
Once upon a time, Flávio Etrusco said: On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto joshy...@gmail.com 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 (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. -- 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. Alright, now I am contradicting what I said earlier, but there can apparently be more than one file in a gzipped `thing`: see https://en.wikipedia.org/wiki/Gzip#File_format . It is not really all files in one container, but more like concatenating serveral of these one-file gzipped files, if you see what I mean. Anyway, I've never seen it happen, so I'm going to leave it at that before I start sounding silly ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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]],42); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 find out what happens here. What is assigned to what and when? Why making Pascal look like C instead of using C? In the example case I would prefer the original or write if array1[array2[i]]42 then array1[array2[i]] := 42; or if performance is realy an issue you I would use an intermediate pointer to the array type: var p : ^arrayelementtype; p := @array1[array2[i]]; p^ := min(p^,42); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 or write In the real program I ended up with if array1[array2[i]]42 then array1[array2[i]] := 42; Then you have everything twice. And if you have to change i to j, you might forget to change one On 03/28/2013 06:26 PM, Jürgen Hestermann wrote: 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 find out what happens here. What is assigned to what and when? Why making Pascal look like C instead of using C? In the example case I would prefer the original or write if array1[array2[i]]42 then array1[array2[i]] := 42; or if performance is realy an issue you I would use an intermediate pointer to the array type: var p : ^arrayelementtype; p := @array1[array2[i]]; p^ := min(p^,42); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
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 that, but I couldn't put my finger on it :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
Am 28.03.2013 18:02 schrieb Benito van der Zander ben...@benibela.de: 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 necessarily make them desireable. You can achieve a similar effect through type helpers in 2.7.1 though: looks cool, but I only have 2.6.2... Then you'll need to wait until 2.8.0 is released (and no, I don't have an estimate). And even if we'd implement your proposal you'd need to wait for the next major version... type TLongIntHelper = type helper for LongInt procedure Min(aValue: LongInt); end; procedure TLongIntHelper.Min(aValue: LongInt); begin Self := Math.Min(Self, aValue); end; Perhaps that should be defined in the rtl Some helper could be defined in additional units, but the problem with them is that only one per type can be active at a time (Delphi compatible). My plan is to change this though, but for this I first need to define proper search rules for this... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operatorst
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 to be consistent, don't turn it on :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature proposal: function-based assignment operatorst
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-proposal-function-based-assignment-operators-tp5713868p5713890.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Feature proposal: function-based assignment operatorst
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 context: http://free-pascal-general.1045716.n5.nabble.com/Feature-proposal-function-based-assignment-operators-tp5713868p5713890.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature proposal: function-based assignment operators
2013/3/29 Sven Barth 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 achieve a similar effect through type helpers in 2.7.1 though: Using type helper here may result in apparently same effect. But in fact they are very different. The syntax OP proposed is a mechanism of the language (compiler), i.e. support will be ubiquitous, but if you implement it with type helper, then you have to write the helper (or use it) every time you need such very tiny feature (if not just save typing), which voids the whole idea of make the source code simpler. Unless you put such helper into the RTL, which will be similar to the OP's proposal, but not as elegant. My opinion is that I like this feature, but I don't mind if it is implemented or not. That will indeed make the syntax more complex and a little un-pascal-ish. 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? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature proposal: function-based assignment operators
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 compiler. Inc/Dec is always processor's single inc/dec instruction AFAIK (at least that's how it's implemented if you dig in to their code). -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Feature-proposal-function-based-assignment-operators-tp5713868p5713893.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
