PureBasic Forums - English

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

x + 5 notation considered harmful!


The term is seemingly the same as 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: 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 .
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.

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

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

So? I see no error with that.

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.

Grunz wrote: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.

Its all just a matter of definition.

x + 1 is just a shorthand for x = x + 1. Therefore, is just a shorthand for 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.

freak wrote: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:

HELP FILE wrote: 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:

HELP FILE wrote: 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...

luis wrote: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

+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)

Tenaja wrote: 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:

HELP FILE wrote: variable*expression ; "variable" will be multiplied directly by the value of "expression"

Tenaja wrote: 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.

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.

freak wrote: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

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.

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.

freak wrote: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