On Mon, Jul 11, 2011 at 15:35, Hans-Peter Diettrich
wrote:
> Alexander Klenin schrieb:
>>> To which data type do you want apply your "constval" modifier, with which
>>> concrete effects?
>>
>> To any datatype, of course. The result should be:
>> 1) Parameter is passed by value
>
> How to pass obje
On 11 Jul 2011, at 02:08, Chad Berchek wrote:
> Even if the calling convention does not change, the semantics can, as
> currently implemented. Even within a single platform const is ill-defined.
> Consider the case of AnsiString. There are three cases as it is currently
> implemented:
>
> 1)
Max Vlasov schrieb:
On Mon, Jul 11, 2011 at 4:45 AM, Chad Berchek wrote:
1. It seems that if a string is a (non-const) local variable it should be
safe. I base this on the following reasoning:
looks like it's not:
procedure TForm1.Button1Click(Sender: TObject);
var
S: string;
procedure
Chad Berchek schrieb:
Some might say that it doesn't matter whether it is passed by value or
reference: if you pass it as const, either way you promise not to modify
it. See, that is my concern: what is IT? People have used other words,
but it ultimately comes down to: if you say the programmer
Chad Berchek schrieb:
I just want to clarify: I am trying to be very careful to distinguish
between implementation and semantics.
"Implementation" is a very precise definition, which can be used to
perfectly describe the semantics of a language. A verbose description of
the semantics leaves
Alexander Klenin schrieb:
On Mon, Jul 11, 2011 at 04:09, Hans-Peter Diettrich
wrote:
If you want to introduce different keywords, then please different for
beforementioned cases. E.g.
constval x: integer; //all value-types
constref r: Trecord; //also ShortString
const??? o: TObject; //all refer
Daniël Mantione schrieb:
Within a certain calling convention, the behaviour of const is defined
and will not change. I.e. an int64 may be passed by value in one calling
convention and by ref in another, but once the calling convention is
fixed, future compatibily is maintained; your assembler
On Mon, Jul 11, 2011 at 4:45 AM, Chad Berchek wrote:
>
> 1. It seems that if a string is a (non-const) local variable it should be
> safe. I base this on the following reasoning:
>
looks like it's not:
procedure TForm1.Button1Click(Sender: TObject);
var
S: string;
procedure SideEffectCall;
Sorry for the additional post; I should have added this to my preceding
message.
I just want to clarify: I am trying to be very careful to distinguish
between implementation and semantics.
If my understanding is correct, AnsiString implementation is always
pass-by-reference.
The problem is
On 7/10/2011 2:40 PM, Daniël Mantione wrote:
However, for a new calling convention (on an existing or a new
platform) it's completely up to the compiler designer what will be
passed as const and what will be passed as reference.
Agreed. That's why I say you can't really make assumptions: if you
On 11 Jul 2011, at 00:03, Daniël Mantione wrote:
> Calling conventions should in principle be eternally frozen. This includes
> const, because for exampe a DLL compiled in version x can be imported by a
> program compiled by version y.
That's indeed a good point.
> The fact that it has happen
Op Sun, 10 Jul 2011, schreef Jonas Maebe:
On 10 Jul 2011, at 21:40, Daniël Mantione wrote:
Op Sun, 10 Jul 2011, schreef Chad Berchek:
I think we really cannot assume anything about what exactly will happen with
regard to the calling convention, which is what I was worried about earlier.
On 10 Jul 2011, at 21:40, Daniël Mantione wrote:
> Op Sun, 10 Jul 2011, schreef Chad Berchek:
>
>> I think we really cannot assume anything about what exactly will happen with
>> regard to the calling convention, which is what I was worried about earlier.
>
> Within a certain calling conventio
Op Sun, 10 Jul 2011, schreef Chad Berchek:
I think we really cannot assume anything about what exactly will happen
with regard to the calling convention, which is what I was worried about
earlier.
Within a certain calling convention, the behaviour of const is defined and
will not change. I
Some thoughts on the meaning of const, constref, and "constval", and how
they can usefully be applied:
My initial understanding of const was hazy. I have come to appreciate
that it is defined, but only in a very loose way. Instead of undefined I
should say ill-defined. I'm not entirely sure what
On Mon, Jul 11, 2011 at 04:09, Hans-Peter Diettrich
wrote:
>>> If you want to introduce different keywords, then please different for
>>> beforementioned cases. E.g.
>>> constval x: integer; //all value-types
>>> constref r: Trecord; //also ShortString
>>> const??? o: TObject; //all references, ex
Alexander Klenin schrieb:
3) Current documentation
(http://www.freepascal.org/docs-html/ref/refsu58.html)
declares that "const" modifier is "retaining the semantics of
passing by value",
so there is definitely a bug here -- you can declare it to be bug in
specification, but still.
Sorry, I can
On 10/07/2011 11:33, Marco van de Voort wrote:
To be honest, I'm a bit surprised by the progression of this discussion. I
sympathise a bit with the proponents of a simple "disable this optimization"
switch, but to me the rest all sounds like people desperately defending
their turf, and losing si
On 10/07/2011 05:34, Alexander Klenin wrote:
As for the whole "optimization hint" angle, I'd like to note that:
1) This is contrary to previous posts in this same thread, where
FPC developers insisted that "const" semantics is defined as
"no refcounting", which is quite different from a hi
On Sun, Jul 10, 2011 at 12:01 PM, Alexander Klenin wrote:
> On Sun, Jul 10, 2011 at 18:53, Hans-Peter Diettrich
> wrote:
>> When the meaning of "const"/"constref" is documented as kind of a *calling
>> convention*, that allows the compiler to optimize the code, no more
>> discussion is required.
In our previous episode, Alexander Klenin said:
> 2) If "const" is indeed an optimization hint, that places it in the
> same category as,
> say, "inline". What would you say if adding "inline" keyword to a procedure
> converted working program into randomly crashing one? I'd say this
> is optim
On Sun, Jul 10, 2011 at 18:53, Hans-Peter Diettrich
wrote:
> Alexander Klenin schrieb:
>> 1) This is contrary to previous posts in this same thread, where
>> FPC developers insisted that "const" semantics is defined as
>> "no refcounting", which is quite different from a hint.
> Refcounting is o
Alexander Klenin schrieb:
Martin, I do not know why you and Hans suddently have an urge to insult Chad,
but he really did not deserve this.
Perhaps a threshold was reached, when the same wrong argumentation was
refrained too often.
As for the whole "optimization hint" angle, I'd like to n
On Sun, Jul 10, 2011 at 04:45, Martin wrote:
> On 09/07/2011 17:12, Chad Berchek wrote:
>>
>> Wow, thanks for the insults guys. I didn't realize I was so stupid.
>>
>> You missed my point too, BTW. According to the link given:
>>
>> "A constant argument is passed by reference if its size is larger
On Sat, Jul 9, 2011 at 6:55 PM, Hans-Peter Diettrich
wrote:
> Flávio Etrusco schrieb:
>
>> Isn't this unfortunately encumbered by patents?
>> http://wiki.winehq.org/CompilerExceptionSupport
>>
>> http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent
>
> Softwa
Flávio Etrusco schrieb:
Isn't this unfortunately encumbered by patents?
http://wiki.winehq.org/CompilerExceptionSupport
http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent
Software patents should not be a problem outside the USA. A nice try,
but unimpor
Op Sat, 9 Jul 2011, schreef Flávio Etrusco:
Isn't this unfortunately encumbered by patents?
http://wiki.winehq.org/CompilerExceptionSupport
http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent
That is a problem. However:
* It's a US patent, so irrelevan
On 09/07/2011 17:12, Chad Berchek wrote:
Wow, thanks for the insults guys. I didn't realize I was so stupid.
You missed my point too, BTW. According to the link given:
"A constant argument is passed by reference if its size is larger than
a pointer."
So you always know what the size of a poi
On Fri, Jul 8, 2011 at 7:05 AM, Jonas Maebe wrote:
(...)
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for "try",
> but low overhead when an exception actually occurs (of course, since
> exceptions are suppose
On Sat, Jul 9, 2011 at 18:12, Chad Berchek wrote:
> Wow, thanks for the insults guys. I didn't realize I was so stupid.
>
> You missed my point too, BTW. According to the link given:
>
> "A constant argument is passed by reference if its size is larger than a
> pointer."
>
> So you always know wha
Chad Berchek schrieb:
Wow, thanks for the insults guys. I didn't realize I was so stupid.
Waking up? ;-)
You missed my point too, BTW. According to the link given:
"A constant argument is passed by reference if its size is larger than a
pointer."
People like you should not read such deta
On 09 Jul 2011, at 18:41, Jonas Maebe wrote:
> That part of the manual is wrong. What const does is by design completely
> implementation-dependent (except for cdecl/cppdecl routines, where it behaves
> the same as in C/C++, and for mwpascal routines, where it behaves the same as
> in MetroWer
On 09 Jul 2011, at 03:29, Martin wrote:
> We do know:
> http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4
>> A constant argument is passed by reference if its size is larger than a
>> pointer. It is passed by value if the size is equal or is less then the size
>> of a nativ
Wow, thanks for the insults guys. I didn't realize I was so stupid.
You missed my point too, BTW. According to the link given:
"A constant argument is passed by reference if its size is larger than a
pointer."
So you always know what the size of a pointer is? If I have this record:
TMyRec =
On Sat, Jul 9, 2011 at 12:40 PM, Thaddy wrote:
> Isn't it time to cut this discussion short? const means do not modify! full
> stop! whatever by reference or value. The rest is bovine extrement.
Not so fast.
As Hans-Peter Diettrich said: "Pascal "const" parameters are
optimization hints in the fi
On 9-7-2011 3:29, Martin wrote:
On 09/07/2011 02:14, Chad Berchek wrote:
Specifically, the way const is now "defined" (or not...) is
disturbing because it leaves out important details. In C++, you can
pass by value or reference, or by pointer which is a value but is
used to make references. Bu
On Sat, Jul 9, 2011 at 4:13 AM, Martin wrote:
> On 09/07/2011 00:59, Max Vlasov wrote:
>>
>> On Sat, Jul 9, 2011 at 3:14 AM, Martin wrote:
>>>
>>> function CRCConstString(constref Str: string): integer;
>>> does what you describ
>>
>> Hmm, it's interesting.. Some observations:
>> - constref is im
Chad Berchek schrieb:
All the problems we've seen with const used in various contexts with
different data types--AnsiString, ShortString, records, etc.--are the
result of one fundamental problem, which is the language design. Const
is not clearly defined. All problems mentioned stem from this.
On 09/07/2011 02:14, Chad Berchek wrote:
Specifically, the way const is now "defined" (or not...) is disturbing
because it leaves out important details. In C++, you can pass by value
or reference, or by pointer which is a value but is used to make
references. But what's important is you _always
Martin wrote:
- See difference to normal "const" is " that it must be passed by
reference."
I had not read about it before, but I think constref is a huge step in
the right direction. It eliminates my fundamental grief with the current
implementation.
Specifically, the way const is now "def
On 09/07/2011 00:59, Max Vlasov wrote:
On Sat, Jul 9, 2011 at 3:14 AM, Martin wrote:
function CRCConstString(constref Str: string): integer;
does what you describ
Hmm, it's interesting.. Some observations:
- constref is implemented in 2.5.1, right? Unfortunately I can not
test it right now in
On Sat, Jul 9, 2011 at 3:14 AM, Martin wrote:
> On 09/07/2011 00:09, Max Vlasov wrote:
>>
>> The answer is indirect referencing. it's a workaround that probably
>> will solve the problem, but I must admit that I don't know what is the
>> exact performance price. The compiler when it detects const
On 09/07/2011 00:09, Max Vlasov wrote:
The answer is indirect referencing. it's a workaround that probably
will solve the problem, but I must admit that I don't know what is the
exact performance price. The compiler when it detects const s:
ansistring could switch to passing not the actual addres
On Fri, Jul 8, 2011 at 2:05 PM, Jonas Maebe wrote:
> The main proposals I've seen were
> a) treat const string parameters the same as value parameters (i.e., get rid
> of the current const behaviour)
> b) the same as a), combined with a very conservative heuristic to apply the
> optimization in ca
On Friday 08 July 2011 12:05:02 Jonas Maebe wrote:
> The main problem here is that FPC's exception handling is based on
> setjump/longjump. This technique has a relatively high overhead for
> "try", but low overhead when an exception actually occurs (of course,
> since exceptions are supposed
Martin schrieb:
c) keep the current behaviour, but add functionality to the compiler
to help debug problems that can occur as a result of problems that can
occur as a result of this behaviour
Concrete: add means to ignore "const" with managed types.
Further debugging aids as far as feasable.
On Thursday 07 July 2011 19:22:27 Florian Klämpfl wrote:
>
> Why? 2) is exactly the same? The const contract with the compiler is
> broken.
>
> Besides this, people like Martin Schreiber won't be happy if a procedure
> suddently eats hundreds of extra clock cycles for nothing.
>
Here you are very t
Am 08.07.2011 12:05, schrieb Jonas Maebe:
However, looking at the generated assembly, I can't believe there
isn't a more efficient way to handle the implicit try-finally. It
feels to me like that is where the problem is. There is a lot of code
and several function calls that go into implementing
On 08/07/2011 11:05, Jonas Maebe wrote:
On 08 Jul 2011, at 05:51, Chad Berchek wrote:
I'm more interested now in a solution. The solutions I've seen so far
have potential, but in my opinion most of them seem like they are
more complex, would be more overhead, and produce worse performance
than
On 08 Jul 2011, at 05:51, Chad Berchek wrote:
The problem comes down to the specs though, or rather the lack
thereof. As I have searched the web and read some docs at
Embarcadero, things have only become more ambiguous. It seems that
everyone repeats the same basic explanations but never f
Op Thu, 7 Jul 2011, schreef Chad Berchek:
The problem comes down to the specs though, or rather the lack thereof. As I
have searched the web and read some docs at Embarcadero, things have only
become more ambiguous.
You are looking in the wrong places. Both Turbo Pascal and Delphi came
wit
I have just written up some very compelling arguments and then decided
to scrap it.
I maintain that const strings, dynamic arrays, and interfaces, as
currently implemented, are dangerous and should be considered useless in
all but the most limited circumstances. The behavior is dependent upon
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 plane
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.
On Fri, Jul 8, 2011 at 04:52, Martin 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 not about the
On Fri, Jul 8, 2011 at 04:39, Martin wrote:
> I do believe the feature itself is a valid feature (the ability for the
> programmer to tell the compiler to skip something like ref counts)
> There is a similar feature (via compiler switch) to skip implicit exception
> frames. (With the risk of mem l
On 07/07/2011 18:29, Alexander Klenin wrote:
But no compiler can identify every occurrence where the ref count can be
ommitted.
so it still stands:
What you want, is the removal of a feature from pascal. The feature for the
programmer to explicitly skip the ref count (at the programmers own ri
On 07/07/2011 18:14, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl 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 referenc
On Fri, Jul 8, 2011 at 04:22, Florian Klämpfl 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
> suddently eats hundreds of
On Fri, Jul 8, 2011 at 03:58, Martin 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 to have
Am 07.07.2011 19:14, schrieb Alexander Klenin:
> On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl 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)
On Fri, Jul 8, 2011 at 04:16, Martin 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 de
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:06, Florian Klämpfl 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" -- like ob
On Fri, Jul 8, 2011 at 03:57, Florian Klämpfl 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
--
Alexander
Am 07.07.2011 19:00, schrieb Alexander Klenin:
> On Fri, Jul 8, 2011 at 03:55, Martin 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 lea
On Fri, Jul 8, 2011 at 03:55, Martin 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.
Currently, there are fo
On 07/07/2011 17:47, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 03:35, Martin 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 what is semantical
Am 07.07.2011 18:55, schrieb Alexander Klenin:
> On Fri, Jul 8, 2011 at 03:49, Florian Klämpfl 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 awaitin
On 07/07/2011 17:36, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 03:23, Martin 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 *do
On Fri, Jul 8, 2011 at 03:49, Florian Klämpfl 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 design?
--
Alexan
> 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:35, Martin 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 diffe
On Fri, Jul 8, 2011 at 03:23, Martin 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 lets you
On 07/07/2011 16:54, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 02:35, Martin 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 mes
On 07/07/2011 16:54, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 02:35, Martin 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 mes
On Fri, Jul 8, 2011 at 02:35, Martin 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 t
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
On Fri, Jul 8, 2011 at 02:29, wrote:
>
>
> On Fri, 8 Jul 2011, Alexander Klenin wrote:
>
>> On Fri, Jul 8, 2011 at 00:14, 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
On Fri, Jul 8, 2011 at 01:48, Martin 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 course, a
On Fri, 8 Jul 2011, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 00:14, 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 De
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 avoide
On 07/07/2011 15:04, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 23:09, Martin 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 obviou
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 Fri, Jul 8, 2011 at 00:14, 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 since at least D2007.
--
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
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
On Thu, Jul 7, 2011 at 23:09, Martin 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 promise, no
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 brea
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 ha
> 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 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 program
On Thu, 7 Jul 2011, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 22:10, 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
respondin
On Thu, Jul 7, 2011 at 22:10, 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 the thread)
really thi
On Thu, 7 Jul 2011, Mattias Gaertner wrote:
Martin 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
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
Martin 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 logic), th
On 07/07/2011 07:51, Alexander Klenin wrote:
On Thu, Jul 7, 2011 at 17:45, Florian Klaempfl 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 implici
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 did
On Thu, 07 Jul 2011 00:15:54 -0500
Chad Berchek 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 whereby the pro
1 - 100 of 135 matches
Mail list logo
