AutoHotkey Community

Firstly and most importantly, _strrev modifies the string you pass it. If you run the same line of code again, you will get the opposite result even though you are passing a literal string:
Typically passing a literal string would be of no use anyway, so assume you always pass a variable:
While this works, there are still problems. Note that _strrev defines only a single parameter. Passing the additional unused parameter is harmless, but ultimately takes time. Now consider this performance note:
So,
There is (at least) one remaining inefficiency: _strrev actually returns the same pointer we gave it, so we are unnecessarily measuring and copying from var when we could be using it directly. I suppose the fastest we can make it while keeping it simple would be:
Note that since the parameter is always copied into the local Str variable and not passed directly to _sttrev, it is safe to do Flip("literal string").

We could cache a pointer to msvcrt\_strrev to improve performance by a set amount per call. For strings up to 10000 characters, the difference seems to be about 10%. The longer the string, the less significant the gain is, relatively speaking. Also note that as with most functions in msvcrt.dll (the Microsoft Visual C run-time), _strrev uses the C calling convention (CDecl).
As already demonstrated, it isn't faster. For every character in the string, it must move every character preceding it. This means that as the string gets longer, the function takes exponentially longer. There are a number of different ways to do it, but I think this is the simplest:
This should take an amount of time directly proportional to the length of the string. I tried several variations and other methods (such as NumGet with concat or NumPut/NumGet), but couldn't trust my benchmark results as I've noticed the order the functions are defined in seems to have an effect.

Generally if a script needs to loop to achieve its result, DllCall to an equivalent compiled function will outperform it.

So when "flipping" a string using these functions is there a call that would also flip any parenthesis/brackets/braces? Obviously you could run a RegEx loop to correct them but I was just curious.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

I could never guess this. I tried it just the way I would have done with CharUpperA()



I am aware ( from Laszlo's Bit Wizardry ) that ignoring CDecl would result in An errorlevel. Is it important here?



It would do good here to mention Laszlo's Machine code version of Flip().
I do not know if it is fast, but is the only solution that will work past nulls.

Thanks.

Incidentally, CharUpperA() also modifies its input.
DllCall has an undocumented "safety feature" which allows you to get away with it. OTOH, the documentation seems to imply "Cdecl" should always be used if the function uses the C calling convention. (It's only logical...)

Wow! I love AutoHotkey

IMO, this should be considered as a bug, comparing with

Why? You are modifying two separate literal strings.

Are you serious? Do we need a poll on how users are expecting it to behave?

This is really strange behavior. Is the literal string being buffered inside the loop and not buffered if there is no loop

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

No, it's not a matter of buffering. What it does is very similar to the example of my last post. The only difference is that it just skips the assignment/update (of my last example) in the second iteration.

So as far as i understand here assignment is not skept and all works right:

But here it is skept all the time?

And as far as I understand it does affect other DllCalls when working with a literal string in a loop as well, right?

Then it might be wise not to use a literal string in DllCall at all, just to be sure or even better to fix it?

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Sean,
What I meant to ask was why you would use the comparison of those two code samples as a basis for your statement that there is a bug. Either way the literal string is modified, you just don't see it if you don't execute the same line twice.

Seriously, the function is asking for a string to modify and you are passing it a literal string. As I see it (metaphorically speaking), you are asking a stupid question and should therefore expect a stupid answer.

Perhaps a more appropriate "answer" would be to recognize the string should not be modified and raise an (access violation) exception - as would be done in C, for example. The more I think about it, the more reasonable it seems. (For instance, DllCall would catch the exception and report the problem via ErrorLevel.) However, I think it would be much more trouble to implement than the added error-detection is worth. The only other solution I can think of is unconditionally copying the literal string on every call (rather than directly using the literal string), and freeing the copy after the function returns - it would allow the string to be modified without side-effects, but would negatively impact the performance of every other script which uses literal strings with DllCall.


HotKeyIt,
With the loop, there is one line of code, with one literal string. Each time the line executes, it refers to the same literal string (i.e. at the same address). After the first iteration, you've essentially modified the code itself:
You may consider it equivalent to this:

With two separate lines, each line refers to its own literal string (i.e. at two different addresses), like this:

In other words, for each (copy of a) literal string in your source code there will be exactly one (copy of the) string in memory after the script loads.
It is perfectly safe if you know the function will not modify the string, but unwise otherwise.

Yes, that's what I meant by the only difference.

Well, just to be precise, I didn't say it's a bug but should be considered as a bug. I could guess it was a design decision, likely for performance. What I really wanted to say was that the behaviors/end-results appeared inconsistent.

I understood AHK treated a literal string as sort of a constant string (however without protecting it). But there is no concept of the constant string in AHK, so the behavior/end-result will be confusing many users IMO.

Awesome, thanks for explanation Lexikos.

So as I understand now, this literal string is saved in an address on load of script and not on each DllCall.So, a literal string can be modified as well.
I assume when a variable is used in DllCall, it uses its address instead.

How would I know whether the DllCall modifies that literal string, is this documented somewhere at MSDN, i could not find it.

I think that behaviour should be documented in AutoHotkey Help.

While experimenting, i come to more confusion but I think I understand it now
As I understand here each DllCall uses separate buffer/address for its string.
When code is run first time, inner string is reversed and outer DllCall reverses it back but in a different buffer/address.
When it runs second time inner DllCall reverses string back so that is why output is different.


And finally, as I understand, here outer DllCall will alter the string by address as well, so no separate buffer will be used, right?

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Really? Then, can you guess the outcome of the following?

I suggest to not waste any more time to understand this. It's not in the realm of understanding, but implementation detail.