Hazard warning: hidden macro

[Grunz]

It might have been mentioned somewhere already, but I did not know what search term to use...

x + 5 notation considered harmful!


The term

Code: Select all

x+5

is seemingly the same as

Code: Select all

x += 5

in C.
But actually it is a hidden macro and the compiler will expand it to x = x + 5.

The importance of the difference can be seen is this example:

Code: Select all

some_array( Random(42) ) + 1

If it were the same as C's += then It'd increase the array at a random position by 1.
But it will expand to

Code: Select all

some_array( Random(42) ) = some_array( Random(42) ) + 1 

.
Which will instead add the content of a randomly determined other slot with 1 and assign that.

So, in the first case, it is not a relevant shortening of the code to write x + 5 instead of x = x + 5.
If you have some complex expression, then it might be shorter, but just then it is dangerous to use.
Overall conclusion is to avoid it just like goto.

[IdeasVacuum]

.... good or not good, I never felt comfortable with the syntax, but I have used it in forum snippets 'to conform'.

[MachineCode]

Which will instead add the content of a randomly determined other slot with 1 and assign that.

So? I see no error with that.

[netmaestro]

There is an error with that, the macro expansion is causing the Random() command to be executed a second time and the first slot, rather than being incremented, instead gets the incremented value of another randomly selected slot assigned to it. Very much not the expected result. At any rate, this gets mentioned from time to time and it's well to remember that you can't use any call, command or function with this code shortcut because it will get called twice.

[Joakim Christiansen]

The importance of the difference can be seen is this example:

Code: Select all

some_array( Random(42) ) + 1

If it were the same as C's += then It'd increase the array at a random position by 1.
But it will expand to

Code: Select all

some_array( Random(42) ) = some_array( Random(42) ) + 1 

.
Which will instead add the content of a randomly determined other slot with 1 and assign that.

This is basically code that doesn't function as intended... Therefore I would categorize this as a bug(!!) in PureBasic since the compiler should be intelligent enough to avoid such stupidity.

[freak]

Its all just a matter of definition.

x + 1 is just a shorthand for x = x + 1. Therefore,

Code: Select all

some_array( Random(42) ) + 1

is just a shorthand for

Code: Select all

some_array( Random(42) ) = some_array( Random(42) ) + 1 

The compiler generates the correct output for that statement. So where is the bug?

The behavior is logical and consistent. Just because you like it to behave otherwise does not make it a bug.

[luis]

Its all just a matter of definition.

That's true. Is this defined using the terms you just used in the help file ?

I found this:

If the result of this operator is not used and there is a variable on the LHS, then the value of the expression on the RHS will be added directly to the variable on the LHS.

and about the "programming by examples" concept:

variable+expression ; The value of "expression" will be added directly to the variable "variable"

So

some_array( Random(42) ) + 1

should mean

1 ; the value of the expression

is added to

some_array( Random(42) ) ; the variable

The above is one (ONE) precise variable element inside the array

Looks like a bug to me.

If it was intended to work this way should be documented but looking the above excerpts from the manual give me the impression this was not the intention...

[Joakim Christiansen]

If it was intended to work this way should be documented but looking the above excerpts from the manual give me the impression this was not the intention...

+1

[Tenaja]

+1

When the manual says this:

variable+expression ; The value of "expression" will be added directly to the variable "variable"

...and NOT this...

variable+expression ; This is expanded out to "variable" = "variable" "expression"

It is is a confirmed bug, because by the definition given in the manual, the gode generation fails. HOWEVER, the bug can be squashed by a simple manual update, if the latter was the original intent.

I really hope the code is changed, though, because it will be much more convenient to have it behave "as it should." Not only did we "all" write code based on the current manual text, it is also more "convertable" to other languages to keep the existing manual text.

BTW, the manual is misleading in any case, if one uses the multiplication operator...
x*4 ... the expression (4) is added to the variable...
It should read "The expression is carried out upon the variable." With this text, it is accurate regardless of which operator is used (add, subtract, multiply, etc)

[luis]

BTW, the manual is misleading in any case, if one uses the multiplication operator...
x*4 ... the expression (4) is added to the variable...

That was specifically for the "+". The sentence is repeated and adjusted for each operator:

variable*expression ; "variable" will be multiplied directly by the value of "expression"

HOWEVER, the bug can be squashed by a simple manual update, if the latter was the original intent.

Yes, even if I would bet it was not. But only Fred can comment on that.

[freak]

The original intend was to have a simple shorter way to update a variable. It was never meant to be used with complex expressions (not to mention function calls with side effects such as Random()) on the left hand side.

[luis]

The original intend was to have a simple shorter way to update a variable. It was never meant to be used with complex expressions (not to mention function calls with side effects such as Random()) on the left hand side.

OK, thanks. So the help should read:

variable+expression ; The value of "expression" will be added directly to the variable "variable". Well, not really. Unless "variable" is actually an expression too complex or causing side effects since the shorthand is expanded to variable=variable+expression and I'm not keeping track of the original destination variable. So a variable expression resulting in different outcomes for every instance of it could bring all the negative consequences of the case. Do you follow me ? What did you expect ?"

I'm joking, but this is what happen when you have to guess expecting something different because commonly accepted elsewhere (for a reason IMHO) and not clearly stated differently in the manual.

I just made a post requesting to mention this in the "PureBasic Docs" thread -> http://www.purebasic.fr/english/viewtop ... 95#p390495

[freak]

Very funny.

The help just needs to read: Statements of the form <exprA> + <exprB> are expanded to <exprA> = <exprA> + <exprB>. This is not complicated and clearly states the current behavior. I really don't see why this is such a big deal.

Btw, if you want this behavior to be different, feel free to post it as a feature request. Screaming bug or whipping out the sarcasm won't get you anywhere.

[luis]

The help just needs to read: Statements of the form <exprA> + <exprB> are expanded to <exprA> = <exprA> + <exprB>. This is not complicated and clearly states the current behavior. I really don't see why this is such a big deal.

Maybe it's not big. But it's a problem for someone or this thread would not exist. Hence the request in the appropriate thread after your clarification.

Btw, if you want this behavior to be different, feel free to post it as a feature request. Screaming bug or whipping out the sarcasm won't get you anywhere.

Thanks for the tip.
I didn't scream. I considered the options (and historically weighted the possibilities of a modification of the current behavior for something of this kind) and decided a little sarcasm was the most logical choice. I don't see you threading lightly in the forums, BTW. I was a feather.

[Psychophanta]

Its all just a matter of definition.

x + 1 is just a shorthand for x = x + 1. Therefore,

Code: Select all

some_array( Random(42) ) + 1

is just a shorthand for

Code: Select all

some_array( Random(42) ) = some_array( Random(42) ) + 1 

The compiler generates the correct output for that statement. So where is the bug?

The behavior is logical and consistent. Just because you like it to behave otherwise does not make it a bug.

(1Up)
Indeed, all depends on what do you want to do