OK, I know we all do it eventually, but I rather belatedly joined in and tried to produce my own trivial shopping list proggy. Except I can't run it because of a compiler error.
In a sub which. hilariously, is virtually identical to a sub a few lines above which doesn't cause an error, an Object is incorrectly reported as a local variable which is never used in the sub (despite being correctly recognised throughout the rest of the program)..
The main prog is only 145 lines, the sub is only 8 lines, so nothing too tricky. and being a compile error, you don't even have to understand how it's supposed to work either. (it's slightly more complex because there is another module, the latest totally untested and un-compiled version of my INIfiles module, so for heavens sake don't anybody try to use that, it probably is a load of rubbish)
I'll try to find a fudge, but it really ought to have a proper fix.
The error message is entirely correct in this case, in fact you have two errors. You are trying to pass both a string literal (False) and an object property (Item.Text) ByRef but only regular variables can be passed ByRef as neither of the others is represented as a reference to a memory address.
No, the error I am getting is on line 140, it is nowhere near that line, it says Node is unused in that sub. I have no idea why you are being given a different error, but it is NOT the one I reported.
But thanks for finding those two, even though they are totally separate from the reported problem.
And yes it is correct for utility routines to have ByRef parameters as passing arrays or records by value is inefficient. I know it doesn't matter in this day and age with fast processors and huge memory, but my lifetime habits are that only incompetent idiots throw chunks of memory around, and I'm too old to change.
Had that error been reported, I wouldn't have needed anyones help fixing it.
I just fixed the problems you spotted, plus all the other instances of those problems but........
I still get the problem I originally reported, it is now on line 147.
I had hoped I was just seeing some obscure knock on effect, sadly not.
Why would an object need to be a reference in order to be passed by reference? It is the compiler's job to generate a reference to the passed value. If a numeric literal is passed to a procedure then clearly it cannot be a Ref parameter. Anything else can be because they take up a memory chunk which can be pointed to. A string literal, or anything else, has to live somewhere, that somewhere has an address, that address can be passed as a reference.
Maybe they don't do it in commercial languages, but in real time languages it is not unheard of to specifically have a "constant " qualifier for reference parameters (or whatever the specific language calls them) so that the compiler can trap assignment to the parameter as an error, thus allowing structured contants to be efficiently handled. So, yes, in some languages, a literal string can be passed by reference, just because it is efficient.
But anyway, I digress.
Back to the thread......
The problem is still there, despite sundry corrections.
P.S. What makes you think us old time real timers are obsessive about efficiency? LOL
I still get the problem I originally reported, it is now on line 147.
I'm afraid that I didn't get your original error as I had the Tools-> Check for unassigned... option disabled. You should be using "Node.Value = " as the assignment destination otherwise Basic4ppc assumes you are auto-declaring a local variable called "Node".
Quote:
Why would an object need to be a reference ...
In Basic4ppc it just does! Bear in mind that the language is both interpreted and compiled. In fact it started out interpreted only and "grew" a compilation phase only a few versions ago to improve performance. The tokenised version of the code that is interpreted is also used to generate the equivalent code for compilation so trying to ensure that the behaviour in both environments remains the same. A side effect of this is that there are compromises in the compiled code. Because the interpreter treats literals differently to variables and only allows a "proper" variable to be passed by reference that limitation also applies to the compiled version.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
Object incorrectly seen a variable by compiler
Linear Mode
