• Andrew (unregistered) in reply to ammoQ
    ammoQ:
    The SUBString thingy looks a bit like a workaround. The way Oracle works, substr() in a SQL statement is processed by the SQL engine, while substr() in a PL/SQL statement is processed by the PL/SQL engine. Of course both should return exactly the same result for given input parameters; but if a bug in the PL/SQL engine caused incorrect results on some input parameters, transfering the work to the SQL engine as shown in the example might help. (Not that I know of any bug that would make this kind of function necessary)

    I believe all Oracle functions are PL/SQL. Not many people do it, but it's possible to compile Oracle functions through C: http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96624/12_tune.htm#48419 So, I suspect that the SUBSTR() function was written in C, and runs the same as a PL/SQL or SQL function.

    The above link also explains that it is slow to move from the PL/SQL engine to the SQL engine. The SELECT in the function call causes a switch to SQL; this is the WTF.

  • Andrew (unregistered) in reply to Andy Goth
    Andy Goth:
    misha:
    Surely "(bool)x" would be considerably more readable and do the same thing [as !!x]?
    Yes, if you're using C++ and descendents. However I usually encounter this kind of garbage when using C, which has no bool type. But thanks, I'll keep that in mind the next time I'm using C++.

    Yes, C can have a boolean type. I don't think the C++ bool type is any different; it's just required by the ISO standard to exist.

    typedef unsigned int bool; #define TRUE 1 #define FALSE 0

    bool done = FALSE;

    while (! done) { ... }

  • QuestionC (unregistered) in reply to Jim
    Jim:
    Enough about the booleans - what's that PRIVATE macro all about?
    A lot of programmers find the macro PRIVATE more intuitive than the keyword static. You see this a lot in Tanenbaum's Minix book.

    Incidentally, I am pretty sure the code snippet we see is just fallout from some form of TRUE, FALSE, MAYBE enum.

  • Andrew (unregistered) in reply to Mr. Shiny & New
    Mr. Shiny & New:
    My fav abuse of stored procs though is a pattern we used to see where I work: a stored proc whose only job is to do a SELECT and return a cursor. Why have the proc at all?

    That actually makes some sense. Store procedures can be called by application programs and return a cursor.

    An embedded C program can run it, and just know to fetch the rows. It may need to know the rows' record structure, by not the SQL that made it. EXEC SQL CALL STORED_SET(:CUR); ... EXEC SQL FETCH INTO :ROW FROM :CUR; ... EXEC CLOSE :CUR; A DBA can write and tune the SQL in the STORED_SET() procedure independently. The best person writes the C or SQL parts, respectively.

  • Kurt Duncan (unregistered)

    Here is why I sometimes use if (x == true)...

    Much of our legacy code was written by unix weenies who were raised on scripts. For scripts, success is indicated by zero, failure by a non-zero error code.

    So, a test for success as written by these guys, looks like if (foo()) { failure handler } else { success handler } ... which is the opposite of the way c, c++, etc work.

    Now... you can argue (as I do) that this is WTF code; nevertheless, it is still all over the place in our code base, so when I write logical code which goes if (foo()) { success handler } else { failure handler } it confuses all the unix weenies.

    So I often write if (foo() == true) specifically not to confuse the unix weenies.

    More generally, that means I am less likely to rely on a stateful test of a boolean for any reason, preferring the more obvious test against a constant/literal -- again, just to make clear what is going on.

  • ibiwan (unregistered) in reply to iMalc
    iMalc:
    The most general way of toggling between two values:

    BOOL toggle (BOOL inVal) { return TRUE + FALSE - inVal; }

    Now you can redefine TRUE and FALSE to whatever you like...

    Wow, that IS general -- it even properly handles fuzzy logic and expert systems! (FALSE=0, TRUE=255, act if truthiness is greater than or less than a given threshold...)

  • dkf (unregistered) in reply to QuestionC
    QuestionC:
    Jim:
    Enough about the booleans - what's that PRIVATE macro all about?
    A lot of programmers find the macro PRIVATE more intuitive than the keyword static.
    Plus some compilers (notably gcc and vc++) can use C extensions to mark a particular function so that it while it is visible outside the object file, it's not visible outside the shared library made from it. This is useful if you don't want to put all your source code in a single file and yet don't want client code poking its nose in where it isn't wanted... :-)
  • (cs) in reply to rumpelstiltskin
    rumpelstiltskin:
    Puckdropper:
    Qbasic isn't exactly BASIC. It is, but it isn't. Using QB, you can learn a lot about functional programming and things like parameter passing and writing functions (ahem: procedures--functions return a single value).

    What could you possibly learn about functional programming from QBasic?

    Apparently he meant procedural programming. Of course, QBaseic is not the best environment to learn the functional one.

  • Robert (unregistered) in reply to Andrew
    Andrew:
    Yes, C can have a boolean type. I don't think the C++ bool type is any different; it's just required by the ISO standard to exist.

    typedef unsigned int bool; #define TRUE 1 #define FALSE 0

    bool done = FALSE;

    while (! done) { ... }

    At least in C++ (and I think also in ISO C99) bool is not the same as unsigned int. Older implementations often use such constructs, yes. For example Visual C defines in some older headers

    typedef int BOOL
    (*shudder*). However, while a boolean in C++ and C99 is always implicitly convertible to an integer value, they are not the same. Furthermore, the lowercase versions of "bool", "true" and "false" have to be reserved keywords, not #define'd.

    So, in strict ANSI C++ (and until proven otherwise, I assert the same to be true in C99), the following is indeed correct and the if clause has to be evaluated.

    int x=2;
    [...]
    if ((bool) x == true) {
    [...]
    }
    In a broken implementation however, where bool is typedef'd to int and 'true' is just defined to be 1, the comparison (apparently) fails. This is not a problem of the standard, but of the implementation, but sometimes it just cannot be helped. Just don't use such 'sensitive' (and reduntant) comparisons in C/C++. Sometimes verbosity helps and adds clarity, in this case, it can actually hurt.
  • rjmccall (unregistered)

    The second function modifies a boolean variable in-place. Sure, it could be rewritten as a one-liner, but that doesn't mean the function itself is useless at all.

    Examples:

    /* This is simple enough without a helper function.  */
    my_bool = !my_bool;
    vToggleOnOff(&my_bool);
    
    /* This takes a moment to parse without a helper     */
    /* function, but we could maybe use a macro if we're */
    /* confident in our compiler's CSE step.             */
    status[i+1]->blighted = !status[i+1]->blighted;
    vToggleOnOff(&status[i+1]->blighted);
    
    /* This potentially has different semantics without  */
    /* a helper function.                                */
    hrkx_find_albatross(alb, st)->flogged = !hrkx_find_albatross(alb, st)->flogged;
    vToggleOnOff(&hrkx_find_albatross(alb, st));
  • rjmccall (unregistered)

    Fix the obvious omission in the last line.

    Many of the posts here are amusing, but Alex seems to consistently overrate his own own rather narrow experiences. These IT people hack out a few websites, and then suddenly they're wizened sages about all forms of programming.

  • Old Wolf (unregistered) in reply to Andrew
    Andrew:

    Yes, C can have a boolean type. I don't think the C++ bool type is any different; it's just required by the ISO standard to exist.

    typedef unsigned int bool; #define TRUE 1 #define FALSE 0

    bool x = 2; bool y = 3;

    if ( x != y ) { whoops }

    In C++, C99, and other languages with true boolean types, the only values that a boolean can have are 'false' and 'true'.

  • UTU (unregistered)

    There is something no-one has yet mentioned of the SUBString-function...

    First some background: Oracle still has some this that are possible on the SQL-engine, but not on PL/SQL-engine. For example, getting the next value of a sequence used to be such a thing up until 9iR2 (at least, I think they've changed it in 10g so that you can just assign "my_seq_nextval := my_sequence.nextval" instead of doing it the hard way "select my_sequence.nextval into my_seq_nextval from dual". This is where I would/am/will be writing a function "get_my_seq_nextval" to do the stupid thing so I didn't have to do it again and again.

    I'm just throwing guesses here, but ain't it just a possibility that on some century old system running Oracle 6 (read: something "old as time itself") there was no possibility to directly call SUBSTR from PL/SQL - and the code just stayed in the codebase as a relic from the past.

  • UTU (unregistered) in reply to UTU
    UTU:
    some this

    Ok. Who did it? Who stole "ng" from my "things".

    Captcha: burned

  • Andy Goth (unregistered) in reply to Kurt Duncan
    Kurt Duncan:
    Here is why I sometimes use if (x == true). For scripts, success is indicated by zero, failure by a non-zero error code. So I often write if (foo() == true) specifically not to confuse the unix weenies.
    Despite my complaining, I often do "redundant" tests like this just to be clear. But I only do it for pointers (explicit comparison against NULL) and numbers (comparison against 0 or 0.0). I dislike automatic conversion to boolean; I think refusing to make this conversion is one of the few things Java got right. :^)

    I'm a Unix script weenie, too. :^) The reason Unix programs have an exit() value of 0 on success and nonzero on failure is that usually there's only one way for a program to succeed and many ways it can fail. (There are documented exceptions, like cmp(1).) But this success/failure mechanism is also used for truth: true(1) always "succeeds," and false(1) always "fails."

  • Bo, the ancient mainframer (unregistered) in reply to r
    r:
    That IF FALSE THEN TRUE ELSE FALSE is a classic that must get trotted out all the time.

    To paraphrase Terry Pratchett in one of the Discworld novels: "all statements are true for some value of true".

  • EPE (unregistered) in reply to ammoQ
    ammoQ:
    The SUBString thingy looks a bit like a workaround. The way Oracle works, substr() in a SQL statement is processed by the SQL engine, while substr() in a PL/SQL statement is processed by the PL/SQL engine. Of course both should return exactly the same result for given input parameters; but if a bug in the PL/SQL engine caused incorrect results on some input parameters, transfering the work to the SQL engine as shown in the example might help. (Not that I know of any bug that would make this kind of function necessary)
    I would guess that the author did not know he could do something like "result := SUBSTR(inputStr,startPos,endPos);".
  • hfrmobile (unregistered)

    it's something like this: Task: convert lower character to upper character

    if (character == "a")
      return "A";
    else if (character == "b")
      return "B";
    
    ...some lines later
    
    else if (character == "z")
      return "Z";
    else
      return "Sorry, don't know!";
    

    Seems that some programmers are paid per code-lines ;-)))

  • Zemm (unregistered) in reply to ais523
    ais523:
    It took me a while, because this was before I understood floating-point numbers were used by default (it's just 'a number', after all)

    Isn't that what DEFINT A-Z was for? And then use "var!" if you really did want a float?

  • Shill (unregistered) in reply to iMalc
    iMalc:
    The most general way of toggling between two values:

    BOOL toggle (BOOL inVal) { return TRUE + FALSE - inVal; }

    Now you can redefine TRUE and FALSE to whatever you like...

    OK, I'll take TRUE to be the maximum value of an integer on the platform and FALSE to be one less than that.

  • (cs) in reply to rjmccall
    rjmccall:
    Many of the posts here are amusing, but Alex seems to consistently overrate his own own rather narrow experiences. These IT people hack out a few websites, and then suddenly they're wizened sages about all forms of programming.

    And some of the IT people here post moronic comments about people whose background they know nothing about, probably trying to inflate their own experience levels. Unfortunately, they tend to expose themselves by the stupidity levels of their comments, as you have done. At least you made it very clear very quickly, so as not to waste anyone's time trying to figure out the levels of your idiocy. Thank you for that, at least.

  • Barfo Rama (unregistered) in reply to Kurt Duncan

    So that's why I always got everything backwards!

    Captcha: pointer

  • metin (unregistered)

    The ! operator is not used, because it is a software patent:

    http://profesores.matcom.uh.cu/~kyrie/documents/appft1.uspto.gov/isnot.html

  • 28% genius (unregistered) in reply to I Know PL/SQL
    I Know PL/SQL:
    Reuben:
    I like the fact SUBString does the same as SUBSTR, except for substrings longer then 100 characters where the output is truncated.

    I think that you will find that this condition will raise an ORA-06502: PL/SQL: numeric or value error, not truncate the string

    A few well-placed EXCEPTION WHEN OTHERS THEN NULL; blocks sprinkled through your code will take care of that.

  • Nelle (unregistered) in reply to Jonatan
    Jonatan:
    malfist:
    If you teach someone BASIC, you cripple their ability to program.

    I can't fully agree on that. Sure it is a limited language but also a good way to start when learning to program. At least in my case when I first started doodling in QBasic was when I was 6 ;). Converting from QBasic to C# was not so hard.

    Me too... Not in QBasic though ...

    Spectrum had a great Basic and an editor where you had only to press G and GOTO was already there ...

  • Speedbird (unregistered) in reply to misha
    misha:
    Jonatan:
    malfist:
    If you teach someone BASIC, you cripple their ability to program.

    I can't fully agree on that. Sure it is a limited language but also a good way to start when learning to program. At least in my case when I first started doodling in QBasic was when I was 6 ;). Converting from QBasic to C# was not so hard.

    Agreed. I started out in QBasic too. The advantage is that after a while, you start to realise the limitations of the language yourself, because you try to do stuff and it's harder than it should be. I didn't know I needed pointers 'cos I'd never heard of a pointer, but I knew I wanted to be able to put a reference to one variable in another. And you don't truly understand the importance of structured programming until you've written some truly tangled spaghetti code yourself :)

    So you learn lots about how not to do it. And then go buy a book on a real language.

    You hit the nail in the head with that comment, one common (and potential) problem is that the "developer" will never realize those limitations and continue to focus on the "language", eventually creating monstrosities such as the one shown in this article.

  • Nelle (unregistered) in reply to UTU
    UTU:
    UTU:
    some this

    Ok. Who did it? Who stole "ng" from my "things".

    Captcha: burned

    probably some rogue substring function ...

  • Hognoxious (unregistered) in reply to misha
    misha:
    I went straight from QB to C++, I don't think it is really any harder than doing C++ from scratch.
    And it's simple to go from C0807 to java too:
     
    public void A100_INITIALISE() {
      this.A110_OPEN_FILE();
      ... }
    
    misha:
    If you are by inclination or ability a half-decent programmer, learning any language isn't going to make you a *worse* programmer, any more than driving a crappy car would make you a worse driver.
    I disagree, it's possible to pick up bad habits that then need to be unlearned.
    misha:
    [disclaimer: I can't drive so I don't know if that last assertion is really true]
    Uh huh.
  • Piotr K (unregistered)

    The real WTF it that they used stored procedures. Stored procedures are EVIL. PL/SQL is a very limited language in comparison with modern OO languages. It always ends up with having some part of business logic in Java/.NET application and some part in stored procedures which is a BAD THING. Performance of SP also often sucks if compared to dynamic SQL queries. Use SP only when really needed.

  • Nero (unregistered) in reply to Jim

    VERY private

  • (cs) in reply to Robert
    Robert:
    At least in C++ (and I think also in ISO C99) bool is not the same as unsigned int. Older implementations often use such constructs, yes. For example Visual C defines in some older headers
    typedef int BOOL
    (*shudder*). However, while a boolean in C++ and C99 is always implicitly convertible to an integer value, they are not the same. Furthermore, the lowercase versions of "bool", "true" and "false" have to be reserved keywords, not #define'd.

    Actually, in C99, bool, true, false are not keywords. In <stdbool.h> there are lines:

    #define bool _Bool
    #define true 1
    #define false 0
    #define __bool_true_false_are_defined 1
    

    But _Bool is a true boolean type. As for BOOL, it's a Platform SDK type, and is still there.

  • (cs) in reply to Robert
    Robert:
    At least in C++ (and I think also in ISO C99) bool is not the same as unsigned int. Older implementations often use such constructs, yes. For example Visual C defines in some older headers
    typedef int BOOL
    (*shudder*). However, while a boolean in C++ and C99 is always implicitly convertible to an integer value, they are not the same. Furthermore, the lowercase versions of "bool", "true" and "false" have to be reserved keywords, not #define'd.

    Actually, in C99, bool, true, false are not keywords. In <stdbool.h> there are lines:

    #define bool _Bool
    #define true 1
    #define false 0
    #define __bool_true_false_are_defined 1
    

    But _Bool is a true boolean type. As for BOOL, it's a Platform SDK type, and is still there.

  • Anonymous (unregistered) in reply to Bob
    Bob:
    malfist:
    If you teach someone BASIC, you cripple their ability to program.

    Bollocks. BASIC programmers learn to program in a nice linear manner and understand the whole input, process, output concept. It's the best possible way to start learning to program. All of the recruits we've had recently get far too clever with pointers or spaghetti objects or some fucking framework <spits> and end up tripping over themselves due to a lack of basic skills.

    I agree. GOTOs make it possible to dig yourself a hole really fast if you can't code, which tends to set a minimum standard. Don't remember which flavors of BASIC implemented if/then/endif etc.

  • Guy (unregistered) in reply to Piotr K
    Piotr K:
    The real WTF it that they used stored procedures. Stored procedures are EVIL. PL/SQL is a very limited language in comparison with modern OO languages. It always ends up with having some part of business logic in Java/.NET application and some part in stored procedures which is a BAD THING. Performance of SP also often sucks if compared to dynamic SQL queries. Use SP only when really needed.

    Yea... Don't let the door hit you on your way out, Piotr.

    Guy

  • Robert (unregistered) in reply to Spectre
    Spectre:
    Actually, in C99, bool, true, false are not keywords. In <stdbool.h> there are lines:
    #define bool _Bool
    #define true 1
    #define false 0
    #define __bool_true_false_are_defined 1
    

    But _Bool is a true boolean type.

    Ok, so ANSI C++ and ISO C99 do differ in this regard, but not signifantly (whew). In C++, true/false are specified explicitly as the boolean literals, whereas 'bool' is the corresponding type specifier. Again something new learned, thanks ;)

    However, even it being a typedef to _Bool in C99 fortunately does not invalidate the main point: it is still a specific boolean data type, and not the same as int, therefore '(bool) x' has to be identical to 'true' for any non-zero value of x. Unfortunately, the second point also remains very true: do not bet on it that your specific implementation behaves correctly in this regard :(

    Ah, the wonderful world of (programming) language evolution...

  • sirGustav (unregistered)

    I really don't see what's wrong with the toggle function. It would be useful as a function pointer. I would also consider using it for the sake of clarity, heck even boost has a next() and prior() functions implemented as ++argument and --argument.

    Sure the implementation could be done in one line, but would that really change anything? It works, has no side effects and readable to people that dont use C/C++ like languages on a daily basis(afaik the ! operator doesn't exist in say vb or delphi).

  • erisdiscordia (unregistered) in reply to Andy Goth
    Andy Goth:
    misha:
    Surely "(bool)x" would be considerably more readable and do the same thing [as !!x]?

    Never mind the (bool)x. We're the Sex Pistols!

    e.

  • FreekV (unregistered) in reply to real_aardvark

    Bwahahahahahaahaahhhahh!!!

  • ac (unregistered)

    So, has PL/SQL had substr since the beginning? I recall having done lots of similar'ish hacks to get around missing features and sometimes old habits die hard. (still wtf, no-one uses forms 3 anymore, right?)

  • (cs)

    I started on Logo, then moved to Basic on an old Amstrad after finding out that I could list the code for any of the games I had. When my Dad upgraded to a 386 I moved onto QBasic. Eventually, with his 486 (which could run Windows 95 when it was released, it was GEM on the 386 and 3.1 on the 486 until then, CP\M on the Amstrad) I got into C++ via Deitel Deitel which I got from the local library. It gave me a thoroughly fine explanation of O-O coding, and was very good at explaining nuances of the language. I moved to C++ to find out about OpenGL, and, of course, a lot of the basic parts of graphics programming (such as double-buffering) I already knew from QBasic. I did a great little sniping game in it which included optional swaying grass (affected by wind velocity). Unfortunately, with the full complement of grass at about 500 blades, randomly swaying every frame, my Dad's PC ground to a halt. But it was pretty. Now I enjoy C#, although most of my work is still done in C++ and Win32.

  • ac (unregistered) in reply to Stone
    Stone:
    If you're using C from the 1980s, sure. C has had a bool type since '99.

    You mean like most people?-)

  • (cs) in reply to sirGustav
    sirGustav:

    Sure the implementation could be done in one line, but would that really change anything? It works, has no side effects and readable to people that dont use C/C++ like languages on a daily basis(afaik the ! operator doesn't exist in say vb or delphi).

    Aww, come on! This is the most ridiculous sattement-that-can-be-considered-as-VB-bashing I heard ever.

    pbItem = Not pbItem ' Basic/VB
    pbItem := not pbItem; ' Pascal/Delphi
    
  • (cs) in reply to Spectre
    Spectre:
    sirGustav:

    Sure the implementation could be done in one line, but would that really change anything? It works, has no side effects and readable to people that dont use C/C++ like languages on a daily basis(afaik the ! operator doesn't exist in say vb or delphi).

    Aww, come on! This is the most ridiculous sattement-that-can-be-considered-as-VB-bashing I heard ever.

    pbItem = Not pbItem ' Basic/VB
    pbItem := not pbItem; ' Pascal/Delphi
    
    not Not operator!().

    The comment refers to C-like languages with operator!() producing code intelligible to users of languages such as VB/Delphi/presumably Cobol that prefer the (slightly) more verbose "[Nn]ot." Perl, being perl, gives you the choice of line-noise or English. I rather wish that ole Larry had also offered multi-lingual support, eg

    n'est pas vrai qu'un plus un sont egale a deux.
    
    Boy, programming in floating-point (or "point flottant") arithmetic would be a breeze.

    Jeez, if your skin was any thinner, you'd be standing in ten pints of your own blood by now ...

  • david (unregistered) in reply to Spectre
    Spectre:
    rumpelstiltskin:
    Puckdropper:
    Qbasic isn't exactly BASIC. It is, but it isn't. Using QB, you can learn a lot about functional programming and things like parameter passing and writing functions (ahem: procedures--functions return a single value).

    What could you possibly learn about functional programming from QBasic?

    Apparently he meant procedural programming. Of course, QBaseic is not the best environment to learn the functional one.

    Reminiscent of the endless debates about whether language x "really is objected oriented" ie, whether language x really is smalltalk. BASIC is not by common definition a functional language, but it is a language in which one can write functional (or object oriented) programms, or (perhaps it comes to the same thing) a language in which one can write a functional language.

  • Nano (unregistered)

    #define TRUE 1 #define FALSE 0 int flag; ... flag=TRUE; ... flag=1-flag; /* toggle */

    I really like the TRUE+FALSE-inVal solution earlier though, who doesn't like arbitrary values for TRUE and FALSE!

  • Iago (unregistered) in reply to david
    david:
    BASIC is not by common definition a functional language, but it is a language in which one can write functional (or object oriented) programms
    No, you cannot write BASIC in a functional-programming style. It does not support higher-order functions. This means you simply cannot do FP in BASIC, period.

    Note that I am not using a "language x is not smalltalk" argument here. I am not holding up LISP or Haskell or anything as the "one true FP language" that every other language must imitate precisely. I am treating FP as a very broad and generic concept, and indeed one that can certainly be used to some extent in languages like C that are not traditionally considered FP languages. However, it cannot be used in BASIC.

    david:
    or (perhaps it comes to the same thing) a language in which one can write a functional language.
    This is not the same thing at all. You cannot write FP in BASIC. If you write a functional language in BASIC and then use that, then you are no longer using BASIC.

    To claim that you are still using BASIC, when you are using a functional programming language written in BASIC, is like claiming that C# programmers are all writing machine code, because C# is implemented in C++ which is compiled down to machine code.

    Anonymous:
    Don't remember which flavors of BASIC implemented if/then/endif etc.
    The IF/THEN statement was implemented in all BASICs, right from the very first version in 1963. Not sure about the history of proper functions and procedures, but they were certainly available in the first BASIC I ever used, which was in about 1984; I don't think I ever used a single GOSUB in all the years I programmed in BASIC.
  • Johan (unregistered)

    The real WTF is that the substr function takes the following arguments:

    string, startpos, length

    as opposed to

    string, startpos, endpos

    and that nobody noticed or mentioned this in the comments.

  • Johan (unregistered) in reply to Piotr K

    You must be smoking something. The real problem is java/.NET code trying to do what the database does, only "better" which is neither desired or achievable.

  • Piotr K (unregistered)

    No. The .NET/Java application server is for PROCESSING, the database is for STORING data. Procedural languages for stored procedures are so limited, that programmers must write stupid SUBString functions as workarounds. Besides letting DBAs touch your business logic code is a VERY BAD IDEA.

  • Anonymous (unregistered) in reply to Iago
    Iago:
    Anonymous:
    Don't remember which flavors of BASIC implemented if/then/endif etc.

    The IF/THEN statement was implemented in all BASICs, right from the very first version in 1963. Not sure about the history of proper functions and procedures, but they were certainly available in the first BASIC I ever used, which was in about 1984; I don't think I ever used a single GOSUB in all the years I programmed in BASIC.

    Here's the long version...

    Early BASIC: GOTOs

    110 INPUT "Do you want more stars? "; A$
    120 IF LEN(A$) = 0 THEN GOTO 110
    130 A$ = LEFT$(A$, 1)
    140 IF (A$ = "Y") OR (A$ = "y") THEN GOTO 40
    150 PRINT "Goodbye ";
    160 FOR I = 1 TO 200
    170   PRINT U$; " ";
    180 NEXT I

    QuickBASIC: multi-line conditionals

    if d < 0 then
    	usrquad = 0
    elseif d = 0 then
    	root1 = fnx(a, b, 0.0)
    	usrquad = 1
    else d = sqr(d)
    	root1 = fnx(a, b,  d)
    	root2 = fnx(a, b, -d)
    	usrquad = 2
    end if

Leave a comment on “No Thanks, I Prefer SUBString!”

Log In or post as a guest

Replying to comment #:

« Return to Article