Asp Forum - preprocessor question

David Resnick

12/1/2008 3:17:00 PM

Given this code fragment:

#define IFV(func, number) incomingFunctVal<CVxicBridgedXferIncomingAction> val##number
( number, &CVxicBridgedXferIncomingAction::func); m_transFnMap.insert(fnMap::value_type(#func, val##number));

IFV( DoJoin, 1 );
IFV( DoJoinRestartReco, 2 );
IFV( DummyAction, 3 );
IFV( RestartReco, 4 );
....
IFV( SomeFunc, 100 );

I'm wondering if there is a way to have the numbers in the function
macro increment automatically?
The code in the macro isn't really subject to change (it is the way to
use a state machine
implementation that I can't modify). I'm just finding it to be a
maintenance pain when
I want to delete a function with a middle number. I've been swapping
the last
function into the place of the deleted one to avoid renumbering the
rest, which is
OK in that order doesn't matter, but is there a better way? The fact
that ## is
used to glue the number into an identifier makes me doubt that this
can be repaired,
but I'd be very happy to be proved wrong.

Thanks!

-David

4 Answers

AnonMail2005@gmail.com

12/1/2008 3:44:00 PM

On Dec 1, 10:16 am, David Resnick <lndresn...@gmail.com> wrote:
> Given this code fragment:
>
> #define IFV(func, number) > incomingFunctVal<CVxicBridgedXferIncomingAction> val##number
> ( > number, &CVxicBridgedXferIncomingAction::func); > m_transFnMap.insert(fnMap::value_type(#func, val##number));
>
> IFV( DoJoin, 1 );
> IFV( DoJoinRestartReco, 2 );
> IFV( DummyAction, 3 );
> IFV( RestartReco, 4 );
> ....
> IFV( SomeFunc, 100 );
>
> I'm wondering if there is a way to have the numbers in the function
> macro increment automatically?
> The code in the macro isn't really subject to change (it is the way to
> use a state machine
> implementation that I can't modify). I'm just finding it to be a
> maintenance pain when
> I want to delete a function with a middle number. I've been swapping
> the last
> function into the place of the deleted one to avoid renumbering the
> rest, which is
> OK in that order doesn't matter, but is there a better way? The fact
> that ## is
> used to glue the number into an identifier makes me doubt that this
> can be repaired,
> but I'd be very happy to be proved wrong.
>
> Thanks!
>
> -David

First cut, create a function called IFV2 (for instance), with a static
counter variable that you increment. The call to IFV and the counter
would be within the function scope.

Just because someone creates crazy preprocessor programming doesn't
mean you can't isolate it and use real programming solution to
minimize it's impact.

HTH

Maxim Yegorushkin

12/1/2008 4:34:00 PM

On Dec 1, 3:16 pm, David Resnick <lndresn...@gmail.com> wrote:
> Given this code fragment:
>
> #define IFV(func, number) > incomingFunctVal<CVxicBridgedXferIncomingAction> val##number
> ( > number, &CVxicBridgedXferIncomingAction::func); > m_transFnMap.insert(fnMap::value_type(#func, val##number));
>
> IFV( DoJoin, 1 );
> IFV( DoJoinRestartReco, 2 );
> IFV( DummyAction, 3 );
> IFV( RestartReco, 4 );
> ....
> IFV( SomeFunc, 100 );
>
> I'm wondering if there is a way to have the numbers in the function
> macro increment automatically?

You could use __COUNTER__ macro. If it is supported by your compiler.

Otherwise, draw inspiration from boost preprocessor library:
http://www.boost.org/doc/libs/1_37_0/libs/preprocessor/doc/ref/co...

> The code in the macro isn't really subject to change (it is the way to
> use a state machine
> implementation that I can't modify).

That's too bad, since such an interface is real pain.

I wonder why incomingFunctVal<> constructor needs that integer? If it
can be auto-generated (possibly in incomingFunctVal<> constructor) by
incrementing a global or class static variable, and if you don't
really need valN objects (their copies are stored in m_transFnMap
anyway) the macro could be simplified to:

typedef CVxicBridgedXferIncomingAction X; // for brevity
int x = 0; // the global counter

#define IFV(func) m_transFnMap.insert( fnMap::value_type( #func , incomingFunctVal<X>(++x, &X::func) ) );

--
Max

David Resnick

12/1/2008 7:07:00 PM

On Dec 1, 11:34 am, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
> On Dec 1, 3:16 pm, David Resnick <lndresn...@gmail.com> wrote:
>
>
>
> > Given this code fragment:
>
> > #define IFV(func, number) > > incomingFunctVal<CVxicBridgedXferIncomingAction> val##number
> > ( > > number, &CVxicBridgedXferIncomingAction::func); > > m_transFnMap.insert(fnMap::value_type(#func, val##number));
>
> > IFV( DoJoin, 1 );
> > IFV( DoJoinRestartReco, 2 );
> > IFV( DummyAction, 3 );
> > IFV( RestartReco, 4 );
> > ....
> > IFV( SomeFunc, 100 );
>
> > I'm wondering if there is a way to have the numbers in the function
> > macro increment automatically?
>
> You could use __COUNTER__ macro. If it is supported by your compiler.
>
> Otherwise, draw inspiration from boost preprocessor library:http://www.boost.org/doc/libs/1_37_0/libs/preprocessor/doc/......
>
> > The code in the macro isn't really subject to change (it is the way to
> > use a state machine
> > implementation that I can't modify).
>
> That's too bad, since such an interface is real pain.
>
> I wonder why incomingFunctVal<> constructor needs that integer? If it
> can be auto-generated (possibly in incomingFunctVal<> constructor) by
> incrementing a global or class static variable, and if you don't
> really need valN objects (their copies are stored in m_transFnMap
> anyway) the macro could be simplified to:
>
> typedef CVxicBridgedXferIncomingAction X; // for brevity
> int x = 0; // the global counter
>
> #define IFV(func) > m_transFnMap.insert( > fnMap::value_type( > #func > , incomingFunctVal<X>(++x, &X::func) > ) > );
>
> --
> Max

That is a very helpful suggestion, thanks. The use of the integer in
the original macro (at least the ## version) was apparently just to
avoid re-declaring identifiers in the same scope, which is fixed by
your macro.

-David

Hendrik Schober

12/1/2008 8:58:00 PM

David Resnick wrote:
> [...] The use of the integer in
> the original macro (at least the ## version) was apparently just to
> avoid re-declaring identifiers in the same scope, which is fixed by
> your macro.

If this is so, and if this is just one file this appears in, you
could use the '__LINE__' macro. But Maxim's suggestion seems better.

> -David

Schobi

comp.lang.c++

preprocessor question

David Resnick

AnonMail2005@gmail.com

Maxim Yegorushkin

David Resnick

Hendrik Schober

x Login to ForumsZone