Use of "#" instead of "select"

[KC Grimes 79]

New to 1.82 is the alternative syntax of "select", being "#".

 

Ex.

testArray = ["A","B","C"]; 
_var = testArray select 1; //B
_var = testArray # 1; //B
_var = testArray #1; //B
_var = testArray#1; //B

All of the above statements have the same return. 

 

Is the "#" operator used in any programming languages in this way? I can't say I have seen it on the web development side, at least. Just wondering where this came from.

 

Not to ask "What's the point?", but, what was accomplished here other than a slight decrease in file size (with bulk use)? Is there a performance difference?

 

I am a fan of plain english, which is why SQF is awesome to me. I will probably continue to use "select" unless there is a solid reason to switch.

 

Anyone know anything further on this?

[AZCoder 921]

Other than the change log, I don't even see it documented yet.

I always thought select was kind of odd, as opposed to testArray[1] or something, or maybe testArray.where(x => x == "B") or some such. I think I've only seen # used as a preprocessor directive, such as #ifndef and so on.

 

 

[POLPOX 778]

At least in Development Branch, there are no performance differences.

 

[KC Grimes 79]

59 minutes ago, AZCoder said:

Other than the change log, I don't even see it documented yet.

I always thought select was kind of odd, as opposed to testArray[1] or something, or maybe testArray.where(x => x == "B") or some such. I think I've only seen # used as a preprocessor directive, such as #ifndef and so on.

 

 

 

I agree that "selecting" via [] would be great, just for standardization sake. 

 

48 minutes ago, POLPOX said:

At least in Development Branch, there are no performance differences.

 

 

Thanks for sharing, makes sense since they are both engine-based operators that (should?) do the same thing. 

 

I will say it may be growing on me a bit, particularly for multidimensional arrays, as opposed to select select select...

[Dedmen 2703]

19 hours ago, KC Grimes said:

Not to ask "What's the point?", but, what was accomplished here other than a slight decrease in file size (with bulk use)? Is there a performance difference?

 

I also don't see the point. No there is no performance difference.
It is a direct dropin for (_array select _index).

The brackets matter. # has higher priority than select. So when using # you sometimes don't need brackets that you'd need with select.

 

 

 

18 hours ago, AZCoder said:

Other than the change log, I don't even see it documented yet.

I always thought select was kind of odd, as opposed to testArray[1] or something, or maybe testArray.where(x => x == "B") or some such. I think I've only seen # used as a preprocessor directive, such as #ifndef and so on.

 

 

Yeah. Preprocessor. It only took half a week after it was added to dev branch till people started reporting issues with conflicts between the preprocessor # and the script #.

 

Select via [] is not possible because of the way the SQF language works. You would have to change the entire language definition.

[AZCoder 921]

5 hours ago, Dedmen said:

Yeah. Preprocessor. It only took half a week after it was added to dev branch till people started reporting issues with conflicts between the preprocessor # and the script #.

 

Select via [] is not possible because of the way the SQF language works. You would have to change the entire language definition.

 

Hmmm, I'd like to see the source code on that, LOL.

[.kju 3244]

failfish 

[Grumpy Old Man 3545]

3 hours ago, AZCoder said:

 

Hmmm, I'd like to see the source code on that, LOL.

Hell no.

 

Cheers

[HazJ 1289]

Could do with a good laugh.

[Dedmen 2703]

On 13.4.2018 at 5:41 PM, AZCoder said:

 

Hmmm, I'd like to see the source code on that, LOL.

You want to see the source code of #?
Here you go:

 

function hashtag(array, index) {

    return select(array, index);

}

[AZCoder 921]

5 hours ago, Dedmen said:

You want to see the source code of #?
Here you go:

 

function hashtag(array, index) {

    return select(array, index);

}

 

Nein! I was referring to the entire code base being limited in how it can handle arrays. And besides, that's JavaScript, not C++. 

 

[fn_Quiksilver 1636]

with no speed increase its just not worth it, ill stick with select

[rübe 127]

So... what's the point? 

[Tankbuster 1746]

3 hours ago, rübe said:

So... what's the point? 

Is the question I was thinking of too

[rübe 127]

@Tankbuster

yep. unironically. If you're going to streamline array syntax, give us the usual C syntax already.

array[i]

Anyone is comfortable with this (and don't tell me the parser couldn't be improved to handle this, it's really no big deal).

But this cryptic hashtag? Just because it's shorter than writing select? No, thanks.

[Tankbuster 1746]

Even the BASIC I learned 30 years ago was better.

That said, I have some sympathy with BI here. They don't improve the language - we complain. They improve the language - we complain. :)

[.kju 3244]

let me repeat

 

Quote

 It only took half a week after it was added to dev branch till people started reporting issues with conflicts between the preprocessor # and the script #.

 

[rübe 127]

@.kju sounds like fun times.

[Grumpy Old Man 3545]

12 hours ago, rübe said:

So... what's the point? 

 

To improve readability, of course:

_lol = [" ","a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"];
_xD = [5,3,2,5,0,11,3,4,2,3,7,1];
_xP = [7,2,3,2,1,3,1,1337,4,9,7,2];
systemchat str ((_lol#(_xD#0*_xP#11))+(_lol#(_xD#1*_xP#10))+(_lol#((_xD#2*_xP#9)+1))+(_lol#(_xD#3*_xP#8))+(_lol#(_xD#4*_xP#7))+(_lol#(_xD#5*_xP#6))+(_lol#(_xD#6*_xP#5))+(_lol#(_xD#7*_xP#4))+(_lol#(_xD#8*_xP#3))+(_lol#(_xD#9*_xP#2))+(_lol#(_xD#10*_xP#1))+(_lol#(_xD#11*_xP#0)));

 

Cheers

[x39 101]

17 hours ago, AZCoder said:

 

Nein! I was referring to the entire code base being limited in how it can handle arrays. And besides, that's JavaScript, not C++. 

 

you always can look into https://github.com/X39/sqf-vm/tree/master/sqfvm-cpp which more or less as close as one can get without direct source code

[AZCoder 921]

1 hour ago, x39 said:

you always can look into https://github.com/X39/sqf-vm/tree/master/sqfvm-cpp which more or less as close as one can get without direct source code

 

I was really being facetious. Nevertheless that's pretty cool, thanks!

 

[Dedmen 2703]

15 hours ago, rübe said:

@Tankbuster

yep. unironically. If you're going to streamline array syntax, give us the usual C syntax already.

array[i]

Anyone is comfortable with this (and don't tell me the parser couldn't be improved to handle this, it's really no big deal).

But this cryptic hashtag? Just because it's shorter than writing select? No, thanks.

The parser could be improved but you would have to change core concepts of a language that is established for about 9 years now.
But the entire SQF language is literally
x command y
command x
command
[private] _variable = expression.

[constant] (a constant would be "1" or "{code}" or "[1,2,3]")

 

Like.. Using x command y and doing _array[1 is easy to.... No.. That would conflict with how Array definitions work.
You would have _array [1] which would be x y. And not x command y.
Other alternative _array.[1] or _array->[1]. These are atleast possible to implement without having to scrap the core concepts of the language.

 

10 hours ago, x39 said:

you always can look into https://github.com/X39/sqf-vm/tree/master/sqfvm-cpp which more or less as close as one can get without direct source code

Intercept might get you even closer.

[rübe 127]

@Dedmen I see, backwards compatibility is the actual problem here. Yeah, that's always nasty, and now is certainly not the time to do anything about this.

[Grumpy Old Man 3545]

22 minutes ago, rübe said:

@Dedmen I see, backwards compatibility is the actual problem here. Yeah, that's always nasty, and now is certainly not the time to do anything about this.

Probably one of the reasons they skipped java implementation for arma 3, which was a planned/discussed feature as far as I can recall.

Maybe some day it will be possible to use C++ and have access to AI core features...

 

Cheers

[Dedmen 2703]

22 minutes ago, Grumpy Old Man said:

Probably one of the reasons they skipped java implementation for arma 3, which was a planned/discussed feature as far as I can recall.

Maybe some day it will be possible to use C++ and have access to AI core features...

 

Cheers

Intercept ^^

Intercept has the possibility to get VERY deep engine access to the AI classes behind soldiers. Providing access to it is on my Todo. But I don't know what specific AI things will be accessible. Would of course be nice if one could control things that SQF can't.

But #offtopic

Also the Java implementation is still inside the game. Just not really accessible from the outside.

 

47 minutes ago, rübe said:

@Dedmen I see, backwards compatibility is the actual problem here. Yeah, that's always nasty, and now is certainly not the time to do anything about this.

I think that's also why they went for # and not for @. Because @ is already used in SQS.