Mike,

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.

That works fine for numeric-based stuff. In my limited knowledge of C++, can degenerate into lots and lots of lines of code for non-numeric logic.

Yes, it's difficult. But look at it from a different angle: All char's have a numeric equivalent, and you don't have to use that numeric equivalent to check for chars in a switch:

char num[2];
// get a number/char whatever in num[]

switch (*num)
{
case '0':
.
case '9':
case 'a':
case 'A':
case 'b':
case 'B':
.
.
default:
};

That's the same as using a select case ASC("*") in basic *=some character. That doesn't help with full strings, but it may give you ideas. And it's a generic solution.

still seems to me that handling strings ain't near so easy in C++ as it is BASIC, sigh..

That is true, strings are much easier in Basic.

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

I've been discussing Sarah's problem with her via e-mail, and the solution was similar to the above.

┌■ Herbert Bushong harchon@centurytel.net
├■ Blackbeard's BBS herb@intelec.com http://www.intelec.com/software/
└■ Fido: 1:19/19 Intelec: 239:600/0

---
■ RM 1.31 2508 ■ Bad Dog! Don't chew the power cor!@!Phzzt!&$ NO TERRIER

--- QScan/PCB v1.20a / 02-1026
* Origin: Blackbeard's BBS ■ Ville Platte, LA ■ 337-468-3385 (1:19/19)

Thanks friend Herbert ..

Mike,

Yes, it's difficult. But look at it from a different
angle: All char's have a numeric equivalent, and you
don't have to use that numeric equivalent to check
for chars in a switch:

char num[2];
// get a number/char whatever in num[]

switch (*num)
{
case '0':
.
case '9':
case 'a':
case 'A':
case 'b':
case 'B':
.
.
default:
};

Correct ...

I've been discussing Sarah's problem with her via e-
mail, and the solution was similar to the above.

On hand. Studying it.

But .. that doesn't help much where the comparator was X$, for example and X$ is a variable length string. I was a bad boy at an earlier time in life and I'm not much better now. Basicly, I'm still trying to digest what I ate when I
was a younger programmer. Gloom.

Mike @ 117/3001

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

But .. that doesn't help much where the comparator was X$, for example and is a variable length string. I was a bad boy at an earlier time in life a

No, it doesn't help with that much at all. :)
You could do a series of nested switch statements (check first letter, check second letter, etc... until you've narrowed it down to a unique value), but that could get real hairy.

I'm not much better now. Basicly, I'm still trying to digest what I ate w I was a younger programmer. Gloom.

:)

┌■ Herbert Bushong harchon@centurytel.net
├■ Blackbeard's BBS herb@intelec.com http://www.intelec.com/software/
└■ Fido: 1:19/19 Intelec: 239:600/0

---
■ RM 1.31 2508 ■ Cat's Favorite Game - Ha! Made you look!

--- QScan/PCB v1.20a / 02-1026
* Origin: Blackbeard's BBS ■ Ville Platte, LA ■ 337-468-3385 (1:19/19)

But .. that doesn't help much where the comparator was X$, for
example and X$ is a variable length string. I was a bad boy
at an earlier time in life and I'm not much better now.
Basicly, I'm still trying to digest what I ate when I was a
younger programmer. Gloom.

yes, if X$='fred' you can't case or switch that out... you have to break down to only one value... i don't think that adding the values together will be of much help since more than one set of adds can equal the same result... at some point, you will end up with the if/then/else structures... even if only to assign a single value to be able to case or switch with... however, doing that if/then/else tree once and then using the single value every else is much better than using if/then/else everywhere that you need to branch based on that
selection...

)\/ark


* Origin: (1:3634/12)

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

If I may ask... do your "alpha conditionals" test for bit patterns?
If so, might you rewrite them using numeric values of those bit
patterns?

---
■ testing... ■
* Origin: FONiX Info Systems * Berkshire UK * +44 1344 641625 (2:252/171)

I posted to Sarah ..

No, it doesn't help with that much at all. :)
You could do a series of nested switch statements
(check first letter, check
second letter, etc... until you've narrowed it down to
a unique value), but
that could get real hairy.

what my auto-transator does with the stuff now. It converts the SELECT CASE to
a slurry of equivalent IF/THEN constructs. The logic knows how to swap between
variable types on the basis of another stunt I've settled on.

In my case I ignored the Bill Gates wry humor advice to throw away the trailing
variable type identifiers on all variables! I kept all mine all throughout my
work.

So . .. I made up my mind I would keep that up by kludge in C/C++. The translator looks or say, the (%) mark as the trailing Ident. Then in the conversion process it converts that always to a trailing (_int) convention. The
(&) becomes (_lng), for example.

After that, getting the translator to be able to figure out the nuances of what
to do with (_str) data, etc., is *MUCH* easier, if you call printf any substitute for PRINT USING .... wry grin..

Sometimes I still think that MALLOC is the inverse of MALLOX ... ;)


Mike @ 117/3001

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

Yes, Mark .

... even if only to assign a single value to
be able to case or switch with... however, doing that
if/then/else tree once and then using the single value
every else is much better than using if/then/else
everywhere that you need to branch based on that
selection...

Wincing .. "The devil you know is better than the devil you don't?"


Mike @ 117/3001



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

Fred ..

If I may ask... do your "alpha conditionals" test for bit patterns?
If so, might you rewrite them using numeric values of those bit
patterns?

In two programs they do in the suite, but not everywhere. To save space I used
bit/pattern performance matrix conditionals in the contest logging software for
telecommunications stuff in the ham radio junk. Pattern matching branches the operations logic for the program in real-time for the operator in the deal. Yet storing the full network site's performance hit status in the site server log took a pitance of space. However, that tiny fragment of the stuff isn't the only place logic jump decision was attempted in CASE SELECT. There are other uses for it in pattern matching, I guess you could call it semi-fuzzy-logic uses elsewhere.

To proof the speed and get a real handle on what the network could and couldn't
do a long time ago, I merged all the professional accounting, case modules, inventory control and database stuff for the full office suite in together with
the ham radio contest logging stuff! I figured if I could put it up for, say example, a site networked instance for Field Day, in real-time, with each operator's position hammering the entire professional suite as if it were the business acquitition terminal, but capturing each business template on the network in split-second real-time, and it didn't smash all to Hades, it sure wouldn't smash in a real disaster load either!

It didn't. It doesn't.

I can tell you that DOS-VDM's in OS/2 are SUPERB at all this, including "alpah conditional" testing in near-real time!


Mike @ 117/3001



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

Yes, Mark .

... even if only to assign a single value to
be able to case or switch with... however, doing that
if/then/else tree once and then using the single value
every else is much better than using if/then/else
everywhere that you need to branch based on that
selection...

Wincing .. "The devil you know is better than the devil you
don't?"

hehehe... i know that feeling...

one of the things i was thinking about while writting the above was 'program efficiency'... in some situations this can be important...

if switch case is faster then if/then/else, then 'converting' to single value for that purpose once is a necessary evil until such time as one gets the chance to rework that section...

thinking about situations where the switch case stuff may possibly be executed hundreds of times a second vs if/then/else trees running hundreds of times a second...

== example ==
red == 1;
blue == 2;
yellow == 3;

procedure routine1;
{
input "what's your color?",color$;
if color$ = "red" then color == red
else if
color$ = "blue" then color == blue
else if
color$ = "yellow" then color == yellow;
}

procedure routine2;
{
case color of
red : do_red_routine;
blue : do_blue_routine;
yellow : do_yellow_routine;
}

procedure routine3;
{
case color of
red : do_red_routine2;
blue : do_blue_routine2;
yellow : do_yellow_routine2;
}

{
routine1;
while 1==1 do
{
routine2;
routine3;
}
}
== end of example ==

)\/(ark


* Origin: (1:3634/12)

Yur are precisely correct Mark

one of the things i was thinking about while writting the above was 'program efficiency'... in some situations this can be
important...

if switch case is faster then if/then/else, then
'converting' to single value for that purpose once is
a necessary evil until such time as one gets the
chance to rework that section...

thinking about situations where the switch case stuff
may possibly be executed hundreds of times a second vs
if/then/else trees running hundreds of times a
second...

== example ==
red == 1;
blue == 2;
yellow == 3;

procedure routine1;
{
input "what's your color?",color$;
if color$ = "red" then color == red
else if
color$ = "blue" then color == blue
else if
color$ = "yellow" then color == yellow;
}

procedure routine2;
{
case color of
red : do_red_routine;
blue : do_blue_routine;
yellow : do_yellow_routine;
}

procedure routine3;
{
case color of
red : do_red_routine2;
blue : do_blue_routine2;
yellow : do_yellow_routine2;
}

{
routine1;
while 1==1 do
{
routine2;
routine3;
}
}
== end of example ==

Plus the worst of the Weevil's is that INSTR routines in BASIC, as most recently written are terribly fast from the way the assembler is coded that the
modern compilers use!

As well, if, as in my case, go-no/go decisions are expected in real-time to literally half-second do-it or don't-do-it decisions, you are comparing COMM port I/O in real time against networked stored data from the hard disk,record lock withstanding, in the middle of it all!

What really makes it so intriquing to work with this stuff in OS/2, even in DOS-VDM's, is that the absolutely superb disk caching and HPFS file system begins to make what you are illustrating absolutely crucial in determining a fair shot at system-wide response time optimization!

There is this superb joke about the two boll weevils! The 40# boll weevil eats
twice as much cotton as the 20# boll weevil! Therefore, when you kill each with a double barrel 12 gauge, you fall on your knees and say, "Thank you Lord,
for teaching me the lesser of two weevils! I've got seed left!"

Not with OS/2. There is this voice from above that booms, "Sorry, your cotton was already gone by the time you got that Ithica! Next time get down your Browning! Make love, not war!"


Chuckle.


Mike @ 117/3001

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

Hello Mark,

In some situations, calling routines via one pointer variable might be faster and/or more efficient instead of switch/case statements or if/then statements coupled with calls to those routines coded separately.

Only Mike can see if one way or another way is 'better'.


Greetings -=Eddy=-

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

... * <- Tribble <- Stealth Tribble
--- GoldED/2 3.0.1
* Origin: I drive OS/2 because I'm sick of being a crash dummy! (2:280/5143.7)

But .. that doesn't help much where the comparator was X$, for example and is a variable length string. I was a bad boy at an earlier time in life an I'm not much better now. Basicly, I'm still trying to digest what I ate wh was a younger programmer. Gloom.

Correct you are. What I did is:

Loop

if (stricmp(string1 == "case1"))
{
whatever;
break;
}

if (stricmp(string1 == "case2"))
{
whatever;
break;
}

while (1==1);



C. Gaefke
cdgaefke@bellatlantic.net


... Have your dreams come true?

--- Renegade vY2Ka2
* Origin: LOTL/2 * home.earthlink.net/~cdgaefke * USA (1:129/230)