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 --- FleetStreet 1.25.1 * Origin: My other computer is an IBM S/390 (2:257/609.5) .