safe_enum vs. OMG IDL to C++11 mapping

5 posts / 0 new
Last post
Offline
Joined: 01/01/2017
Posts: 12
safe_enum vs. OMG IDL to C++11 mapping

In the thread Modern C++ API - safe_enum, Sumant Tambe wrote:

Finally, section 7.12 in the specification requires the use of C++11 enum classes for C++11 compatibility. It appears not be the case in the current version of rtiddsgen. Perhaps the reason is that a static get_default() function is defined in the generated struct type that encapsulates the native enum. C++11 enum class does not have static functions. [...]

Have you brought this to the attention of the IDL to C++11 RTF ?

Perhaps the mapping standard could be improved to cover your additional required functions?


- Oliver

Offline
Joined: 04/02/2013
Posts: 79

Hi Oliver,

We produce this get_default() function to simplify our code-generation process. We don't strictly need it, and we could always move it outside the enum wrapper type (as a standalone namespace function), as suggested in the previous thread.

Alex

Offline
Joined: 01/01/2017
Posts: 12

Hello Alex,

When accessing enum values from safe_enum, the enum type needs to suffixed with "_def".

For example, given the IDL

module mymodule {
   enum myenum { value_0, value_1 };
};

the value_1 would be accessed as mymodule::myenum_def::value_1.

In the OMG C++11 mapping, the suffixing of the type name is not required.

Offline
Joined: 04/02/2013
Posts: 79

You don't need to use the "_def" type, just the safe_enum. For example:

This IDL enum:

enum Color {RED, GREEN, BLUE};

Produces this C++ enum:

struct Color_def {
 enum type {
  RED,
  GREEN,
  BLUE
 };

 static type get_default(){ return RED;}
};

typedef dds::core::safe_enum<Color_def> Color;
 
 

Which you can use like this:

Color c = Color::RED;

 

Note that you use the Color safe_enum, not Color_def

Offline
Joined: 01/01/2017
Posts: 12

Hello Alex,

Note that you use the Color safe_enum, not Color_def

Many thanks. I don't know how I managed to overlook that.

Oliver