Am 07.07.2011 08:35, schrieb Alexander Klenin:
As further support for #1, consider: With a class, you do not have to pass
it to a procedure as var, but when you modify the instance, you modify the
same instance as was passed to the procedure. That is how classes work.
Having a variable point
On Thu, Jul 7, 2011 at 17:45, Florian Klaempfl flor...@freepascal.org wrote:
Put in another words, current const string implementation honors the
implicit contract of
adding const in front of the string parameter cancels refcounting,
at the cost of breaking the implicit contract of refcounted
On Thu, 7 Jul 2011, Chad Berchek wrote:
Michael wrote:
You can always fool the compiler. The compiler trusts you and assumes
that what you tell her is true...
Yes, of course you can always fool the compiler, it just shouldn't be
the other way around. The example you gave is very different
On Thu, 07 Jul 2011 00:15:54 -0500
Chad Berchek ad...@vobarian.com wrote:
[...]
The difference between a feature and a bug is the specifications. Here
the specifications are the documentation. I have not found any
documentation in either FPC or Delphi that there is some implicit
contract
Chad Berchek schrieb:
Thaddy wrote:
It is a contract between the compiler and the programmer in which it
is expected that the string will not be modified inside a procedure,
function or method.
This is the crux of the controversy. I realized this when I was writing
the original post, but
On 07/07/2011 07:51, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 17:45, Florian Klaempflflor...@freepascal.org wrote:
Put in another words, current const string implementation honors the
implicit contract of
adding const in front of the string parameter cancels refcounting,
at the cost of
Martin f...@mfriebe.de hat am 7. Juli 2011 um 12:20 geschrieben:
On 07/07/2011 07:51, Alexander Klenin wrote:
[...]
As I have shown before in this thread, non ref. counted values e.g.
shortstrings are affected by the same problem.
And as per Chad's reply (and agree with his
On 07/07/2011 11:43, Mattias Gaertner wrote:
You don't need the future. You can already create a crash using const
shortstring:
Indeed, thanks for the example.
And with this example there is another potential issue arising from not
honouring the contract of const.
The behaviour of such
On Thu, 7 Jul 2011, Mattias Gaertner wrote:
Martin f...@mfriebe.de hat am 7. Juli 2011 um 12:20 geschrieben:
On 07/07/2011 07:51, Alexander Klenin wrote:
[...]
As I have shown before in this thread, non ref. counted values e.g.
shortstrings are affected by the same problem.
And
On Thu, Jul 7, 2011 at 22:10, michael.vancann...@wisa.be wrote:
Sigh
That's what I've been saying all along. You don't even need strings for it.
Plain records and integers will do it just as well.
Well, I am sorry, but do you all (not only Michael, I'm just
responding to the last mail in
On Thu, 7 Jul 2011, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 22:10, michael.vancann...@wisa.be wrote:
Sigh
That's what I've been saying all along. You don't even need strings for it.
Plain records and integers will do it just as well.
Well, I am sorry, but do you all (not only
On 07/07/2011 12:42, Alexander Klenin wrote:
I'll re-iterate again:
1) The reference counting is not just an optimization, it is also a
memory management technique,
an important concept which is aimed at providing simple value
semantics for heap-allocated structures,
and insulating the
Based on this promise, the compiler may decide to do some optimization.
It will also warn you if it detects inside the code that you break
your promise.
Based on my new knowledge of const strings I revisited the bug I
mentioned previously. I still have no idea where exactly I made the
error.
On Thu, 7 Jul 2011, Wimpie Nortje wrote:
Based on this promise, the compiler may decide to do some optimization.
It will also warn you if it detects inside the code that you break
your promise.
Based on my new knowledge of const strings I revisited the bug I
mentioned previously. I still
On 07/07/2011 14:14, michael.vancann...@wisa.be wrote:
On Thu, 7 Jul 2011, Wimpie Nortje wrote:
For me the advantages of using const strings are completely dwarfed by
the time required to ensure I keep my side of the promise and still have
the risk that some small change in the future will
On Thu, Jul 7, 2011 at 23:09, Martin f...@mfriebe.de wrote:
I do think Florians, or Mattias example are relevant.
Let's for a moment ignore the const ansistring issue.
The 2 examples prove, that even with const i : SomeRecord, your code can
crash for none obvious reasons, IF you break the
michael.vancann...@wisa.be hat am 7. Juli 2011 um 13:10 geschrieben:
[..]
That's what I've been saying all along. You don't even need strings for it.
Plain records and integers will do it just as well.
Yes.
I hope the example helps people understanding this.
Maybe an example can be
On Thu, 7 Jul 2011, Mattias Gaertner wrote:
michael.vancann...@wisa.be hat am 7. Juli 2011 um 13:10 geschrieben:
[..]
That's what I've been saying all along. You don't even need strings for it.
Plain records and integers will do it just as well.
Yes.
I hope the example helps people
On Fri, Jul 8, 2011 at 00:14, michael.vancann...@wisa.be wrote:
Given that Borland never decided to 'fix' it, I'm inclined to think that
they also don't consider it a real problem, but rather a corner case
(if they are aware of it at all).
Hm. My testing indicates that Delphi has this fixed
Martin schrieb:
The original example ( a bug on mantis) had little strangeness. A global
variable being modified in an OnChange handler of a TEdit.
This could very, very easily happen.
One of the reasons why *global variables* should be avoided.
DoDi
On 07/07/2011 15:04, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 23:09, Martinf...@mfriebe.de wrote:
I do think Florians, or Mattias example are relevant.
Let's for a moment ignore the const ansistring issue.
The 2 examples prove, that even with const i : SomeRecord, your code can
crash
On 07/07/2011 16:14, Hans-Peter Diettrich wrote:
Martin schrieb:
The original example ( a bug on mantis) had little strangeness. A
global variable being modified in an OnChange handler of a TEdit.
This could very, very easily happen.
One of the reasons why *global variables* should be
On Fri, 8 Jul 2011, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 00:14, michael.vancann...@wisa.be wrote:
Given that Borland never decided to 'fix' it, I'm inclined to think that
they also don't consider it a real problem, but rather a corner case
(if they are aware of it at all).
Hm.
On 7/6/2011 8:00 AM, Felipe Monteiro de Carvalho wrote:
On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo
miklos.cse...@eok.sote.hu wrote:
fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the
missing package?
fp: error while loading shared libraries: libtinfo.so.5: cannot
On Fri, Jul 8, 2011 at 01:48, Martin f...@mfriebe.de wrote:
If you look at the point (2) of the mail you responded to,
you will see that I discuss this exact issue. Const string is passed by
value,
and it does not lead to any undefined behaviour and crashes
except this case (barring, of
On Fri, Jul 8, 2011 at 02:29, michael.vancann...@wisa.be wrote:
On Fri, 8 Jul 2011, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 00:14, michael.vancann...@wisa.be wrote:
Given that Borland never decided to 'fix' it, I'm inclined to think that
they also don't consider it a real problem,
On 07/07/2011 16:27, Alexander Klenin wrote:
1) That the code you posted would work quite correctly if const
string is fixed,
including all the optimizations you are suggesting in the rest of
your message.
No.
As I said: IF the result of constant expressions like s[a] = '' are
cached (in
On Fri, Jul 8, 2011 at 02:35, Martin f...@mfriebe.de wrote:
On 07/07/2011 16:27, Alexander Klenin wrote:
1) That the code you posted would work quite correctly if const
string is fixed,
including all the optimizations you are suggesting in the rest of
your message.
No.
As I said: IF
On 07/07/2011 16:54, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 02:35, Martinf...@mfriebe.de wrote:
On 07/07/2011 16:27, Alexander Klenin wrote:
1) That the code you posted would work quite correctly if const
string is fixed,
including all the optimizations you are suggesting in the
On 07/07/2011 16:54, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 02:35, Martinf...@mfriebe.de wrote:
On 07/07/2011 16:27, Alexander Klenin wrote:
1) That the code you posted would work quite correctly if const
string is fixed,
including all the optimizations you are suggesting in the
On Fri, Jul 8, 2011 at 03:23, Martin f...@mfriebe.de wrote:
Yes, I use pointers, but it does not matter how I managed to change the
content of s. All that matters is, that I broke the promise (assuming s
was declared const)
No, the whole point it is that it *does* matter.
Direct memory access
On Fri, Jul 8, 2011 at 03:35, Martin f...@mfriebe.de wrote:
On 07/07/2011 16:27, Alexander Klenin wrote:
1) That the code you posted would work quite correctly if const
string is fixed,
including all the optimizations you are suggesting in the rest of
your message.
A different point
Also note that, implemented properly, removal of incref/decref calls
should not depend on any const declarations, it can be performed even
for non-const strings.
I'am awaiting your patch.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Fri, Jul 8, 2011 at 03:49, Florian Klämpfl flor...@freepascal.org wrote:
Also note that, implemented properly, removal of incref/decref calls
should not depend on any const declarations, it can be performed even
for non-const strings.
I'am awaiting your patch.
So you agree with my
On 07/07/2011 17:36, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 03:23, Martinf...@mfriebe.de wrote:
Yes, I use pointers, but it does not matter how I managed to change the
content of s. All that matters is, that I broke the promise (assuming s
was declared const)
No, the whole point it
Am 07.07.2011 18:55, schrieb Alexander Klenin:
On Fri, Jul 8, 2011 at 03:49, Florian Klämpfl flor...@freepascal.org wrote:
Also note that, implemented properly, removal of incref/decref calls
should not depend on any const declarations, it can be performed even
for non-const strings.
I'am
On 07/07/2011 17:47, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 03:35, Martinf...@mfriebe.de wrote:
AFAIK, today all that const string does is remove the ref count.
So basically you say, because of your reasoning, no one should be able to
use such a feature in there code?
It should do
On Fri, Jul 8, 2011 at 03:55, Martin f...@mfriebe.de wrote:
That doesn't make much sense either. Now const means different things
depending on the type ?
It already does. I agree it makes no sense, but this is much larger problem,
which deserves at least a separate discussion thread.
Am 07.07.2011 19:00, schrieb Alexander Klenin:
On Fri, Jul 8, 2011 at 03:55, Martin f...@mfriebe.de wrote:
That doesn't make much sense either. Now const means different things
depending on the type ?
It already does. I agree it makes no sense, but this is much larger problem,
which
On Fri, Jul 8, 2011 at 03:57, Florian Klämpfl flor...@freepascal.org wrote:
I'am awaiting your patch.
So you agree with my design?
About detecting if value parameters need no incr/decr. ref? I didn't see
any design yet.
See http://bugs.freepascal.org/view.php?id=19605 and this thread
--
On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl flor...@freepascal.org wrote:
Am 07.07.2011 19:00, schrieb Alexander Klenin:
Currently, there are four meaninigs of const:
1) Const by value -- like Integer
2) Const by reference -- like shortstring
3) Const by reference, but not really const --
On 07/07/2011 18:09, Alexander Klenin wrote:
About detecting if value parameters need no incr/decr. ref? I didn't see
any design yet.
See http://bugs.freepascal.org/view.php?id=19605 and this thread
that is about at runtime, in debug compiled exe
We are talking about compile time decissions
On Fri, Jul 8, 2011 at 04:16, Martin f...@mfriebe.de wrote:
On 07/07/2011 18:09, Alexander Klenin wrote:
About detecting if value parameters need no incr/decr. ref? I didn't see
any design yet.
See http://bugs.freepascal.org/view.php?id=19605 and this thread
that is about at runtime, in
Am 07.07.2011 19:14, schrieb Alexander Klenin:
On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl flor...@freepascal.org wrote:
Am 07.07.2011 19:00, schrieb Alexander Klenin:
Currently, there are four meaninigs of const:
1) Const by value -- like Integer
2) Const by reference -- like shortstring
On Fri, Jul 8, 2011 at 03:58, Martin f...@mfriebe.de wrote:
On 07/07/2011 17:47, Alexander Klenin wrote:
Also note that, implemented properly, removal of incref/decref calls
should not depend on any const declarations, it can be performed even
for non-const strings.
Differnet feature. Nice
On Fri, Jul 8, 2011 at 04:22, Florian Klämpfl flor...@freepascal.org wrote:
Why? 2) is exactly the same? The const contract with the compiler is broken.
Since when are passing by value and by reference the same?
Besides this, people like Martin Schreiber won't be happy if a procedure
On Fri, Jul 8, 2011 at 04:52, Martin f...@mfriebe.de wrote:
if const reads: I (the programmer) tell the compiler this value is going to
be constant
versus: I ask the compiler to help me avoid changing it
But as in my other mail, it may not be best named (but now we are changing
topic, it's
On 07/07/2011 19:12, Alexander Klenin wrote:
Neither do I advocate to use const, unless you know what you do. And if
anyone advocates it, then it's a problem (but not a problem of the feature)
Just google const string parameter Delphi to see the advocating.
That's a different issue.
Am 07.07.2011 19:54, schrieb Alexander Klenin:
...
The problem with this particular feature is that *nobody* seems to use
it correctly --
if even compiler developers did not get it right, what can we expect
from ordinary
users?
Here I am. Probably the most ordinary FP user on the planet.
49 matches
Mail list logo
