log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- Latest hardware upgrade from RISCOSbits (News:)
- Announcing the TIB 2024 Advent Calendar (News:1)
- Code GCC produces that makes you cry #12684 (Prog:39)
- RISCOSbits releases a new laptop solution (News:)
- Rougol November 2024 meeting on monday (News:)
- Drag'n'Drop 14i1 edition reviewed (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:2)
- October 2024 News Summary (News:3)
- RISC OS London Show Report 2024 (News:1)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
Acorn Arcade forums: Programming: RETURN non-existent variable
 
  RETURN non-existent variable
  swirlythingy (20:03 15/2/2013)
  nunfetishist (11:33 16/2/2013)
    swirlythingy (21:49 16/2/2013)
 
Martin Bazley Message #121923, posted by swirlythingy at 20:03, 15/2/2013

Posts: 460
In BASIC, I frequently use constructs such as the following:

a%=FNa(b%,c%)
(...)
DEF FNa(RETURN b%,RETURN c%)
b%=2:c%=3
=1


This initialises the variables b% and c%, regardless of whether they actually existed prior to FNa being called.

I'm not sure how far this tolerance in passing a reference to something which doesn't exist yet extends, though. What happens if FNa tries to read b% and c% prior to writing to them? Limited experimentation suggests that RETURNed parameters are automatically initialised to 0 if they didn't exist when the procedure/function was entered, but is this defined behaviour and/or should I rely on it?

The BBC BASIC reference manual doesn't appear to cover such subtleties.
  ^[ Log in to reply ]
 
Rob Kendrick Message #121924, posted by nunfetishist at 11:33, 16/2/2013, in reply to message #121923
nunfetishist
Today's phish is trout a la creme.

Posts: 524
The BBC BASIC reference manual doesn't appear to cover such subtleties.
This is why you should be using a more modern and more carefully described language smile

On answering your question, I always assumed that such variables are initialised as zero and it was safe to assume that: but if it isn't, it's the caller's fault, and not the function's, IME (in case you're writing a library).

Also, I think if this was not the case, the runtime variable creation hack using EVAL and RETURN variables wouldn't work.
  ^[ Log in to reply ]
 
Martin Bazley Message #121928, posted by swirlythingy at 21:49, 16/2/2013, in reply to message #121924

Posts: 460
On answering your question, I always assumed that such variables are initialised as zero and it was safe to assume that: but if it isn't, it's the caller's fault, and not the function's, IME (in case you're writing a library).
In this case I'm writing both the caller and the function. The problem stems from the wide variety of circumstances in which I am attempting to use the same procedure. Depending on a switch, one of its parameters is either an input (and the program should error if it is not initialised) or an output (the program is able to derive the value of that parameter for itself and pass it back to the caller). Determining whether or not it has been "initialised", however, is more tricky - and in some other circumstances, it is perfectly valid for the same parameter to be write only!
Also, I think if this was not the case, the runtime variable creation hack using EVAL and RETURN variables wouldn't work.
No, that's safe, because you never read the value of the variable in the EVAL statement, you only assign it.
  ^[ Log in to reply ]
 

Acorn Arcade forums: Programming: RETURN non-existent variable