Subj : Translating CASE from BASIC to C++
To : Mike Luther
From : David Noon
Date : Fri Feb 16 2001 01:11 pm
Hi Mike,
Replying to a message of Mike Luther to David Noon:
ML> Another county heard from, Dave!
In this case, Bedfordshire.
ML>> 3.) Based on what I learned from the Watcom
ML>> Forum, my intitial
ML>> translator algorithim was writtne to simply back-level all
ML>> SELECT CASE in BASIC to the crude IF / THEN logic.
DN>> This is the most direct translation of SELECT CASE ...
DN>> CASE ... END SELECT into C. Just remember to include
DN>> the magic word "else", because a SELECT CASE statement
DN>> can select no more than one case from the list.
ML> The translator is presently written that way..
If you are using C strings rather than C++ Strings then you must also remember
to use strmcp(), or some similar function to perform the comparisions.
DN>> However, if you are prepared for a wild ride try using a hash
DN>> function and then switch based on the hash value. If your target
DN>> strings in your CASE clauses are known at compile time (this is a
DN>> requirement/limitation of the C/C++ grammar) then your converter
DN>> can do the hashing for you and ensure that the hash values are
DN>> unique. Then your code simply calls the hash function on the
DN>> variable and switches on the returned value.
ML> The target strings are, in some cases.
Known at compile time? Good.
ML> Based on that, the simplest
ML> thing to do is throw away the stupidity from the earlier code, at
ML> least in my case,and use numeric logic anyway. Problem solved, at
ML> least if SELECT CASE has at most only a very few numeric steps
ML> between 2 to 4, not 2 to 1000's,inclusive.
I'm not sure I follow. Do you plan to use a look-up array and then switch on
the matching subscript?
ML> There *ARE* places where the comparative string data is *NOT* known at
ML> compile time. It actually arises from the data. In fact, identical
ML> data is possible, leading to a first in first out logic that is used.
ML> Makes no difference on what happens later, first in logic for
ML> solution is correct.
Since the case values in a switch block are required to be known at compile
time in C/C++, the situation of duplicate values seldom arises in those
languages.
DN>>
http://www.snippets.org
ML> bookmarked. Which, my memory seems to recently have flagged, might be
ML> a problem. Either his site or is it Gray's interrupt library site
ML> has recently come back to me as "URL not found error" !
That's Ralf Brown, not Gray. Still, it probably doesn't matter much on a
monochrome monitor.
ML> The following I won't snip. It's actually what is critical to the
ML> OS/2 specific part of this thread and .. curiously not, but relevent!
DN>> Having written all that, I cannot let pass the
DN>> opportunity to point out that you have chosen the
DN>> wrong language for your task. PL/I is supported on all
DN>> the platforms you have mentioned and its SELECT
DN>> statement allows everything BASIC's does and more. For
DN>> me, the choice of PL/I would have taken very few brain
DN>> cycles.
ML> Did *NOT* realize PL/I is in DOS ??? (!) <- Pup scratching ear
You can d/l the Digital Research PL/I compiler for DOS from a Web site (search
on "CP/M"). It isn't anywhere near as slick as IBM Visual Age PL/I, but it is
almost as old as some of the people with whom I work.
ML> The reason I was plowing ahead toward C++ for OS/2, was that per the
ML> DB2 buy-me, try-me, you'll-love-me, banter, was that it specifically
ML> only noted interface capability, I *THOUGHT* in C++, that, function
ML> portability taken into account, was also available in DOS.
I haven't seen a DB2 client for DOS. There is certainly a 16-bit CAE for
Windows 3.x, but I haven't seen one for DOS. [Confession: I haven't looked very
hard.]
ML> Of course, you must understand and be patient with me. Of course, DB2
ML> doesn't run in DOS. But the older level interface programs that
ML> might be set to used DATA that DB2 has made available in disk or
ML> comm-linked operations, would still have a fighting chance to
ML> maintain a common-source toolset, even spanning DOS, OS/2, whateverX,
ML> and shudder, if under pain o death I have to do WIN-something ...
Nothing creakier than Win16, AFAIK. However, I have run the Win16 CAE for DB2
in WIN-OS/2 sessions for development work and it runs just fine. One gotcha is
that the Windows must have network support of some form, as there is no DB2
server capability for Win16. Hence you will need Win 3.1 under PC-DOS with IBM
LAN Extensions (if you can find a copy of the latter), WfWG under any
PC-DOS/MS-DOS that can host it, or WIN-OS/2 under Warp Connect or Warp 4.
ML> The bad thing about the future is that it exists. Sigh, in
ML> programming, a thing of beauty is a joy for never.. ;)
ML> Thank you for the ideas, Mikey goeth back to digging in the books,
ML> sigh!
If you don't have much background in SQL programming try the book on DB2 by
Craig Mullins. Or ask here, as I am currently working as a DB2 DBA (see origin
line) and can write that dialect of SQL in my sleep.
Regards
Dave
<Team PL/I>
--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)
