I've been faced with the job of translating everything from PowerBASIC to C++ in order to survive. Like it or not I have to provide application cross-platform compatibility between DOS, OS/2 and .. WIN-xx, if I go into that. I've also been advised by one client that the Feds told them that here in the USA, 7 years of support have to be given for any old system when a new one is implemented in certain medical applications with medical records. I don't represent that as gospel, only what I have been told to expect... ;)

Now .. the only way I can seemingly, perhaps, gain seven years of cross-platform interoperability between OS/2, and DOS ... and shudder,WIN-xx ..
is with WATCOM V11(b) which I licensed along with the books, and where it may go as version (c) etc., a long time ago.

So ..

I'm about 60% through writing an auto-translator from PowerBASIC 3.5 source to Watcom V11 (b). It's been educational. One of the things that has been a stumbling block to me is the use of CASE in BASIC where the switch logic is based not on numeric conditionals, but alpha conditionals.

This surfaced in the OS/2 echo a bit ago with something that Sarah replied to.
I posted it in the Watcom Forum. I'd like to attempt to re-look at the issue here to see if anyting inspirational shows here please:


1.) How can you handle CASE translations from BASIC to C++
for OS/2, with emphasis on WATCOM V11(b) as the toolset?

2.) SWITCH functions only with numeric logic, as I now think
is the only way it works. That's what I learned in the
Watcom Forum when this question was posed there.

3.) Based on what I learned from the Watcom Forum, my intitial
translator algorithim was writtne to simply back-level
all SELECT CASE in BASIC to the crude IF / THEN logic.

Write the translator so that it converts the SELECT CASE
to form a conditional master variable, based on what
was used for the SELECT conditional variable.

Re-design SELECT CASE as a parade of IF/THEN constructs.

That works fine for numeric-based stuff. In my limited knowledge of C++, it can degenerate into lots and lots of lines of code for non-numeric logic. It still seems to me that handling strings ain't near so easy in C++ as it is in BASIC, sigh..

Using the stock WATCOM libraries, remember this has to work across, DOS,OS/2 and .. shudder .. likely WIN-xx too, what do we do? Suggestions would be appreciated. However, that's really unfair, isn't it? ;)

I think Sarah is faced with this same problem as well, but maybe not in WATCOM V11, but some other compiler. Thus the problem is generic? But is sure is OS/2 programming related, at least to me and I suspect others.


Thanks ..


Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hello Mike,

I know nothing about C, C++ (not to mention Watcom C), so I'm problably not much help to you and I can only give a very general reply.

Wednesday 07 February 2001 09:17, Mike Luther wrote to All:

2.) SWITCH functions only with numeric logic, as I now think is the
only way it works.

So you need to embed the alpha-numeric logic (comparison) inside a numeric logic (comparison), in C every comparison is numeric, no matter what. What kind
of alpha-numeric logic is used ? Can you give specific examples?

Concerning cross-compability at source code level: only use documented standard
elements which behave the same with all compilers on all platforms (but I think
you already know that).


Greetings -=Eddy=-

email: e.thilleman@freeler.nl
e.thilleman@hccnet.nl

... My best view from a Window was through OS/2.
--- GoldED/2 3.0.1
* Origin: * <- Tribble . <- TRIBBLE.RAR (2:280/5143.7)

I'm not lost as to getting this part... Eddy,

So you need to embed the alpha-numeric logic (comparison) inside a numeric logic (comparison), in C every comparison is
numeric, no matter what.

That's within my understanding of all this.

What kind of alpha-numeric
logic is used ? Can you give specific examples?

The rest is multi-faceted. At different places I do different things that are text comparison based. The following post here from yours asked a question, I think, as to whether the test logic changed at run time.

Yes, it does. Therefore, reducing it to numeric logic isn't quite as easy as i
the comparison could be determined at compile time. That would be easy (I think!) Simply switch the logic to numeric to start with and forget text! After all, integer operations are, I guess, at this level about as ast and efficient as you can get! As a matter of fact, from what littleI know, long integers, in some cases, may be even as good or better than short ones..

Concerning cross-compability at source code level:
only use documented standard elements which behave the
same with all compilers on all platforms (but I think
you already know that).

Oh yes... I'm horribly trying to keep the portability issue in front of me at all times, but learning is expensive... ;)

Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Another county heard from, Dave!

How far off the wall are you prepared to go? If you
fancy a bit of mathematical amusement, read on.

I've already snapped ..

In the general case, one cannot do so directly. If the
values to be compared are integral then the conversion
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!

Remember that C is very flexible about what it
considers to be an integer. Every char is actually a
shrunken int. But a char followed by a NUL char
constitute a string, which is not an integer.

Yes.

3.) Based on what I learned from the Watcom
Forum, my intitial
translator algorithim was writtne to simply back-level all
SELECT CASE in BASIC to the crude IF / THEN logic.

This is the most direct translation of SELECT CASE ...
CASE ... END SELECT into C. Just remember to include
the magic word "else", because a SELECT CASE statement
can select no more than one case from the list.

The translator is presently written that way..

However, if you are prepared for a wild ride try using a hash function and then switch based on the hash value. If your
target strings in your CASE clauses are known at
compile time (this is a requirement/limitation of the
C/C++ grammar) then your converter can do the hashing
for you and ensure that the hash values are unique.
Then your code simply calls the hash function on the
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

Stout's "snippets" collection:
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!

Having written all that, I cannot let pass the
opportunity to point out that you have chosen the
wrong language for your task. PL/I is supported on all
the platforms you have mentioned and its SELECT
statement allows everything BASIC's does and more. For
me, the choice of PL/I would have taken very few brain
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)

Hi Mike,

Replying to a message of Mike Luther to David Noon:

Another county heard from, Dave!

In this case, Bedfordshire.

3.) Based on what I learned from the Watcom
Forum, my intitial
translator algorithim was writtne to simply back-level all
SELECT CASE in BASIC to the crude IF / THEN logic.

This is the most direct translation of SELECT CASE ...
CASE ... END SELECT into C. Just remember to include
the magic word "else", because a SELECT CASE statement
can select no more than one case from the list.

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.

However, if you are prepared for a wild ride try using a hash
function and then switch based on the hash value. If your target
strings in your CASE clauses are known at compile time (this is a
requirement/limitation of the C/C++ grammar) then your converter
can do the hashing for you and ensure that the hash values are
unique. Then your code simply calls the hash function on the
variable and switches on the returned value.

The target strings are, in some cases.

Known at compile time? Good.

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.

I'm not sure I follow. Do you plan to use a look-up array and then switch on the matching subscript?

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.

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.

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" !

That's Ralf Brown, not Gray. Still, it probably doesn't matter much on a monochrome monitor.

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!

Having written all that, I cannot let pass the
opportunity to point out that you have chosen the
wrong language for your task. PL/I is supported on all
the platforms you have mentioned and its SELECT
statement allows everything BASIC's does and more. For
me, the choice of PL/I would have taken very few brain
cycles.

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.

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.

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

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

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.

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!

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)

Hello Mike,

Tuesday 13 February 2001 23:13, Mike Luther wrote to Eddy Thilleman:

Yes, it does. Therefore, reducing it to numeric logic isn't quite as
easy as i the comparison could be determined at compile time. That
would be easy (I think!) Simply switch the logic to numeric to start
with and forget text! After all, integer operations are, I guess, at
this level about as fast and efficient as you can get! As a matter of fact, from what littleI know, long integers, in some cases, may be
even as good or better than short ones..

If you can put multiple chars inside one long integer, I guess...

Concerning cross-compability at source code level: only use
documented standard elements which behave the same with all compilers
on all platforms (but I think you already know that).

Oh yes... I'm horribly trying to keep the portability issue in front
of me at all times, but learning is expensive... ;)

Keeping cross-compability prevents you from using specific advantages of specific platforms, but you can include specific code for specific platforms inside IFDEF...ELSE...ENDIF (or ENDDEF, I don't remember exactly) compiler directive's testing for the target platform. So if you can use advantages of a platform with just localized code inside IFDEF...ELSE...ENDIF compiler directive's, why not? :)


Greetings -=Eddy=-

email: e.thilleman@freeler.nl
e.thilleman@hccnet.nl

... I program like a MAN. I use COPY CON PROGRAM.EXE.
--- GoldED/2 3.0.1
* Origin: Bugsbugsbugsbugsbugsbugsbugsbugsbugsbugsbugs (2:280/5143.7)