Variables & Arrays

[pixelsearch]

Hello,

I'm a newbie to AutoIt and there is a sentence I dont understand the meaning in the Help File, in the "Dim / Global / Local / Const" part. The sentence is : "Declaring a variable with a simple value in the same scope will not change the value in the variable"
Could anyone be kind enough to share a short example ?

Thanks in advance

PS: maybe I should indicate its preceding sentence (I understood this one and tested it ok) : "Declaring the same variable name again will erase all array values and reset the dimensions to the new definition."
 

[Melba23]

pixelsearch,

The 2 sentences are not linked - this example will I hope show what the 2 of them mean:

#include <MsgBoxConstants.au3>
#include <Array.au3>

; First sentence

; Initial declaration
Global $vVar[1] = ["Just me!"]

_ArrayDisplay($vVar, "Initial array", Default, 8)

; Redeclared so all previous values erased
Global $vVar[2]

_ArrayDisplay($vVar, "Redeclared empty array", Default, 8)

; Second sentence

Global $sString = "Initial value"

MsgBox($MB_SYSTEMMODAL, "Initial", $sString)

; Redeclare variable
Global $sString

; Value is unchanged as long as scope is not changed
MsgBox($MB_SYSTEMMODAL, "Redeclared", $sString)

Please ask if you have any questions.

M23

[pixelsearch]

Thanks a lot Melba23, you are helpful to everyone and I learned many things from your comments in the Forum

Your example is very clear and its last part worked nicely because you didn't assign a value to the 2nd Global $sString, while the help file states : "Declaring a variable with a simple value in the same scope will not change the value in the variable"

Dont you think the help file should indicate this : "Declaring a variable without assigning it a value, in the same scope, will not change the value in the variable"

 
 

[czardas]

5 hours ago, pixelsearch said:

Dont you think the help file should indicate this : "Declaring a variable without assigning it a value, in the same scope, will not change the value in the variable"

I concur that the original wording can easily be misinterpreted, which makes it appear to be incorrect:
Although unintentional, "Declaring a variable with a simple value" sounds like reinitialization in the context in which this appears.

Maybe this is easier to understand.
Redeclaring a variable in the same scope without reinitialization does not change its value.

I'm half inclined to think that this is more relevant to coding practice:
"Do not redeclare a variable in the same scope without reinitialization because it doesn't do anything."

Second sentence was meant to be a joke.

Edited June 4, 2018 by czardas

[jchd]

Quote

Declaring the same variable name again will erase all array values and reset the dimensions to the new definition. Declaring a variable with a simple value in the same scope will not change the value in the variable.

Agreed this wording can easily be misinterptreted. My proposal:

Within the same scope, redeclaring an array or a map† will erase its content and reset the dimensions to the new definition (in case of an array)†.
Redeclaring a flat variable (not an array nor a map†) without reinitialization is a pointless no-op.

† Since the future support of the Map datatype is uncertain (something VERY unfortunate) it may be wise to avoid mentionning it, just as it is missing in some other places of the help file.

[czardas]

Yeah that's much clearer to me.

[pixelsearch]

Thanks jchd & czardas for your proposals.

 I dont know who could amend the help file accordingly in a future release, but we did our best to make it happen 
 

[Melba23]

pixelsearch,

I can change the Help file - and my suggested text would be:

Quote

Within the same scope, redeclaring an array will erase its content and reset the dimensions to the new definition - use ReDim to retain existing content in the elements still available within the new array. Redeclaring a simple variable without reassigning a new value will retain the current content - and so is a pointless action.

How does thaty sound?

M23

[pixelsearch]

That's great too Melba23, it's very clear now and it sounds good.

There were one or two other parts of the help file that were as obscure, too bad I didn't pin them while reading them. In case I ever found them again, I'll let you know so you'll decide if it's worth the amend or not.

Can you imagine I started this thread because my script wasn't working and it was very frustrating, I had a Global $aHistorique[1][9] in the beginning of the script, then a few _ArrayAdd($aHistorique, $sFill) which populated the array correctly (while leaving its 1st row always blank +++) then a new Global $aHistorique[1][9] which emptied the array during a loop, before it was populated again with _ArrayAdd() etc... As it didn't work as I expected, I checked the help file... and here we are 

It's strange to work with an array that has always its 1st row blank, but well... I guess it's the price to pay if you want to populate it with  _ArrayAdd() only . Anyway the script is working now, I found where my error was... and it had nothing to do with the Array. Hurray !

[Melba23]

pixelsearch,

You can initially declare the array as Global $aHistorique[0][9] - then you will not get the blank line.

M23

[pixelsearch]

Melba23: thats why I like your comments, you always find incredible solutions. Who could ever imagine declaring the array as Global $aHistorique[0][9] ?

While you were answering, I was testing this :

#include <Array.au3>

Global $aHistorique[1][9]
_ArrayDelete($aHistorique, "0")

$sFill = "1|2|3|4|5|6|7|8|9"
_ArrayAdd($aHistorique, $sFill)
_ArrayDisplay($aHistorique)

It worked too, but your solution is better, replacing :

Global $aHistorique[1][9]
_ArrayDelete($aHistorique, "0")

with :

 Global $aHistorique[0][9]

Many thanks !
 

[Melba23]

pixelsearch,

Being able to declare empty arrays is a relatively new thing in AutoIt, so it is not surprising that you had not heard of it. Glad I could help.

M23

[pixelsearch]

@Melba23: as you are mastering the help file, maybe could you indicate this new possibility in it, i.e. declaring an empty array, with the syntax you indicated : ...[0,x]

As we are chit-chatting, it would be great to know who decides of the new features which will be added in AutoIt ?

I read the "Credits" & "AutoIt and Developer History" in the help file, when Jon (Jonathan Bennett) started it on October 1998, then all the names of you guys who climbed on board for this fantastic adventure, some of you are still here, 20 years after the project began... what a great job you did, thanks to all of you !

So who decides ? Maybe all of you vote before a decision is approved, or Jon decides by himself ? Maybe you'll tell us 

If I had been here in 1998, I would have fought Jon (lol) and never let him use the 0 index in Arrays, all arrays would have started from [1], bye bye index [0] and all the problems you created, because we constantly must have in mind that Ubound() is 1 greater than the last index, that index start from 0, that sometimes the 0 index contains the number of elements (sometimes not), etc... etc...

When I was programming with FoxPro (a database in the very early 1990's), the problem was already solved, we used statements like; Declare aArray[10, 50] which created an array of 10 lines and 50 columns, you accessed them easily from  aArray[1, 1] to  aArray[10, 50]

Before that, in the 80's , some other Basic languages allowed us to indicate, in the beginning of the program, a statement like: Option Base 0 (use the 0th index in arrays) or  Option Base 1 (start arrays with index = 1). Guess which one I always choosed ?

If I remember well, the 0 index was important in the 70's because memory was expensive and you couldn't afford to lose any byte of memory, that's why they gave you no choice and you had to use the 0 index, but that was in the 70's !

Ok, end of chit-chat or we'll never end this thread 

 

[Melba23]

pixelsearch,

I do not "master" the Help file - it is the work of many people. But I will take a look and see how empty arrays might be mentioned.

If you want a new feature to be added to AutoIt, then open a "Feature Request" in Trac (use the <Bug Tracker> link in the menu at the top of the page to access it. But you will need to provide a very good case as to why this feature needs to be added - development time is limited.

 We will have to agree to differ about arrays starting at 0/1 - I am so used to having a [0] element that I hardly notice, besides I often keep a count in there as is the case with so many arrays returned by AutoIt functions.

M23

[czardas]

I haven't had time to fully analyse how variables behave in all the possible scenarios. I like the terminology used by @jchd. The term 'Flat' (variables), as distinguished from arrays (or maps), is an easy way to differentiate data types. I trust an experienced author, and industry professional, to use correct or appropriate terminology. I believe the language used in the help file should be as universal as possible.

Edited June 5, 2018 by czardas

[jchd]

Don't align your compass to my english which as you already know isn't my mothertongue. I've no idea who first coined the terms "flat variable" or "flat file" nor when I started using it.

[czardas]

I think the term is very descriptive, but it might not be equally clear to everyone. This makes me think of something I was listening to on the radio earlier today. The discussion was about creating logs in order to trace mistakes made by AI (robots). The presenter suggested that something similar to a black box could be used: in the same way that aircraft record flight data. What made me laugh was when the lady expert explained to the presenter what the term 'black box' actually means in programming. It's something very different.

Edited June 5, 2018 by czardas

[RTFC]

On 6/4/2018 at 4:03 PM, Melba23 said:

and so is a pointless action

Hmmm Not sure I entirely agree here. Aside from the fact that calling some legitimate usage "pointless" in a Help document may put beginners off (it may spark the question: "why did they design it that way if it's pointless?"), I find it can actually be quite useful, namely when several different main scripts #include the same subsidiary library (of a bunch of UDFs written/cobbled together myself) and functions in the latter rely on Globals defined in the former. When debugging the library on its own, AU3check would throw a hissy fit if I didn't add dummy empty Global declarations at the top.

On 6/4/2018 at 8:31 PM, pixelsearch said:

If I remember well, the 0 index was important in the 70's because memory was expensive and you couldn't afford to lose any byte of memory, that's why they gave you no choice

Don't think you remember this too well, actually (although memory was waaaay more expensive then; that's true). The practice of using zero-index arrays originates in lower languages (notably assembly), where a base-address of a contiguous memory region is accessed with an offset and index of zero, and subsequent indices multiplied by the width of each entry added to the base address provide access to subsequent entries. That is, base address + [ 0 * width ] = base address.

Edited June 5, 2018 by RTFC

[czardas]

17 hours ago, RTFC said:

When debugging the library on its own, AU3check would throw a hissy fit if I didn't add dummy empty Global declarations at the top.

IMHO, this is unrelated to core language design and only attributable to the limitations of a specific tool. [Edit: actually there is no way to check syntax of a missing library ]. However, I agree that saying an action simply has no effect bloats the help file. In this case I believe it is worth mentioning (although I would word it differently) in order to differentiate the effects of redeclaration on different data types. Unintended usage is not without risk, although I like how you do that - I might start to copy you.

Edited June 6, 2018 by czardas

[BrewManNH]

7 hours ago, czardas said:

I agree that saying an action simply has no effect bloats the help file.

But it's necessary for clarity, such as the reference to declaring a Global Static variable being meaningless.