Subj : Translating CASE from BASIC to C++
To : David Noon
From : Mike Luther
Date : Tue Feb 13 2001 03:20 pm
Another county heard from, Dave!
DN> How far off the wall are you prepared to go? If you
DN> fancy a bit of mathematical amusement, read on.
I've already snapped ..
DN> In the general case, one cannot do so directly. If the
DN> values to be compared are integral then the conversion
DN> is straightforward, but for anything else it's a chore.
to this, I think. Of course there *IS* a difference between knowledge and
understanding! Huge grin!
DN> Remember that C is very flexible about what it
DN> considers to be an integer. Every char is actually a
DN> shrunken int. But a char followed by a NUL char
DN> constitute a string, which is not an integer.
Yes.
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.
The translator is presently written that way..
DN> However, if you are prepared for a wild ride try using a hash function
DN> and then switch based on the hash value. If your
DN> target strings in your CASE clauses are known at
DN> compile time (this is a requirement/limitation of the
DN> C/C++ grammar) then your converter can do the hashing
DN> for you and ensure that the hash values are unique.
DN> Then your code simply calls the hash function on the
DN> variable and switches on the returned value.
The target strings are, in some cases. Based on that, the simplest thing to do
is throw away the stupidity from the earlier code, at least in my case,and use
numeric logic anyway. Problem solved, at least if SELECT CASE has at most only
a very few numeric steps between 2 to 4, not 2 to 1000's,inclusive.
There *ARE* places where the comparative string data is *NOT* known at compile
time. It actually arises from the data. In fact, identical data is possible,
leading to a first in first out logic that is used. Makes no difference on
what happens later, first in logic for solution is correct.
I'll snip the example. No sense wasting the bandwidth..
I've already got him ..
DN> For a very good supply of hash functions in C, try Bob
DN> Stout's "snippets" collection:
DN>
http://www.snippets.org
bookmarked. Which, my memory seems to recently have flagged, might be a
problem. Either his site or is it Gray's interrupt library site has recently
come back to me as "URL not found error" !
The following I won't snip. It's actually what is critical to the 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.
\ ?
Did *NOT* realize PL/I is in DOS ??? (!) <- Pup scratching ear
The reason I was plowing ahead toward C++ for OS/2, was that per the DB2
buy-me, try-me, you'll-love-me, banter, was that it specifically only noted
interface capability, I *THOUGHT* in C++, that, function portability taken into
account, was also available in DOS.
Of course, you must understand and be patient with me. Of course, DB2 doesn't
run in DOS. But the older level interface programs that might be set to used
DATA that DB2 has made available in disk or comm-linked operations, would still
have a fighting chance to maintain a common-source toolset, even spanning DOS,
OS/2, whateverX, and shudder, if under pain o death I have to do WIN-something
...
The bad thing about the future is that it exists. Sigh, in programming, a
thing of beauty is a joy for never.. ;)
Thank you for the ideas, Mikey goeth back to digging in the books, sigh!
Mike @ 117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
