preprocessor question

D

David Resnick

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
 
A

AnonMail2005

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
 
M

Maxim Yegorushkin

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/counter.html
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) \
) \
);
 
D

David Resnick

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


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) \
            ) \
        );

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Preprocessor 4
preprocessor bug? 2
Pythen question 0
Order of preprocessor macro replacement 3
Preprocessor trick? 9
Math python question 10
Preprocessor trick 6
Preprocessor eating backslashes?? 5

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top