kinda wondering, would it really be needed

[doppler]

I maybe dreaming in the wrong language here.

Consider I want to increment a variable by 1:

QB64pe way x=x+1
dreaming x=+1

x=+1 is closer to C than the official quick basic language, but can it be made to work as a way in QB64pe ?  Would it be worthwhile ???  Or am I just strange ????
I use a lot of variables to act as pointers, arrays and such.

[ahenry3068]

If you really want to code like that you could easily do something like this.

Code: (Select All)

Dim I As _Integer64





I = 10



INC I





Print I

Print

End



Sub INC (X As _Integer64)

    X = X + 1

End Sub

[doppler]

If you really want to code like that you could easily do something like this.

Code: (Select All)

Dim I As _Integer64





I = 10



INC I





Print I

Print

End



Sub INC (X As _Integer64)

    X = X + 1

End Sub

That's one way.  But using a sub requires sharing or knowing what variable is passed to sub.  Need a generic sub, for all math types byte, integer ... and work for all INC variables passed down.  Such as INC x, INC y, INC z.  XYZ are different math types but I want all to increased by 1.  Or my understanding about SUB's is wrong.

[SMcNeill]

I maybe dreaming in the wrong language here.

Consider I want to increment a variable by 1:

QB64pe way x=x+1
dreaming x=+1

x=+1 is closer to C than the official quick basic language, but can it be made to work as a way in QB64pe ?  Would it be worthwhile ???  Or am I just strange ????
I use a lot of variables to act as pointers, arrays and such.

I don't think anything like this would ever end up being added.

Consider this:

x = -1

Now, is that an assignment of x = (-1), or is it a shortcut command to x = x - 1?

It's the same with the x = +1.    "+1" is just an explicit way of displaying the sign of the number there.  It's not something which we usually see written in code, but it *IS* perfectly valid existing syntax.

Try this, but you'll need to paste it and then compile without hitting any other key at the IDE wants to strip off that explicit + here:

Code: (Select All)

x = 3

x = x + +3

Print x

If written in a different IDE, the above works and runs without any issues.  In our IDE, we try to simplify the code by stripping off that explicit plus symbol in there.

It's because of this old functionality where +1 is just an sign-explicit "1", that I don't think we'd ever see something like this pop into the language.

What I personally think would be nice would be the addition of the ANY type.


SUB INC(x AS _ANY)
  x = x + 1
END SUB

Then you don't need a function for all those values.  It'll pass the value back and forth and match types automatically for you....

Oh... But to dream.... 

[Jack]

just my opinion, aside from the += or whatever op= brevity, it's performance efficiency is probably negligible

[CharlieJV]

I maybe dreaming in the wrong language here.

Consider I want to increment a variable by 1:

QB64pe way x=x+1
dreaming x=+1

x=+1 is closer to C than the official quick basic language, but can it be made to work as a way in QB64pe ?  Would it be worthwhile ???  Or am I just strange ????
I use a lot of variables to act as pointers, arrays and such.

Just a side-thought ...

Consider adjusting the dream just a hair, so that the operator is before the equal sign, like this:

   

[bobalooie]

Consider this:

x = -1

Now, is that an assignment of x = (-1), or is it a shortcut command to x = x - 1?

It's the same with the x = +1.    "+1" is just an explicit way of displaying the sign of the number there.  It's not something which we usually see written in code, but it *IS* perfectly valid existing syntax.

...

What I personally think would be nice would be the addition of the ANY type.


SUB INC(x AS _ANY)
  x = x + 1
END SUB

Then you don't need a function for all those values.  It'll pass the value back and forth and match types automatically for you....

Oh... But to dream.... 

I realize you know this, but others may not be familiar with the notation.

Understanding that C is a minimalist language and can be a PITA, the C operators ++ and -- are explicit:

x++  increment
x--    decrement 

The way C can handle assignment operators is handy and also explicit:

x += 3 is the same as x = x + 3 etc.

I like the idea of _ANY as well.

[CookieOscar]

+1 vote for type _ANY (but for different reasons than a 'fix' for OP's idea).

And I've never seen '=+' as an arithmetic assignment operator.
For good reasons, as outlined by SMcNeill (ambiguity with explicit sign or unary operators).

But if implemented properly (ie. +=, -=, /=, <<=, etc), together with the post-operators (eg. x++), and especially for speed the prefix-operators (eg. ++x), I would very much welcome it! Though, I'd understand if that isn't going to happen in QB64.

PSS: a tidbit for the speed monkeys out there: ordered from theoretical slow to fast:

•     CALL INC(x) (calling that sub INC as shown in the suggestion post above)
  
•     x = x + 1
  
•     x += 1
  
•     x++
  
•     ++x
  

[Kernelpanic]

Something like ANY has existed in Visual Basic since version 2, the Variant data type. However, it should be used with caution, otherwise you'll lose track of which variable value/type Variant currently contains.

Whether it would make sense to introduce this data type in QB64... 

Variant data typre

Addition: 
Up to and including VB6, the as Any data type was also supported. The as Any keyword disabled type checking and allowed any data type to be passed or returned, for example, to a C program.

It has since been deprecated and is no longer supported. It has been replaced by the Object (as Object) data type, which can hold any data.

[madscijr]

The only reason I brought up ANY and UNION was to allow us to reference API functions in a straightforward way. 

As for using _ANY (AKA variant) types in programs, the only place I can see that being useful is for operator overloading, i.e., creating a function that can receive different parameter types. For example, the IIF function. Before the team added a native _IIF, you had to "roll your own", so you would create a function 

Code: (Select All)

Function IIF$(bTest%, ValueIfTrue$, ValueIfFalse$)
    If bTest%=_TRUE then IIF$ = ValueIfTrue$ Else IIF$ = ValueIfFalse$
End Function

The problem was, if you also wanted an IIF that instead returned an integer, single, long, or any other type, you had to create separate functions for every type.

Code: (Select All)

Function IIFInt%(bTest%, ValueIfTrue%, ValueIfFalse%)
    If bTest%=_TRUE then IIFInt% = ValueIfTrue% Else IIFInt% = ValueIfFalse%
End Function

Function IIFLong&(bTest%, ValueIfTrue&, ValueIfFalse&)
    If bTest%=_TRUE then IIFLong& = ValueIfTrue& Else IIFLong& = ValueIfFalse&
End Function

etc.

This is annoying, and also makes it harder to code and debug because now you have to remember the names of all the different IIF functions you created.

Now that QB64PE had a native _IIF, however, that problem had gone away for me, and I haven't run into any situations yet where I otherwise need operator overloading.

However, there are a bunch of API functions I'd like to try using from QB64PE, where Microsoft's API uses types involving UNION and ANY, that I have not been able to figure out how to define in QB64PE where the equivalent types aren't supported. @SpriggsySpriggs and some other more advanced users very graciously tried to explain about counting bytes, calculating sizes for padding, and even writing test programs in C to output the memory size for different types, etc., to try to figure out the byte sizes needed to fudge type definitions to approximate a QB64PE type compatible with a given API function, but it is all very complicated and tedious, and as a lowly BASIC programmer, just too difficult for me. Therefore, I proposed that we somehow make the UNION and ANY available in QB64PE simply to allow referencing these API functions more easily.