Jump to content
KC Grimes

Use of "#" instead of "select"

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Haha 1

Share this post


Link to post
Share on other sites
3 hours ago, AZCoder said:

 

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

Hell no.

 

Cheers

  • Haha 5

Share this post


Link to post
Share on other sites

Could do with a good laugh. :rofl:

Share this post


Link to post
Share on other sites
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);

}

Share this post


Link to post
Share on other sites
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++. :xmas:

 

Share this post


Link to post
Share on other sites
3 hours ago, rübe said:

So... what's the point?  :don16:

Is the question I was thinking of too

Share this post


Link to post
Share on other sites

@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.

  • Like 1

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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 #.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
12 hours ago, rübe said:

So... what's the point?  :don16:

 

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

  • Like 1
  • Haha 6

Share this post


Link to post
Share on other sites
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++. :xmas:

 

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

Share this post


Link to post
Share on other sites
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.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×