Subj : Re: A really stupid Question - how to build a library
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Thu Oct 07 2004 05:12 pm

No, in the case of *message++ (the one post increment in your code 
that is NOT better as a pre increment), the code is correct.  You want 
to increment but use the original value.

Had you wanted pre increment it would have been *++message, increment 
the pointer and then take the value at the new address.  ++*message 
would increment the value at the address contained in the variable.

I am used to doing DOS ISR's on DOS-era machines and not on gigahertz 
machines.  On such machines one must be careful about the amount of 
processing one does during the interrupt.

> ...Unfortunately you can't create different ISRs that are called 
> depending on the argument list ...

ISR's have no argument list controllable by you.

Of course you can have multiple ISR's.  You already are doing 
something like this:

  start
  call getvect and save the original vector
  call setvect to set your ISR as the vector
  run
  at the end
  call setvect to restore the original vector

I do not know anything limiting you from setting a new vector when you 
change modes.  You can have several ISR's and set whatever one you 
wish to have right now.

..  Ed

> D Kat wrote in message
> news:4165847e$1@newsgroups.borland.com...
>
> Things are going well... I'm in the process of changing all the 
> incrementing code to pre rather than post....
> Problem...  I have a pointer to a character array that I'm 
> incrementing ... *message++
>
> what is the proper way to deal with this?  ++(*message) or what? It 
> compiles just fine as ++*message .... but that just seems... not 
> right.
>
> I'm also going back and forth on where to put the actual ISR since 
> that varies and I can see no way to make it do optional operations 
> without putting too much code in it.
>
> For example... Some times we play one buffer out one channel and 
> another out the other (in effect stereo).  Sometimes we play the 
> same data point out of both channels (mono).....  I am already 
> getting clicks once in every great while so I do not want to push it
> ......  Unfortunately you can't create different ISRs that are 
> called depending on the argument list (overloading ?)...  Sorry, 
> thinking outloud to the room.  It has been very helpful coming here.

.