 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
SKAN
Joined: 26 Dec 2005
Posts: 5887
|
 Posted: Thu Jan 11, 2007 7:10 pm Post subject: |
 |
|
| Laszlo wrote: | | What do you mean? There is no error in the script. |
Still 
Why does this not shoot an error?
| Code: | MsgBox %][%
lkldsal
asldllaslklasd
salasldlaslklsdaklasd
saldlsaklsdaklkaslkdlakldas |
 |
|
| Back to top |
|
 |
jonny
Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota
|
| Posted: Thu Jan 11, 2007 7:12 pm Post subject: |
|
|
| AHK doesn't know you want it to treat those as part of the MsgBox line. Operators make implicit continuations, otherwise you have to use parens. |
|
| Back to top |
|
|
Titan
Joined: 11 Aug 2004
Posts: 5068
Location: imaginationland
|
| Posted: Thu Jan 11, 2007 7:55 pm Post subject: |
|
|
| Laszlo wrote: | | x+++x looks beautiful |
o_O
| Laszlo wrote: | | I consider relying on undocumented features of the language to be dangerous and bad style, you consider it OK. |
Chris wrote: "I think the current evaluation order is unlikely to change. If it ever does change by accident (e.g. due to some optimization), the current battery of tests will alert me so that the change can be undone or documented in the changelog." We also have archives (minor versions are also available) so it's not something to be over obsessive about. As for readability it's at the author's sole discretion to apply comments, lexical conformity, serialized arithmetic, et al. (and always should be)
| Skan wrote: | | Why does this not shoot an error? |
Perhaps a link will help... Splitting a Long Line into a Series of Shorter Ones: "A line that starts with "and", "or", ||, &&, a comma, or a period is automatically merged with the line directly above it (in v1.0.46+, the same is true for all other expression operators" (like =).
_________________
RegExReplace("irc.freenode.net/ahk", "^(?=(.(?=[\0-r\[]*((?<=\.).))))(?:[c-\x73]{2,8}(\S))+((2)|\b[^\2-]){2}\D++$", "$u3$1$3$4$2") |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Thu Jan 11, 2007 8:05 pm Post subject: |
|
|
| Skan wrote: | Why does this not shoot an error? | Code: | MsgBox %][%
lkldsal
asldllaslklasd
salasldlaslklsdaklasd
saldlsaklsdaklkaslkdlakldas |
|
It does for me. Which AHK version accepts this script? |
|
| Back to top |
|
|
SKAN
Joined: 26 Dec 2005
Posts: 5887
|
| Posted: Thu Jan 11, 2007 8:21 pm Post subject: |
|
|
| Laszlo wrote: | | It does for me. Which AHK version accepts this script? |
Sorry! I double-clicked the wrong file.  |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Thu Jan 11, 2007 8:33 pm Post subject: |
|
|
There could be good reasons to change how expression evaluation works. For example, && and || are treated differently than other operators. This short circuit stuff prohibits using side effects in Boolean expressions.
z := x & ++y ; no short circuit
z := x && ++y ; documented short circuit
Performance is not a good enough reason for this, because empty value propagation is also very common in scripts, so arithmetic short circuits would speed up scripts similarly. Now we have to remember that && is dangerous, & is safe for side effects (which don't rely on the evaluation order). It does not mean that evaluation will change, though. |
|
| Back to top |
|
|
jonny
Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota
|
| Posted: Thu Jan 11, 2007 8:51 pm Post subject: |
|
|
| Quote: | | For example, && and || are treated differently than other operators. This short circuit stuff prohibits using side effects in Boolean expressions. |
Purism alert! For the last time, this is almost never a problem. And where it is, it can be done differently. Creative examples don't count if they can easily be done with similar code that isn't problematic. And this case doesn't even seem to be a problem...
| Quote: | | z := x && ++y ; documented short circuit |
I've used this many times myself to conditionally increment a variable. How is it undesirable or unexpected behavior?
| Quote: | | Performance is not a good enough reason for this |
Yes it is. And so is the usefulness of it.
| Quote: | | empty value propagation is also very common in scripts, so arithmetic short circuits would speed up scripts similarly. |
I believe Chris has already mentioned that this would be non-trivial. Do any open-source interpreters implement this already? |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Thu Jan 11, 2007 10:30 pm Post subject: |
|
|
| jonny wrote: | | Purism alert! For the last time, this is almost never a problem. And where it is, it can be done differently... And this case doesn't even seem to be a problem... |
Nobody said "this" was a problem. It is an asymmetry, or inconstancy. Some like it, others don't. You say "it can be done differently". This is the point. We are speaking about different ways of evaluating different kinds of expressions. What AHK has is just one possibility, it can be done differently.
| jonny wrote: | | [z := x && ++y]I've used this many times myself to conditionally increment a variable. |
It is bad style, because it is hard to understand without digging into the documentation (finding short circuits), it behaves differently in other languages, it could change in the future being deviant from main stream languages, and it can be easily written cleanly.
| jonny wrote: | | Quote: | | Performance is not a good enough reason for this |
Yes it is. And so is the usefulness of it. |
"This" refers to the difference between the arithmetic and Boolean expression evaluation. I don't see, why performance dictates such differences (short circuits everywhere would improve performance). And what is the "usefulness" of such differences? If Chris has already mentioned that arithmetic short circuits would be non-trivial, it is just a practical reason, not performance or usefulness. |
|
| Back to top |
|
|
jonny
Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota
|
| Posted: Fri Jan 12, 2007 1:01 am Post subject: |
|
|
| Quote: | | it behaves differently in other languages, it could change in the future being deviant from main stream languages |
Zuh?
| Code: | //C++
#include <iostream>
using namespace std;
int main()
{
int x, y=0;
x = 0;
x && y++;
cout << y << endl; //Outputs '0'
x = 1;
x && y++;
cout << y << endl; //Outputs '1'
return EXIT_SUCCESS;
} |
| Quote: | | "This" refers to the difference between the arithmetic and Boolean expression evaluation. I don't see, why performance dictates such differences (short circuits everywhere would improve performance). And what is the "usefulness" of such differences? |
It seemed like you were arguing against short-circuiting. My mistake, I guess. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Tue Jun 19, 2007 7:24 pm Post subject: |
|
|
Let us return to the original topic: conversion between number representations in different bases.
In theory, the Windows (XP, NT) runtime library has the necessary functions to convert a number to its binary, octal, decimal and hex representation, and back. If they worked, we could avoid AHK loops, and hopefully speed up the conversions. But they suck. (In the most common cases they do work for unsigned numbers: binary: 1..31 bits, octal, hex: 1..32 bits, decimal: 1..64 bits, which is surprising, because the conversion function is called RtlInt64ToUnicodeString.)
Here is the code, if someone wants to experiment: | Code: | ; Setup a Unicode structure for 65 characters. Need to be done only once
VarSetCapacity(UnicodeBuffer,130,0)
VarSetCapacity(UnicodeStruct,8,0)
NumPut(130,UnicodeStruct,2,"UShort")
NumPut(&UnicodeBuffer,UnicodeStruct,4)
; Setup a counted ANSI string structure for 65 characters. Need to be done only once
VarSetCapacity(ANSIstring,66,0)
VarSetCapacity(ANSIstruct,8,0)
NumPut(66,ANSIstruct,2,"UShort")
NumPut(&ANSIstring,ANSIstruct,4)
num := 2**63, base := 10 ; = 2,8,10,16. Respective precision = 31,32,64,32 bits
DllCall("ntdll\RtlInt64ToUnicodeString", Int64,num, UInt,10, UInt,&UnicodeStruct) ; UNSIGNED num
DllCall("ntdll\RtlUnicodeStringToAnsiString", UInt,&ANSIstruct, UInt,&UnicodeStruct, UInt,0)
VarSetCapacity(ANSIstring,-1) ; fix length
MsgBox % "[" ANSIstring "]`nLength = " StrLen(ANSIstring)
/* http://msdn2.microsoft.com/en-us/library/ms804299.aspx
NTSTATUS RtlInt64ToUnicodeString(
IN ULONGLONG Value,
IN ULONG Base OPTIONAL, // 2 Binary, 8 Octal, 10 Decimal, 16 Hexadecimal
IN OUT PUNICODE_STRING String);
String
typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer; } UNICODE_STRING
ULONG RtlUnicodeStringToAnsiSize(PUNICODE_STRING UnicodeString); #bytes for NULL-terminated ANSI string =~ UnicodeString
NTSTATUS RtlUnicodeStringToAnsiString(
IN OUT PANSI_STRING DestinationString, Pointer to an ANSI_STRING structure to hold the converted ANSI string
IN PUNICODE_STRING SourceString, Pointer to the Unicode source string to be converted to ANSI
IN BOOLEAN AllocateDestinationString); Use 0
typedef struct _STRING {
USHORT Length;
USHORT MaximumLength;
PCHAR Buffer; } ANSI_STRING
*/ |
|
|
| Back to top |
|
|
Elevator_Hazard
Joined: 28 Oct 2006
Posts: 304
Location: US
|
| Posted: Tue Jun 19, 2007 7:32 pm Post subject: |
|
|
| Veovis wrote: | | One of the weakest areas of my coding is that my code is very un-optimized and usualy a lot longer and more complex than it needs to be. From studying examples like this and stuff that people like Laszlo write helps me to learn about how to optimize things. |
Same here! I've improved a little... And this script is nice, I'll use it more and more.
_________________
Changed siggy at request of ahklerner  |
|
| Back to top |
|
|
Titan
Joined: 11 Aug 2004
Posts: 5068
Location: imaginationland
|
| Posted: Tue Jun 19, 2007 8:49 pm Post subject: |
|
|
Laszlo I saw your wrapper for sprintf a while ago, can it convert integers to base 2?
btw thanks Elevator_Hazard 
_________________
RegExReplace("irc.freenode.net/ahk", "^(?=(.(?=[\0-r\[]*((?<=\.).))))(?:[c-\x73]{2,8}(\S))+((2)|\b[^\2-]){2}\D++$", "$u3$1$3$4$2") |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Tue Jun 19, 2007 9:07 pm Post subject: |
|
|
| Unfortunately, there is no binary type supported in sprintf. You can have hex, decimal or octal only. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4016
Location: Pittsburgh
|
| Posted: Tue Jun 19, 2007 9:53 pm Post subject: |
|
|
| I found another function in msvcrt.dll, which does the conversion to any base. The wrapper is here. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
