AutoHotkey Community

It is currently May 27th, 2012, 9:58 am

All times are UTC [ DST ]




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 44 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject:
PostPosted: January 11th, 2007, 7:10 pm 
Offline
User avatar

Joined: December 26th, 2005, 4:40 pm
Posts: 8776
Laszlo wrote:
What do you mean? There is no error in the script.


Still :roll:

Why does this not shoot an error?

Code:
MsgBox %][%
lkldsal
asldllaslklasd
salasldlaslklsdaklasd
saldlsaklsdaklkaslkdlakldas


:shock:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 7:12 pm 
Offline

Joined: November 13th, 2004, 4:08 am
Posts: 2951
Location: Minnesota
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 7:55 pm 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
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 =).

_________________
GitHubScriptsIronAHK Contact by email not private message.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 8:05 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
Skan wrote:
Why does this not shoot an error?
Code:
MsgBox %][%
lkldsal
asldllaslklasd
salasldlaslklsdaklasd
saldlsaklsdaklkaslkdlakldas
:shock:
It does for me. Which AHK version accepts this script?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 8:21 pm 
Offline
User avatar

Joined: December 26th, 2005, 4:40 pm
Posts: 8776
Laszlo wrote:
It does for me. Which AHK version accepts this script?

Sorry! I double-clicked the wrong file. :oops:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 8:33 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 8:51 pm 
Offline

Joined: November 13th, 2004, 4:08 am
Posts: 2951
Location: Minnesota
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?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 11th, 2007, 10:30 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 12th, 2007, 1:01 am 
Offline

Joined: November 13th, 2004, 4:08 am
Posts: 2951
Location: Minnesota
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 19th, 2007, 7:24 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
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
*/


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 19th, 2007, 7:32 pm 
Offline

Joined: October 28th, 2006, 2:14 am
Posts: 297
Location: US
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 :D


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 19th, 2007, 8:49 pm 
Offline
User avatar

Joined: August 11th, 2004, 1:47 am
Posts: 5347
Location: UK
Laszlo I saw your wrapper for sprintf a while ago, can it convert integers to base 2?
btw thanks Elevator_Hazard :)

_________________
GitHubScriptsIronAHK Contact by email not private message.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 19th, 2007, 9:07 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
Unfortunately, there is no binary type supported in sprintf. You can have hex, decimal or octal only.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: June 19th, 2007, 9:53 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
I found another function in msvcrt.dll, which does the conversion to any base. The wrapper is here.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 44 posts ]  Go to page Previous  1, 2, 3

All times are UTC [ DST ]


Who is online

Users browsing this forum: sks, Yahoo [Bot] and 21 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group