Store vocab macro definitions as enumerator values

[PeterBowman]

Currently, we use #defines:

kinematics-dynamics/libraries/TeoYarp/ICartesianControl.h

Lines 26 to 35 in 1236178

	#define VOCAB_CC_STAT VOCAB4('s','t','a','t') ///< Current state and position
	#define VOCAB_CC_INV VOCAB3('i','n','v') ///< Inverse kinematics
	#define VOCAB_CC_MOVJ VOCAB4('m','o','v','j') ///< Move in joint space, absolute coordinates
	#define VOCAB_CC_RELJ VOCAB4('r','e','l','j') ///< Move in joint space, relative coordinates
	#define VOCAB_CC_MOVL VOCAB4('m','o','v','l') ///< Linear move to target position
	#define VOCAB_CC_MOVV VOCAB4('m','o','v','v') ///< Linear move with given velocity
	#define VOCAB_CC_GCMP VOCAB4('g','c','m','p') ///< Gravity compensation
	#define VOCAB_CC_FORC VOCAB4('f','o','r','c') ///< Force control
	#define VOCAB_CC_STOP VOCAB4('s','t','o','p') ///< Stop control
	#define VOCAB_CC_TOOL VOCAB4('t','o','o','l') ///< Change tool

Enumerations seem like a cleaner way to achieve the same result (per https://github.com/robotology/yarp/blob/aac0dc7/src/libYARP_sig/include/yarp/sig/Image.h#L363-L392):

enum ICartesianControlVocabRpcCommandsEnum
{
    VOCAB_CC_STAT = VOCAB4('s','t','a','t'), ///< Current state and position
    VOCAB_CC_INV = VOCAB3('i','n','v'),      ///< Inverse kinematics
    VOCAB_CC_MOVJ = VOCAB4('m','o','v','j'), ///< Move in joint space, absolute coordinates
    VOCAB_CC_RELJ = VOCAB4('r','e','l','j'), ///< Move in joint space, relative coordinates
    VOCAB_CC_MOVL = VOCAB4('m','o','v','l'), ///< Linear move to target position
    VOCAB_CC_MOVV = VOCAB4('m','o','v','v'), ///< Linear move with given velocity
    VOCAB_CC_GCMP = VOCAB4('g','c','m','p'), ///< Gravity compensation
    VOCAB_CC_FORC = VOCAB4('f','o','r','c'), ///< Force control
    VOCAB_CC_STOP = VOCAB4('s','t','o','p'), ///< Stop control
    VOCAB_CC_TOOL = VOCAB4('t','o','o','l')  ///< Change tool
}

Some potential benefits: https://stackoverflow.com/a/11648734.

Note that, in #115 and #121, we want to pass similar vocabs to several new methods of the ICartesianControl interface and represent them as ints. This change would entail using the correct type (e.g. ICartesianControlVocabRpcCommandsEnum in the example above) instead of integer primitives.

[jgvictores]

Interesting.

1. Are we sure we want to specify RPC (might end up in duplicates with streaming commands)?
2. Not my favorite, but just to lay out all the options, yet another way would be via static const int, see this and this.

[PeterBowman]

1. Not sure if I understood this. Could you provide an example?
2. We'd have to deal with the intricacies of the One Definition Rule (those vocabs are defined in a header file). Apart from that, we'd end up adding data to a pure virtual class (SO question - I recall having referenced this somewhere).

[jgvictores]

1. Just thinking if something among the lines of ICartesianControlVocabCommandsEnum::Rpc and ICartesianControlVocabCommandsEnum::Streaming would be interesting vs ugly.
2. Agreed, static const int is definitely not my favorite option.

[PeterBowman]

I didn't notice that switching to enumerations will probably require some changes in the function signatures proposed in #121. Note to self: investigate implicit conversions (unscoped enum to int) per this SO answer, or adapt the signature to these new types.

[PeterBowman]

While working on #121, I committed aeae9df (see also #121 (comment)). Now, we have a mixture of macro definitions and enumerators in ICartesianControl.h. Conversions from int/double to an enumerator type require a static_cast. Function signatures of the newly added getParameter and setParameter methods actually accept a double, but we can pass a variable of enumeration type and the compiler will perform an implicit conversion.

[PeterBowman]

yet another way would be via static const int

Or even constexpr (C++11), see #150 (comment).

[PeterBowman]

Following robotology/yarp#1755, namespace-aware constexpr macros are the new hype.

[PeterBowman]

Re-implemented via yarp::os::createVocab while trying to solve #180. Now we have constexpr int globals in ICartesianControl.h, and enumerations in ICartesianSolver.h. Caveats are described in the comments: using int instead of auto or yarp::conf::vocab32_t because SWIG was complaining.

[PeterBowman]

I think it's OK as the way it is now: global vocabs in ICartesianControl.h, enumerations in ICartesianSolver.h. Moving that in either direction (convert to enumeration or global variable) would break the interfaces. Grouping vocabs as enums for the sake of classification is not a must, we already have that in doxy.