local variable1, macrostring as string
variable1="This is a string"
macrostring="variable1"
¯ostring="This is a new string"
That is valid in Foxpro and assigns "This is a new string" to variable1. In X# I get the error "The left-hand side of an assignment must be a variable, property or indexer"
This is actually supported, but there seems to be a small bug in the compiler currently which does not allow this exact syntax. But if you change "=" with ":=" it will work:
Kevin,
This automatic expanding of strings that have an embedded macro is not on by default. It adds quite an overhead to the speed of the compiler and runtime because all strings need to be checked for an embedded ampersand.
local lcMacroTest = "Success" as string
local lcInsertString as string
lcInsertString = "This is the macro: &lcMacroTest "
MessageBox(StrEvaluate(lcInsertString))
We assume that you as a developer know when a string has a macro (or may have a macro) and you can decide when to add this and when not.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
local variable1, macrostring as string
variable1="This is a string"
macrostring="variable1"
¯ostring="This is a new string"
That is valid in Foxpro and assigns "This is a new string" to variable1. In X# I get the error "The left-hand side of an assignment must be a variable, property or indexer"
On the vfp side using name expressions combined with "Store" is faster as no macro expansion is involved and allows you to set multiple targets if needed.
Thomas,
This has been implemented in X# in the mean time.
In fact it was already working for the := operator (which is handled by the "assignmentexpression" rule in the compiler.
However we forgot to check for macro expressions in the LHS of the "binaryexpression" rule (the '=' operator can also be a comparison) . This binary expression is "promoted" to an assignment expression when it is the first expression on an expression statement.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
robert wrote:This has been implemented in X# in the mean time.
I had realized that - but I expect the "Store to (nameexpr)" to be faster compared to macrocompilation in xSharp as well, so I decided to mention the vfp "better practice" in the hope that no premature micro-benchmark comparison between vfp and xSharp ensues, as such code parts should be the exception and not really relevant fo compare between runtimes.