How to deal with OTK 'optional' conflicting with C++11 std::optional

[FV]

Hi all,

OTK defines 'optional' in ciptype.h with the simple '#define optional' statement. Why anybody would use preprocessor definitions in C++ API made for public consumption is beyond comprehension...

Anything based on std::optional (or boost::optional) causes compilation errors.  The only way I had figured out how to deal with it was to use dependency injection design pattern. This approach is extremely inefficient in terms of writing code or maintaining it. What it boils down to is:

//wrapper.hxx

//wrapper.cxx includes service.hxx - thus avoids polluting wrapper.hxx with std::optional

class Service; //forward

class Wrapper

{

Service service;

Wrapper();

}

//service.hxx and service.cxx

class Service

{

std::optional some_value;

}

//client.cxx

#include <wrapper.hxx>

class OTK_Client

{

Wrapper *proxy;

OTK_Client() { proxy = new Wrapper();}

}

Does anybody have a better idea how to handle this?

TIA.

Feliks.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[MarkStallard]

FV wrote:

OTK defines 'optional' in ciptype.h with the simple '#define optional' statement. Why anybody would use preprocessor definitions in C++ API made for public consumption is beyond comprehension...

Anything based on std::optional (or boost::optional) causes compilation errors

Hi Feliks -

I, too, have been burned by '#define optional' in OTK C++. It caused a tangle of compiler errors with Boost Geometry, which depends on boost::optional. I was able to mitigate the issue somewhat by changing the order of my #include statements, but I ultimately resolved the problem by removing most of the OTK C++ code from that project. This problem will only get worse when std::optional is officially incorporated as expected in the C++17 standard.

I believe that the OTK C++ library overuses C preprocessor macros. The try/xcatchbegin/xcatch/xcatchend syntax is another example. In the case of '#define optional', it was bad judgement on PTC's part to use a common English word, in all lowercase, as the name of a preprocessor macro.  Any good book on C will tell you to name these macros in all uppercase and to use a distinctive naming pattern, like "#define OTKCPP_OPTIONAL ...". Any good book on C++ will tell you to use preprocessor macros only as a last resort.

Back to addressing this problem: Have you tried changing the order of you #include statements? Also, can you use '#undef optional' to mitigate this problem?

|+|  M a r k  |+|

[FV]

Hi all,

Mark,

Changing order of #include statements did not work for me - even if the code compiles with no errors the linker was not happy and refused to produce dll's ...

The 'dependency injection' which I had outlined in the original post is working but it creates quite a lot of code bloat...

My guess is the macro 'optional' is related somehow to using shared code behind OTK and Java OTK API's - most likely the word is mimicking java's  'Class Optional <T>' and somebody (in one's infinite wisdom)  had replaced the uppercase 'O' with lowercase 'o' without giving it too much thought.

Feliks.