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) .