Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Returning a String from a function
#1
Hi all!

Is it possible to return a string from a function? I tried this:
Code:
dim result as STRING
result = test(50)
print result

function test(n as UBYTE) as STRING
    return str(n)
end function

But I get a compile error:
Code:
test.bas:2: Cannot convert value to string. Use STR() function
Am I doing something wrong? I'm suspecting the answer is 'yes'. :-)
Reply
#2
LTee Wrote:Hi all!

Is it possible to return a string from a function? I tried this:
Code:
dim result as STRING
result = test(50)
print result

function test(n as UBYTE) as STRING
    return str(n)
end function

But I get a compile error:
Code:
test.bas:2: Cannot convert value to string. Use STR() function
Am I doing something wrong? I'm suspecting the answer is 'yes'. :-)

Your code looks ok to me. Sad This seems a reintroduced bug. Let me check it...
Can you compile against v1.2.6?
Reply
#3
Oops!

I just gave it a go with 1.2.6 r1812 (the final release of 1.2.6?) and it throws the same compilation error.

Here's the interesting thing - the call to the function only fails to compile if it's within the same file as the function declaration. So if I make two files, like this:

ReturnString.bas:
Code:
function test(n as UBYTE) as STRING
   return str(n)
end function

TestReturnString.bas:
Code:
#include "ReturnString.bas"

dim result as STRING
result = test(50)
print result

... and then compile TestReturnString.bas, then everything is fine. I guess this explains why some of the library files compile okay, they have String functions in them but never call themselves. :-)
Reply
#4
Ah! Further to this, it appears that successful (or not!) compilation actually depends on where the call is in the file.

If the call appears BEFORE the declaration then compilation will fail. But if it appears AFTER the declaration then compilation succeeds.

i.e. this version won't compile:
Code:
dim result as STRING
result = test(50)
print result

function test(n as UBYTE) as STRING
   return str(n)
end function

... but this remixed version will actually work okay:
Code:
function test(n as UBYTE) as STRING
   return str(n)
end function

dim result as STRING
result = test(50)
print result

This only seems to be true for String functions - functions that return numerics appear to work fine regardless of where the call is.
Reply
#5
Okay, I remember. It's not a bug.
If you call a function in advance (not being declared yet) the compiler will asume it's a FLOAT function. You have to use DECLARE, to declare the function header in advance (like in C):
Code:
declare function test(n as Ubyte) as String

dim result as STRING
result = test(50)
print result

function test(n as UBYTE) as STRING
   return str(n)
end function
If you don't use DECLARE, everything (parmeters and return type) are supposed to be Float. So, the BUG in the compiler is the compiler should complain that your later function declaration doesn't match the expected return type.
Reply
#6
Ah, gotcha. That seems simple enough - thanks for the help!

I got out of the habit of having to declare functions in advance since I started doing Java rather than C for work. :-)
Reply
#7
Okay, I'm still not quite there... apologies! :-)

I'm having strange problems when I declare functions in advance. Code which would previously compile starts giving 'undefined label' compilation errors once I declare a function.

For instance, this segment of a high score routine compiles okay:
Code:
'table arrays
dim hsScore(10) as UINTEGER
dim hsName(10) as STRING

'displays the table and prompts the user to enter a name
sub hsEnterName(hsPos as UBYTE)
    
    'get the user to enter a name
    dim hsNewName as STRING
    hsNewName = "NOBODY"
    
    'assign the name to the array
    hsName(hsPos) = hsNewName
    
end sub

function hsGetName(hsY as UBYTE) as STRING
    return "TEST"
end function

However, I can't call hsGetName unless I declare it, so I changed the code to include a line for that:
Code:
'table arrays
dim hsScore(10) as UINTEGER
dim hsName(10) as STRING

declare function hsGetName(hsY as UBYTE) as STRING

'displays the table and prompts the user to enter a name
sub hsEnterName(hsPos as UBYTE)
    
    'get the user to enter a name
    dim hsNewName as STRING
    hsNewName = "NOBODY"
    
    'assign the name to the array
    hsName(hsPos) = hsNewName
    
end sub

function hsGetName(hsY as UBYTE) as STRING
    return "TEST"
end function

Now when I try to compile I get this:
Code:
test.bas:51: Error: Undefined label '_hsName'

The longer piece of code that this comes from generates similar but slightly different compilation errors (sometimes the label names are not ones that I've used in the code), and the line numbers reported do not always point to relevant lines of code (e.g. sometimes they point to lines which only have comments on them).

Am I missing something in the declare statement? This is still with 1.2.7, btw.
Reply
#8
Ok, this is another *NASTY* bug. Fixed now. Sorry. :oops:
Download new release 1.2.8r2153, here: <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Archive#Latest_Development_Version">http://www.boriel.com/wiki/en/index.php ... nt_Version</a><!-- m -->

1.2.7 is *flawed*. I'm going to remove it from the download page. It's obvious I was impatient to add new features instead of making more testing. Sad
1.2.8 is much better. I won't add new features from a while (in 1.2.8). It has some major code rearrangements (which might introduce new bugs). So better stay here until the compiler is well tested before going into 1.2.9 with Dynamic arrays (or the whatever).
Reply
#9
Well, that seems to work perfectly now! The only errors left are in my own code. :mrgreen:

Many, many thanks, boriel!
Reply
#10
Ok. This bug is close (Well, this bunch of them). Still a -O3 bug pending, BTW :?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)