Wonder if the compilers clever enough to optimise that
Sure … but it’s calling overhead that would be absent in a language construct, it’s syntactically nonstandard and less elegant, and probably misses some compiler optimization opportunities.
1 Like
There are many optimizations LLVM can do that cant be used with Xojo code for various reasons
Unfortunately
I’m not sure if inlining is enabled
1 Like
Pascal, uses this exact approach, but shorter, as inc() and dec(), as an alternative for ++x and --x.
The difference is that it is a standard inline function, part of the language, and not a callable function, works much like a macro, it means it can solve the increment/decrement super fast, with minimal assembly codes in place without any call, just like ++x and --x does. That’s not the same as an user defining and using a slow function needing setting parameters, doing a call and returning.
1 Like
I have a question Rick. You really mean that I++ than inc()??? Interesting thesis. But stupidly that has to do how it is implemented on compiler surface and not on grammar of the language or what ever. The increasing and decreasing is even not implemented as an on top functionality looking in the C++ source code or even in Java. So I can’t see why inc() or dec() could be faster of better. So I wanna know what you mean with the description. Thanks in advance for helping me out.
I simply can’t understand what you said. And I hope that people understand what I said.
If you get a copy of the Object Pascal Handbook, at page 63 you will find this (read the note. I hope it is enough to you understand what I said):
Better, I wrote a sample, and can show the assembly output pointing out the difference of an user code inc(), and the native one, in assembly. Red is the user code; yellow is the native function.
1 Like
Nice try but you are not writing about the implementation for it Wirth was doing. You are writing about Freepascal. Another animal and not comparable. But okay, let’s say under this conditions you are right while there is no possible way to show in short time and I haven’t enough to do that now. TKS.
And by the way: the Lazarus / Freepascal implementation is following the Ideas of the old Borland implementation. Wasn’t so like it should be.
There’s no reason any compiler couldn’t implement inc/dec, incr/decr such that it yields that exact same machine code that ++i, --i generates in any C++ compiler
That freepascal did is evidence of that
Many languages wont have the exact same semantics as C++(esp not the post inc, post dec operators) and few have the same expression evaluation behaviour that C++ does where the inc/dec has a “value”
But thats going to be language dependent
It isnt useful in Pascal, or many other languages
But in C and its derivatives it is - or can be
An expression like
if ( ++I ) { ........}
mains uncommon in C and its relatives, in C any non-zero result is “true”
In pascal
if inc(i) .......
makes NO sense since inc(i) ISNT a boolean expression which pascal requires
just different semantics of the overall language
I was looking in the Sources and the theory behind which Mr. Wirth wrote the one invented Pascal and its compiler. Has nothing to do with the rest. In both cases it is implemented in a total different way than in Freepascal or Delphi. Never mind.
All I said was
How Wirth implemented it doesnt invalidate what I said
He chose to do it one way. Great !
Others might do in other ways (like free pascal) Great !
As long as the implementation passes tests for compliance then its all good
No ?
FWIW my reply wasnt specifically to you
1 Like
The discussion was about application speed. Therefore the implementation is extremely important. Okay, what we are peaking about…man. Right. For me it makes no sense to discuss it is only about the mathematical implementation and the speed of this app: not from interest.
Thorsten, every current implementation I know does what I showed. Inc(i) spits optimized inline code equivalent to what ++i does in C. What Wirth did 50 years ago using a CDC mainframe as his development platform is useless for the current standards. At the end, he just defined the language, the “how to” is on the hands of the implementer, and currently we do what I showed. For FreePascal, for Object Pascal, for any Pascal I can remember since Turbo Pascal in the 80’s. If I do recall, at the time of Wirth, his Pascal “compiler” was just a translator of the language in a series o P-Codes, like BASIC did too. At the end they needed a runtime to interpret and run that code. I had colleague in the 80’s that wrote his own Pascal P-Code compiler and interpreter, I guess as a pet project for fun, because we didn’t need one, we had Turbo Pascal in our company. We wrote industrial software for a industrial computer the company we worked for built. I wrote much of that OS, except the kernel, that was already done when I was invited to the project.
1 Like
ISO Pascal sadly does not have a kind of construct to allow that, inc() is not a function, does not return a value. There’s another one called succ(i) to return the successor value (i+1), also inlined and optimal fast, but it is immutable, does not affect “i”. If you wanted that, you should create your own inc() function with another name.
It’s the same with every Wirth programming languages like Modula2, I think. Pascal is probably one of the easiest programming languages to parse and write toy compiler.
1 Like
I like how Purebasic does it… if you just have “x+1” on a line, it adds 1 to x. Same with all the basic math operators. And, of course, you can change 1 to any math expression.
Works with strings as well.
c$=“boo”
c$+“hoo”
c$ is now “boohoo”
Not the safest construct. The lack of an explicit attribution pass me the impression that it opens a portal for bugs being invited in.
Currently some languages uses a similar construct to “return” a value at the end of a function/lambda, but don’t change variables not explicitly attributed in the expression, Ruby for instance.
The implementation could be identical to what C/C++/ etc do
It doesnt have to be that implementation
It could be something else
But at this point we’re splitting hairs
I know
Its why I wrote what I wrote which said it wont work
And I’m ok with that
There are certain idioms in C/C++ that I truly dislike
if (++i ) {
}
is one
But I suppose if you wrote nothing but C++ for years you’d get used to it and expect it
1 Like
oh how I dislike the $ notation 
1 Like
No need of a “nothing but”, just using such idioms a bit for few months make them natural, and I really feel a kind of pain of not having them in Xojo. And yes, we can write concise cryptic and fast instructions mixing them + bitwise operations + ternary operations in a for( ; ; ) that demands a good comment or you will take 1 minute understand it after 6 months, but for most things it just looks clear and easy.