saving a program using put/get

[Stainnd]

After reading the previous post, (and from what numerous other people have told me), I decided to use a get/put statement and a random-access file thingy (a very technical term) to store my data and then load it (btw, its an rpg program. I am trying to store character information so that it can be recalled later). Here in lies my problem. I defined the type just fine.


TYPE character
charname AS STRING * 15
gender AS INTEGER
...
...
armor AS STRING *15
ac AS INTEGER
END TYPE

I also dim'd the new record.

Dim player AS character

In my createchar sub, I get the information from the user for the new character:
INPUT "Character name:", name$
INPUT "Male or Female:", gender$

(Actually I printed that, and then used an inkey do/loop to check for "m" or "f", and saved it as gender% as 1 or 2, but either way, it assigned gender as a variable)

And then for the finale:

OPEN "savedata.dat" FOR RANDOM AS #1 LEN = LEN(player)
player.charname = name$
player.gender = gender%
...
...
player.armor = "None"
player.ac = 10
PUT 1,1, player
CLOSE #1

After all this coding, I pretty much feel like a genius (b/c i'm a relatively beginner programmer with low expectations i guess). And you know what error Microsoft decides to give me when I run the program? "Identifier cannot include period." And it highlights the .charname part. Why is this happening and how can i fix it? (and any suggestions to improve my code wouldn't be minded either, though that is really not neccesary.) Thanks
-Mike

 

[trollacious]

First, DON'T use the same variable name for 2 different variables: gender$ and gender%. I know BASIC lets you do this with the different data type endings, but it's poor coding practice.

Second name$ is the name of a QBASIC function already, so you can't use that as a variable name. That's probably what's causing your error message. Didn't it capitalize itself when you first typed it in? If you use the QBASIC editor, that'll indicate what are QB reserved words/functions.

 

[edfair]

more familiar with GW than Q so may not apply:
With random required a field statement to define the fields when the file was opened, then a lset to transfer it to the record, then a put for storage.
A period isn't valid as a viariable name.

I wouldn't want to start an arguement but were I trying to do the same thing I would use sequential I/O since it is simpler.
open"o",1,"c:\test\test.dat"
print #1,variable1;",";variable2;",";variable3
close 1

Random access it the only way to go when you want to a linked list database or you want to work with entire groups of variables at one whack, but it is overkill for a simple data storage application.
Ed Fair
unixstuff@juno.com
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[Stainnd]

Thanks for your responses.

I didn't use two different gender variables. If you read carefully, I never used the gender$, i just wrote that instead of the code I used cause it was one line instead of like 20. Second, switching the name$ variable to charname$ or something like that does nothing.

A period is valid when using a random access file. In fact every tutorial there is on the subject (including qbasic help file) tells me to use a period. The type part is what defines the field, and i did transfer the variables to fields, and I did store them.

The problem is that qbasic doesn't like my period in the indentifier, except that all literature on the subject tells me to use a period. -Mike

 

[Stainnd]

I feel like the biggest tool on the planet. When I Dim'd the variable player, i didn't dim it shared. All my random access file stuff was done in a createchar sub, but i defined the character type and dim'd player in the normal part of the program. That was the problem. Thanks anyway. -Mike

 

[pebe]

Trollacious,
I can't agree with your comment about using the same variable with different types. Just because you don't do it, it isn't bad practice!

Variables should have meaningful names, and it is a bit pointless to pick up choice$ as an INKEY$ and then change it to boxes% to get its value. I never DIM variable AS type. I prefer to give the type every time I use it.

That way, when I look back at a program after 6 months I know that choice$ is a string and choice% is its value. Had I just used choice, I would have had to look up the beginning of the prog to see if I had DIMd it as a string, or left it as the default (choice!).

 

[trollacious]

You're absolutely right that you should use a variable name that's significant to the value in it. So, instead of using choice$ and choice%, you use strchoice (or choicestring) and intchoice (or choicenumber), or something like that. If you've read much on programming, this is the concept behind "Hungarian notation", which is (or at least WAS) widely taught as an effective way to keep track of what type of value is in what variable in C/C++ and other similar languages commonly used for commercial software.

As for it just being my opinion, you'll probably find more in agreement with what I wrote than not among professional programmers.

As well, when I program in QB, I always DIM the variables with their types individually so I don't have to constantly use the identifier characters at the end each time. Ironically, if you switch to VB, you can use Option Explicit that requires variable names to be Dimmed, and catches a LOT of mistakes from not remembering what exactly that variable name was before. For small programs, this isn't significant, but in larger ones it becomes quite useful. It's also a good habit to get into when/if you switch to other languages that require variable type declaration.

 

[logiclrd]

Also, what is really not particularly well-known is that in Visual Basic, ALL variables that are not [tt]Dim[/tt]med are of type [tt]Variant[/tt], no matter what type-declaration character you put after them. The type-declaration character causes it to change the type at runtime, and thus [tt]gender%[/tt] and [tt]gender$[/tt] are really the same variable: a [tt]Variant[/tt] called [tt]gender[/tt]. When you use [tt]gender%[/tt], it converts the value in [tt]gender[/tt] to an [tt]Integer[/tt] to do the operation, or converts the result of an assignment to an [tt]Integer[/tt] before encapsulating it into the [tt]Variant[/tt]. Similarly, when you use [tt]gender$[/tt], it automatically converts to a [tt]String[/tt] and back. Since it does this every time the variable is accessed, it is a very important performance hit, even though it is hidden. Thus, if you want to write code that performs decently in Visual Basic, you MUST [tt]Dim[/tt] your variables. You can still use the type-declaration character if you do; it will just give you an error if you specify a type that is different that the variable (e.g. [tt]Dim gender As String[/tt] followed by code referring to [tt]gender%[/tt] will cause an error, while accessing [tt]gender$[/tt] will not). In 99% of all cases, [tt]Variant[/tt]s are your enemy

 

[trollacious]

I realized that all variables not Dimmed in VB were Variants, which take significantly longer to process, but didn't realize that applied to variables with type identifiers, like % or $, too. Nor did I realize that VB interprets the variable without the identifier, making gender% and gender$ the same variable. Thanks for the info, logiclrd. # (bearded smiley face)

 

[pebe]

 I believe the main requirements for good programming are that:

  1. The program runs as intended - without bugs.
  2. The end product is user friendly and foolproof, ie. illegal user responses should have been anticipated and trapped, the printer seen to be ready, etc.
  3. The code should be as concise as is practicable.
  4. The coding should be easily understood by others - essential if someone else maintains the program.

If those criteria are met then the program should be acceptable. To achieve that end, the programmer should be free to use whatever legitimate routines, variables, and arrays he chooses within the constraints of the particular language used. If someone expects the code to be transportable, then that's a different ballgame not necessarilly within the remit.

This thread was started by Stainnd in this QBasic forum - not in the VB or any other forum. It is therefore reasonable to assume that the snippet of his program shown was written in QBasic. He used valid QBasic variables. While it would be nice to use only code that is transportable to another language/dialect, I fail to see why it is poor programming practice because it won't transport.

Assembly coding for one family of microcontollers is totally different from another family and cannot be transported. In some cases it is not even possible between members of the same family! So why expect it of Qbasic programming?

 

[logiclrd]

It was trollacious who started the Visual Basic discussion by bringing in the concept of 'Option Explicit'. I went on to give another good reason to use it: it forces you to write VB code that runs more efficiently. Code portability was never an issue, as far as I can tell. What WAS of issue was the portability of coding habits, and it is definitely better to get into the habit of [tt]DIM[/tt]ming all your variables if you have any aspirations beyond hobby code in QB

 

[trollacious]

I agree with the 4 points pebe listed as requirements for good programming.

Coding clearly also means with as little ambiguity as possible. Using the same variable name with a different identifier violates that. From the example in the beginning of the post, stainnd decided to use the integer value "1" for male, and "2" for female. For humans, males and females are ones and twos, though. To be clear, as well as flexible for later on, it'd have been best to declare CONST MALE=1, FEMALE=2 and just use the constant names throughout the rest of the program. If later on he decided to make those values strings, like "M" and "F" a simple change at the beginning of the program would take care of the whole program (I realize QB doesn't allow CONST with string, but a DIM SHARED would take care of that and still be transparent to the programmer), along with changes to the variable data types that stored those values.

Like logiclrd wrote, if you're going to be anything more than a hobby QB user, then developing good habits that you can carry to other areas is a good idea. If you visit other forums, you'll find questions and comments related to languages other than what the forum subject is, as well, because concepts in programming aren't boxed in for any given language. The QB language family was a big step in BASIC programming from its non-structured predecessors. It has a number of features in it borrowed and adapted from other languages, and the next large evolutionary step in the family was the VB series. Previous BASIC versions didn't allow data type declarations in DIM statements apart from the identifier characters. They didn't allow arrays to be DIMmed with any starting element desired. They didn't have SUBs and FUNCTIONs that kept data private to the procedure, which caused some problems when programmers didn't watch variable names closely. By looking at later versions of a language, we can see where the language has evolved with certain elements and certain coding practices enforced more strictly, while others were dropped.

 

[logiclrd]

Actually, trollacious, you can do strings in constants:
[tt]
CONST HelloWorld$ = "Hello, world!"
[/tt]

 

[trollacious]

Thanks, logiclrd. I hadn't tried that, nor seen anything about that in any reference before. #