InterviewSolution
Saved Bookmarks
InterviewSolution
| 1. |
Solve : New, again, with BASIC? |
|
Answer» This is my first posting here. I did some BASIC programming back in the mid-1980s and now decided I wanted to get back into it again. This attached program was my first new attempt at it, using QB 1.1. I've since gotten into QB 4.5 and like it much better. One suggestion I have is to accept both Upper Case Y and Lower case y such asBasic and variants use AND and OR. Either way, a better approach would probably be a function. StrComp is a function found in more recent Versions of Visual Basic. It is not present in older QBASIC and QuickBASIC packages, but you can write a Version of it: Code: [Select]CONST FALSE = 0 CONST TRUE = NOT FALSE DECLARE FUNCTION STRCOMP(str1 AS STRING, str2 AS STRING, COMPARETEXT AS INTEGER) FUNCTION STRCOMP(str1 AS STRING, str2 AS STRING, COMPARETEXT AS INTEGER) IF COMPARETEXT THEN STRCOMP=(UCASE$(str1)=UCASE$(str2)) ELSE STRCOMP=(str1=str2) END FUNCTION Not tested, I'll admit. Speaking of Functions and subroutines, I notice a distinctive lack of them in the provided source listing, instead using GOTO for most of the flow control. Aside from that, you might want to consider looking into more modern alternatives. If not Visual Basic, then something like FreeBASIC. FWIW, your provided source listing compiles and runs with the freeBASIC if the "-lang DEPRECATED" flag is PASSED to the compiler. (it does provide a warning about a variable). I know this does not directly pertain to your question, but I think you should give QB64 a try. It is a modern remake of QB and is almost completely syntax compatible. If you are not just doing this for fun and actually want to gain some programming skills, you should choose a more modern programming language as BC suggested (maybe C#) because once you learn that one, most other programming languages will just fall into place; it wont take much learning time because of the similarities.First - A big thank you to DaveLembke, BC_Programmer and Linux711 for your suggestions and help. I appreciate your interest. Dave: I tried your suggestion for accepting both upper and lower case of a letter. As you suspected the && (AND) || (OR) will not work in QB 4.5. I modified it to a syntax that does work; see my attached file, BOTHCASE.txt. Thanks for the offer for additional assistance. BC_Programmer I must admit I'd never heard of the "StrComp," function and the code you provided is a little above me at this point. You make a good point about functions and subroutines. I can see where that is better than using GOTO for most of the flow control. Linux711 I'll add your suggestion to my list of apps to try. So now my list has: 1. QB64 2. Visual Basic 3. FreeBasic 4. QB64 I am doing this for fun but also want to gain some programming skills. [recovering disk space, attachment deleted by admin]I think it would be simpler to convert the ENTER$ variable to an uppercas before it goes to the if statement. I believe to do so you type: UCASE$(ENTER$) In your code. Quote from: Newbe on January 27, 2013, 12:36:29 PM Dave: I tried your suggestion for accepting both upper and lower case of a letter. As you suspected the && (AND) || (OR) will not work in QB 4.5. I modified it to a syntax that does work; see my attached file, BOTHCASE.txt. Thanks for the offer for additional assistance. Original Code: [Select]CLS PRINT "Would you like to print this information?" INPUT "ENTER 'Y' for YES"; Enter$ IF Enter$ = "y" THEN Enter$ = "Y": GOTO PrintIt IF Enter$ = "y" THEN GOTO PrintIt IF Enter$ <> "y" THEN IF Enter$ <> "Y" THEN GOTO RUSure PrintIt: PRINT : PRINT "Print it": END RUSure: PRINT : PRINT "Not print it": END What about: Code: [Select]CLS PRINT "Would you like to print this information?" INPUT "ENTER 'Y' for YES"; Enter$ Enter$ = UCASE$(Enter$) IF Enter$ = "Y" THEN GOTO PrintIt GOTO RUSure PrintIt: PRINT : PRINT "Print it": END RUSure: PRINT : PRINT "Not print it": END Or, changing it to use structured programming, rather than "street BASIC" stuff (I think I'll describe that in a bit): Code: [Select]CLS PRINT "Would you like to print this information?" INPUT "ENTER 'Y' for YES"; Enter$ Enter$ = UCASE$(Enter$) IF Enter$ = "Y" THEN PRINT "Print it" ELSE PRINT "Not print it" END IF END That is essentially what you are "emulating" using the street BASIC goto. GOTO was the only control structure you could use in some early BASIC interpreters for Personal Computers. However, there hasn't been a good reason to limit yourself to using GOTO as the only method of flow control. It makes things more difficult to follow, and as programs get larger, it can become impossible to keep track of all the control flow. This applies equally to "GOSUB"; GOSUB works basically like GOTO, but you can make it return to where you used it with RETURN. For example: Code: [Select] CLS PRINT "Would you like to print this information?" INPUT "ENTER 'Y' for YES"; Enter$ Enter$ = UCASE$(Enter$) IF Enter$ = "Y" THEN GOSUB PRINTIT ELSE GOSUB NOPRINTIT END PRINTIT: PRINT "Print it" RETURN NOPRINTIT: PRINT "Not print it" RETURN END This is functionally identical to the above. Naturally the appropriate logic would go within each, as I imagine you are implying with your own example. Quote BC_Programmer I must admit I'd never heard of the "StrComp," functionStrComp isn't in QuickBASIC, or most older BASIC dialects. I was thinking of Visual Basic. Quote and the code you provided is a little above me at this point.My code was in error, actually. The purpose is to create a new Function- STRCOMP, for comparing strings. Though perhaps a stumbling block for you is that you don't appear to be using Functions at all. EXAMPLES of common functions include LEFT$(), RIGHT$(), etc. StrComp() as present in languages that have it- unsurprisingly- compares the two strings you give it. if the first string is less than the second in the sort order, it returns -1; if they are equal, it returns 0. and if the second string is smaller, it returns 1. Now, I quite recall my initial hurdles learning about Functions. The best way I found to consider them is more or less like a Math function. For example, math usually portrays math functions as f(x), which performs some function f on the value x. Most BASIC dialects include common Functions such as SIN, COS, and TAN. A Function, then, usually has a few basic properties. -A Name. This is pretty obvious. You need a name for a function so you can call it and use it. -Arguments. Most functions take in inputs. for example, the trigonometric functions accept a number. This isn't required, though. -A return value. This is what the function gives you back. Now, in the case of StrComp, we have the following: The Name will follow the standard "convention" of QuickBASIC, which is all uppercase function names. I think it looks ugly and makes the code look like it's yelling but when in Rome... Anyway, the name here will be STRCOMP. Arguments. Our function will compare two strings. So we will need to accept two strings as arguments. We also want a argument to determine whether we will be case insensitive. We will accept an "INTEGER" number value. 0 will MEAN we don't want to compare text, and 1 will mean we do. ("Compare Text" meaning to be case insensitive) QuickBASIC's rules regarding functions means we have to "DECLARE" it before we use it. This isn't 100% necessary but it's a good habit anyway. The line is essentially used to tell the compiler "I'm going to be using a Function, if you don't know what it does when you see it, don't worry, I'll tell you". Code: [Select]DECLARE FUNCTION STRCOMP(BYVAL str1 AS STRING,BYVAL str2 AS STRING, BYVAL COMPARETEXT AS INTEGER) AS INTEGER the Function is declared with two String Arguments, and one INTEGER argument. the final section says the type of the Function's return value. in this case, INTEGER. BYVAL is worthy og explanation as well. This says that the Function will accept the parameters "By Value". In other words, when you call the function, the function get's a copy of what you sent it. This prevents the Function from changing those parameters, which can cause side effects later on. Here is the implementation: Code: [Select]FUNCTION STRCOMP(BYVAL str1 AS STRING,BYVAL str2 AS STRING,BYVAL COMPARETEXT AS INTEGER) AS INTEGER IF COMPARETEXT THEN str1 = UCASE$(str1) str2 = UCASE$(str2) END IF iF str1<str2 THEN STRCOMP=-1 IF str1=str2 THEN STRCOMP=0 IF str1>str2 THEN STRCOMP=1 END FUNCTION The first step we take is to check if the passed in COMPARETEXT argument is non-zero. This satisfies the IF condition, and we then change the two input strings to be the uppercase versions of themselves by assigning the result from the UCASE$() function on them. After that, we simply follow the convention. "return" values are set by assigning values to the name of the function. In this case, we set the appropriate values to STRCOMP inside the function. The last thing we assigned when the function exits will be used in place of the function call. Some examples: Code: [Select]PRINT "StrComp test." PRINT STR$(STRCOMP("False","FALSE",0)) PRINT STR$(STRCOMP("Turkey","Monkey",0)) PRINT STR$(STRCOMP("Animal","Weasel",0)) Quote Linux711 I'll add your suggestion to my list of apps to try. So now my list has:FWIW your budget program works fine in QB64 as well. QB64 is available here Dear OP, If you are comfortable with QB 4.5 just keep using it. You can make code that is both easy to read and efficient. You can define procedures and functions in QB 4.5 as well as different types of variables. And the ability to handle binary files in QB if very good. You don't need to learn another computer language unless you want to. Any language that does what you want is what you want. Age does not matter. If someday QB will not run on a new OS, you just put it in a VM and keep working. BYW, Fort ran is still around and does some very cool things. Once again my thanks to BC_Programmer for all the help. Geek-9pm: I appreciate your comments also.Several folks had suggested QB64 as a next step. So when BC_Programmer told me that my "budget program works fine in QB64 as well. QB64 is available here" I clicked the "here" link, downloaded, and installed QB64. It works fine and I like it but there is one thing I can't figure out how to change. I figured out how to get the editing window to full screen. But when I run the .bas program it goes to another window which is about 1/4 the size of my screen. In QB45 the program runs in the same window in which the code is entered, while QB64 opens a popup window of about 1/4 the size of the full screen; at least that's what mine does. I tried running QB64 with a desktop shortcut to qb64.exe and with the following desktop .bat file: cd\qb64 'Directory on my C: drive where qb64.exe is located. qb64.exe What am I missing?http://qb64.net/wiki/index.php?title=FULLSCREENThanks Linux711. I'll let you know how it works out. I haven't tried it yet in a program. It may be a few days though, since I have other stuff going.OK, I tried QB64 and can readily see how much it is advanced over QB45. However, at least on my Win XP machine, it is cumbersome for me - I guess it's just too much for me to absorb at once. I wrote the attached program in QB45 and do like the way it looks there - as a 2nd effort anyway. I ran this same code on QB64. It does run but: it opens in a window 1/4 the size of my monitor screen; the top section of the first screen has a blue background for the top half (as I intended) but black for the bottom half. The rest of the program runs the same as in QB45, just in the small window. There are other items, which I don't need to get into now. My main goal now is composing efficient code. Comments? [recovering disk space, attachment deleted by admin]Comments? Frankly I do not see any need to run this kind of program in 64 bit mode. To the best of by knowledge there is no advantage to letting a small progrm have more memory space than it could possibly use. The code yon provided will compile to a EXE that takes less that a megabyte. And the data space is uses is trivial. Am I missing something here? Quote from: Geek-9pm on February 08, 2013, 09:42:51 PM Comments?-QB64 is a 32-bit program, not a 64-bit one. -Original QB's data usage is severely limited, as a result of not having access to a Virtual Memory manager. (Go ahead, try to find all the anagrams in a 200K+ Dictionary). -64-bit Programs do not use more memory space. They have the capability to access more memory, though. Also: QB64 appears to auto-update. Though that one could go either way. It is actively developed, however, which is a plus. As for efficiency: Switching to subroutines and functions will speed up the code significantly. GOTO of course compiles to an Assembly JMP instruction. The issue with it is that it often wreaks havoc on the CPU prefetch cache, and basically every JMP will flush the prefetch queue. CALL and RET- which are used for functions and subroutines- work with the prefetcher logic. This wouldn't have a impact on your program- your program is currently fine, since most of it's time is spent waiting for user input. |
|