AFAIK Inc() and Dec() are built in functions that where, at the time of Turbo Pascal, a faster way to inc/dec ordinals. Now the compiler is smart enough to optimise things anyway.
AFAIK Inc() and Dec() are built in functions that where, at the time of Turbo Pascal, a faster way to inc/dec ordinals. Now the compiler is smart enough to optimise things anyway.
would it be nice to allow them now to Inc/Dec properties ?
Inc(Button1.Tag) will be a shortcut for Button1.Tag := Button1.Tag + 1
would it be nice to allow them now to Inc/Dec properties ?
Inc(Button1.Tag) will be a shortcut for Button1.Tag := Button1.Tag + 1
AFAIK, Inc and Dec have been slower than a simole increment for some time now.
ReplyDelete"would it be nice to allow them now to Inc/Dec properties ?"
ReplyDeleteI'd go further and add the unary operators for increment and decrement:
Button1.Tag++;
or
++Button1.Tag;
I see no reason for sticking to Inc/Dec, might be missing something...
just because Inc/Dec have been Pascal keywords for decades, and ++ / -- have C like flavor
ReplyDeletemight be a valid reason for others, for me, I see C-like languages more productive; we can't stick to the "old ways" when we have better alternatives
ReplyDeleteDorin Duminica
ReplyDeleteI would prefer: Button.Tag += 1, as already implemented in FreePascal.
It's more pascalish. ++ is too symbolic too me.
Well Dorin, why do you use Delphi then ? At least you can use C++Builder ?!
ReplyDeleteMarkus Ja that can work too, it's a bit more clearer, but it's all syntax, nothing special, people can get used to it
ReplyDeletePaul TOTH I haven't touched Delphi in probably half a year by now...
but that's another question, anyway "+=" could be not so weird beside ":=" :)
ReplyDeleteand Inc/Dec could be also function like in
While Inc(Index) < 100 do
Andrea Raimondi Where does it come from? Agner Foq writes that it may occur only in some cases related to reading the carry flag, which is AFAIK never done by the Delphi compiler. See "16.2 INC and DEC" in http://www.agner.org/optimize/optimizing_assembly.pdf
ReplyDeletePaul TOTH inc/dec as a function could indeed make sense. But code may be more difficult to debug in some cases. You can already do this using an inlined function - I've seen this in the Delphi RTL.
ReplyDeleteA. Bouchez it is something at the back of my mind. I think it was a senior developer at a company I worked at who said this. I never made tests on this though because I do not have many cases of increments :-)
ReplyDeleteAndrea Raimondi The compiler should produce the same code for inc(x) and x := x + 1. Do you have evidence that this is no the case?
ReplyDeleteDavid Heffernan a long time ago there was a debate about this and I am talking about 20 years ago. I recall that Inc and Dec produced a larger code which executed a bit faster, whereas a simple increment was generating a smaller, but slower, code. I haven't looked into this for a long time, but chances are that references to that debate are still available on the net. When this debate happened, it was a different computing era, so the size of the code mattered just about as much as its speed. This is why I remember it :) I don't know what happened ever since because, as I said, this is not something I use a lot (really, almost not at all).
ReplyDeleteA
grabs popcorn I see a "is this syntax pascal'ish enough..." discussion on the horizon.
ReplyDeleteDorin Duminica will new language feature bring you back to Delphi anyway ?
ReplyDeletePaul TOTH one developer, or one developer's thoughts are pretty much a drop in the ocean OR irrelevant;
ReplyDeleteyou asked
"would it be nice to allow them now to Inc/Dec properties ?"
I commented
"I'd go further and add the unary operators for increment and decrement:
Button1.Tag++;
or
++Button1.Tag;
"
did you just get an AV and wanna drop it on me? (;
Button1.Tag.Inc;
ReplyDelete+Andrea It's not really helpful to spread FUD like this. Get some facts to back up what you say, or say nothing.
ReplyDelete+Lars Yuk!
ReplyDeleteLars Fosdal Nice. So you increase the value you retrieved by the property. Hello value types.
ReplyDeleteCompiler magic is magic.
ReplyDeleteAnd ambiguity is ambiguous.
ReplyDeletePutting a method on a result of a property does not imply anyhow that it means increasing the value of the property.
IMO, it's just another helper-like syntax.
ReplyDeleteObject.Prop.Action;
Object.List.Clear;
Object.Value.Increment;
Object.Value.Trunc;
but I do see the ambiguity.
The cleanest is probably
Inc(Object.Value);
Efficiencywise, such a construct doesn't really improve anything, as you still need to call getter and setter.
Andrea Raimondi " I recall that Inc and Dec produced a larger code which executed a bit faster, whereas a simple increment was generating a smaller, but slower, code." This is incorrect, even in Pentium 4 times, I'm afraid. In x86 asm, INC/DEC is smaller in code size than ADD/SUB, and "may" be a little slower, about pipelined execution, if the carry flag is checked just after the opcode. It is in all cases, always executed in one CPU cycle, and would always be pipelined in the asm generated by the Delphi compiler. The Agner Fox resources I linked are a good entry point, when you want to know more about asm level.
ReplyDeleteLars Fosdal "Efficiencywise, such a construct doesn't really improve anything, as you still need to call getter and setter."
ReplyDeleteIf there is a getter it should be called with the increased value! If the property is read-only you must not increase the value. It is simple as that: no matter what syntax - it is only sugar.
If it is read only, it shouldn't compile, just like for constants.
ReplyDeleteconst
MyConst = Integer(1);
begin
Inc(MyConst);
[dcc32 Error]: E2064 Left side cannot be assigned to
Calling the getter with the increased value, would make Inc behave differently from prop := prop + 1;
Lars Fosdal "Calling the getter with the increased value, would make Inc behave differently from prop := prop + 1;"
ReplyDeleteEh, huh, what? Read the first post again.
Ditto?
ReplyDeleteInc must do a SetValue(GetValue + 1);
Lars Fosdal And what does x.Value := x.Value + 1 do?
ReplyDeleteWhat I wrote. Perhaps I misinterpreted your statement "If there is a getter it should be called with the increased value!" as if the field value should be set, bypassing the getter, and the getter then called.
ReplyDeleteLars Fosdal "Perhaps I misinterpreted your statement" Indeed you did. I was commenting on your proposal to make it look like a method call and its ambiguity and potential confusion. We already have that problem with properties returning records that have methods. People call the method and then wonder why the internal state change is not present in the backing field (because it was done on the copy that was returned by the getter).
ReplyDeleteAdding mutating methods to built in simple types like integer would be a terrible thing to do.
ReplyDeleteDorin Duminica 'I see C-like languages more productive' - er, so x++ is 'more productive' than Inc(x). Riiiiiight...
ReplyDeleteChris Rolliston the unary inc/dec alone not so much, the overall short-hand calls, yes
ReplyDelete+Dorin I don't think ++ or += make C, C++, C#, Objective-C or Java more productive than Delphi. Presence or otherwise has no real bearing on productivity. Personally I'd like to see += and friends. Pre and post increment I'm less keen on. They lead to horrible UB/sequence point issues in C and C++. Even though there's no UB with these ops in C# the code becomes unreadable quite rapidly.
ReplyDeleteDavid Heffernan probably not, but it certainly feels like it to me; with respect to pre and post inc/decrement, I've seen fantastic delphi code in both new and legacy apps, it all has to do with how the developer choses to use the language features...
ReplyDeleteDavid Heffernan
ReplyDeleteRemind me please, what's UB, it doesn't ring a bell.
Undefined behavior
ReplyDelete+Johan there are daily questions on SO asking why x++ + ++x++ gives one value or another. And the answer is that the standard allows such code but does not define what the behaviour is. Anything is permitted to happen.
ReplyDeleteSimilar to this in Delphi would be the order of evaluation of function arguments. You must not write code that depends on that order because it is not specified.
if possible, i;d better like xxx.inc() than x++.
ReplyDelete