borland setvect problem

[Lane Kent Anderson]

I am trying to write a com port class to handle serial
communications. My problem comes when I try to setvect() my
interrupt handler (a member function) in my constructor.

Just using: (Borland Turbo C++ (v1.1))
void interrupt Handler() { // Handler is a
// member function
.
.
}

setvect(COM_INT,Handler);
doesn't work. The compiler tells me I must use ::

So I type:
setvect(COM_INT,COMPORT::Handler);

Now I get an error saying setvect arguments don't match types.
Casting it doesn't fix the problem.
So I type:
setvect(COM_INT,&COMPORT::Handler);

This doesn't fix anything (I didn't think it would).

So, my question is: How can I get this stupid thing to work? Is
there a way to force the compiler to accept arguments of
different types (like in C)? This is probably the biggest turn
off for me about C++. If I can get past this, I'll make the
switch.

Thanks in advance for any help.

Kent Anderson
ke...@bert.cs.byu.edu
ke...@fcs.byu.edu

[Dennis Parrott]

Lane Kent Anderson (ke...@bert.cs.byu.edu) wrote:
: I am trying to write a com port class to handle serial

: communications. My problem comes when I try to setvect() my
: interrupt handler (a member function) in my constructor.
:
: Just using: (Borland Turbo C++ (v1.1))
: void interrupt Handler() {// Handler is a
: // member function
: .
: .
: }
:
: setvect(COM_INT,Handler);
: doesn't work. The compiler tells me I must use ::
:
: So I type:
: setvect(COM_INT,COMPORT::Handler);
:
: Now I get an error saying setvect arguments don't match types.
: Casting it doesn't fix the problem.
: So I type:
: setvect(COM_INT,&COMPORT::Handler);
:
: This doesn't fix anything (I didn't think it would).
:
: So, my question is: How can I get this stupid thing to work?

The problem is that as a (non-static) member function, the BIOS is utterly
unable to call the handler. The BIOS *expects* to call a routine that has
a C function signature (which COMPORT::Handler definitely does NOT possess).

Your can get around this by:

1. making Handler a static member function
2. writing a Handler function as a non-member function which dispatches
the interrupt to your COMPORT object/member function

Take note that member functions are not called in the same way that "regular"
C functions are. (does 'this' give you a hint? ;^) - details in a good
C++ book like Lippman, Stroustrup or Eckel...)

: Is there a way to force the compiler to accept arguments of

: different types (like in C)? This is probably the biggest turn
: off for me about C++. If I can get past this, I'll make the
: switch.

As you can now see, this is NOT a problem with the compiler, but really with
what DOS and the BIOS are expecting.

:
: Thanks in advance for any help.

You're welcome.

--------------------------------------------------------------------------------
Dennis M. Parrott | Disclaimer: My opinions, mine. Not Ford's.
par...@ed8200.ped.pto.ford.com |
Ford Motor Company | You can write crummy code in ANY language.
Dearborn, Michigan USA | I know because I've done maintenance on it.

[Stephen Watson]

par...@pt9222.ped.pto.ford.com (Dennis Parrott) writes:

>Lane Kent Anderson (ke...@bert.cs.byu.edu) wrote:
>: I am trying to write a com port class to handle serial
>: communications. My problem comes when I try to setvect() my
>: interrupt handler (a member function) in my constructor.

[...]

>The problem is that as a (non-static) member function, the BIOS is utterly
>unable to call the handler. The BIOS *expects* to call a routine that has
>a C function signature (which COMPORT::Handler definitely does NOT possess).

[...]

>As you can now see, this is NOT a problem with the compiler, but really with
>what DOS and the BIOS are expecting.

At the risk of being pedantic, I should point out that the problem has
*nothing* to do with the operating system as such, but is, in fact, a
"feature" ;-) of the language. The same problem arises when writing
handlers in *any* vendor's C++ under *any* O/S. The run-time problem
in calling a member fn as a handler has to do with the lack of a
'this' pointer. The compiler prevents this from arising by
considering member fns to be of a different type than non-member (or
static member) fns.

I have already e-mailed Mr. Anderson some example code which does what
he wants.
--
| Steve Watson a.k.a. wat...@sce.carleton.ca === Carleton University, Ontario |
| this->opinion = My.opinion; assert (this->opinion != CarletonU.opinion); |
"Everybody loves to see / Justice done
On somebody else" - Bruce Cockburn

[Jamshid Afshar]

In article <kent.76...@bert.cs.byu.edu>,

Lane Kent Anderson <ke...@bert.cs.byu.edu> wrote:
>I am trying to write a com port class to handle serial

>communications. My problem comes when I try to setvect() [which expects
>a regular function pointer] my interrupt handler (a member function)
>in my constructor.
>[...]

Do you access `this' object in your member function? If you do, what
object do you expect your function to use when the interrupt is
called? Since the interrupt handler calls your interrupt function
like a regular C function, there's no way for it to pass a `this'
pointer. If you do not access `this' object inside your member
function, why not make the member function static?

>[...] So, my question is: How can I get this stupid thing to work? Is

>there a way to force the compiler to accept arguments of
>different types (like in C)? This is probably the biggest turn
>off for me about C++. If I can get past this, I'll make the switch.

Refusing to compile code that is theoretically impossible to implement
is a turn off? Anyway, see SECTION 17 of the comp.lang.c++ FAQ (which
you should have read before posting) for a complete explanation and
example solution (rtfm.mit.edu, /pub/usenet/comp.lang.c++). A
solution is also provided in one of Borland's TechFax documents:
TI652.ZIP Interrupt Handlers as Member Functions.

The TechFax documents are all at ftp.borland.com in
/pub/libs/c/ti/c_all.zip. Get /pub/INDEX while you're at it.

Jamshid Afshar
jam...@ses.com