Best practise for _MSC_VER macro

[vix]

I found a very old thread on this topic but I wonder if the approach is up-to-date since the compiler used by CVI has changed since version 2013.

Which is the best practise to use when compiling with CVI 2017 sources which use Windows SDK files?

Should be _MSC_VER macro defined to some value?

Or should it be left undefined?

I'm interested in a general solution from NI engeneers.

Thanks

[vix]

Could someone from NI side clarify this, please?

[alamanna]

Hi Vix,

in the LabWindows/CVI 2017 Help I found that

LabWindows/CVI does not define _MSC_VER, a macro that is defined by the external compiler. If you import code originally developed under the external compiler to LabWindows/CVI, you might have to manually define the macro.

Does this answer your question?

Regards,

Alessia

[rolfk]

There is no good answer to this question. It really depends on the code you want to compile. It's dependencies and expectations when it sees this macro defined will define what is the best value for it if any. Some software is programmed to do very complicated dependency handling based on such macros, which makes it almost unportable to any other version even of the same compiler that what it was programmed for, and definitely unportable to just about any other compiler. The best compatibility approach is usually to use such macros only to detect if that compiler is used at all, not its exact version. Even better is to avoid such macro check in any code that you intend to make portable, though that is often not completely possible. As less assumptions code makes about such macros as better it usually is.

[vix]

Hello Alessia and rolfk

I know that probably the answer is not easy, and so I try to describe a little bit my scenario.

I'm not porting code originally developed under the external compiler to LabWindows/CVI (as the example case in the LabWindows/CVI 2017 Help).

Often I need to import third party libraries in CVI (OPC UA, JSON, 3D, ...) and it's quite easy find this kind of libraries on github (as an example).

Usually they are heavily tested (with Travis and AppVeyor) with many compilers (MSVC, GCC, LLVM/CLANG) and Operating Systems (MS Windows, Linux) and so the several #ifdef they use in the code are right.

LabWindows/CVI is a litlle bit "uncommon" and "out-of-standard": its compiler is clang-based (but is quite old), it uses Windows Kit (SDK) but without MSVC, ...

I hope you can understand what I mean.

It happens that to compile this code in CVI some modification to the #ifdef is necessary.

Sometimes this is a clear bug in the library: when this happens I open a proper PR on github.

Sometimes this seems more related to CVI architecture and I can't pacth the library by myself at every new release.

I try to express my question in a slightly different way:

is it expected that Windows SDK files can be used in CVI without defining _MSC_VER macro?

[rolfk · Accepted solution]

I understand what you mean but this statement:

@vix wrote:

Usually they are heavily tested (with Travis and AppVeyor) with many compilers (MSVC, GCC, LLVM/CLANG) and Operating Systems (MS Windows, Linux) and so the several #ifdef they use in the code are right.

is mixing up totally unrelated things. The code is right and tested of course, for the compilers it supports. But that says nothing about other compilers and LabWindows/CVI is a different compiler no matter what, even if it does some effort to be compatible with MSC. That means if you get such a library you have to adapt the library itself. If it is a good library you most likely have somewhere a config.h.in file that allows to configure all the relevant things that are compiler specific. If it is a Linux centric library it has instead a make based thing and then you have the interesting task to update the make scripts itself to make it work for your compiler, which in my experience is a hopeless exercise. The make based system is so complex and obscure that you need a special academic degree to be able to adapt the scripts properly to a new compiler. Trying to tweak some precompiler defines to make a library compile with a new compiler is definitely not the right way. You should rather add some configuration settings to the library to match what LabWindows/CVI does require. Cumbersome: yes defintely, but the only real solution.

LabWindows/CVI is a little bit "uncommon" and "out-of-standard": its compiler is clang-based (but is quite old), it uses Windows Kit (SDK) but without MSVC, ...

It traditionally used its own proprietary C compiler with a lot of effort put in to make it both MSVC and Borland C compatible, though only one of them at any time, and the compatibility mode was an installation decision. This of course gave maximum flexibility to do whatever the LabWindows/CVI developers deemed necessary but was an unsustainable development model in the long run, since C compiler development is a highly specialistic and dynamic business. So they switched to a clang backend, most likely also because of licensing issues as you can't really integrate gcc into a closed source project nor do you likely want to as gcc changes continously and often in incompatible ways between versions.

I try to express my question in a slightly different way:

is it expected that Windows SDK files can be used in CVI without defining _MSC_VER macro?

I would think so. But that depends on (most likely wrong) assumptions of a library based on the value of this define.