BOOL redefinition after including minwindef.h - c++

I am a newbie in C/C++, just in case :)
I have cloned an older protocol stack solution written in C with one main class in C++ imported it into VS
(Visual C++ 2017 v 15.9.5 targeting Windows SDK 10.0.17134.0) it compiled correctly and working.
Now made a C++ solution (windows console application) created a folder lib copy pasted all those .h and .c files into lib added the path to additional include directories and also in linker additional library directories.
Building the Solution throwing tones of errors. the one I am trying to fix now is:
One of the header files contains type definitions
typedef uint8_t U8;
#ifndef BOOL
typedef U8 BOOL;
#endif
but this is conflicting with minwindef.h from windows kit. though I #include types.h getting C2371 'BOOL': redefinition; different basic types
in the whole solution, I want to use this definition of BOOL and all other ones defined in this header.
How should I solve the issue? Or in General in case of using C codes in C++ projects what settings and MACRO (e.g. extern "C" in methods) should I follow

I don't know anything about the library you're trying to work with, because you did not tell us what it is. But I can make some guesses:
The code did not used to interface with Windows code at all;
By creating a Windows C++ application you have added Windows dependencies;
The Windows dependencies (well-known for poisoning the namespace with short names like BOOL) are conflicting with the library's code (which is doing the same thing with its BOOL macro, when defined, and its BOOL type alias, otherwise).
This isn't really to do with C vs C++ or anything like this, and there's no general fix you can make. You can either try to get rid of the Windows dependency (do you need that header for your task?) or you can patch your library not to touch BOOL (after making sure that Windows's BOOL is what you need it to be).
And use this as a good lesson not to pollute namespaces!

Related

Py ILM Base not compiling on windows

I've downloaded the latest copy from Latest Open EXR repo and compiled most everything without any problems. However, when I get to PyILMBase it fails.
There are two distinct issues with my attempts:
Error C2491 'PyImath::FixedArray::name': definition of dllimport function not allowed PyImath (...)\src\pyilmbase-2.2.1\PyImath\PyImath.cpp 41
and an import to unistd.h that kind of gets addressed Here
my question being, has anybody successfully compiled this for windows? It seems odd that I can't find any specific info about that compiling error. Am I missing something in the way that C++ works?
This project makes extensive use of whatever it is that causes the error C2491, so going in and changing it would be a little complicated
IlmBase is compiled as a shared library. A shared library must provide their function declarations in order your program can find them.
It's perform by declaring them as dllimport or dllexport depending on the situation.
__declspec(dllimport): imports the implementation from a DLL so your application can use it.
__declspec(dllexport): tells the linker that you want this object to be made available for other DLL's to import. It is used when creating a DLL that others can link to.
These keywords are generally handled by a single macro. In your case PYIMATH_EXPORT.
These lines are from PyImathTask.h
#if defined(PYIMATH_EXPORTS) // create library
#define PYIMATH_EXPORT __declspec(dllexport)
#else // use library
#define PYIMATH_EXPORT __declspec(dllimport)
#endif
So, because you want to make these functions available from your application, you must add PYIMATH_EXPORTS as a preprocessor definition.
Actually, PyIMath's properties mispells it - they've write it as PyImath_EXPORTS - ...
To fix that, in vs2015, go to the PyImath's properties > Configuration Properties > C/C++ > Preprocessor > Replace PyImath_EXPORTS by PYIMATH_EXPORTS.
It's probably the same thing for PyIex...

Eclipse CDT Include paths, "Tool Chains", cannot find string, cout etc

I am trying to use CDT to edit C++ files. However, it refuses to see the std classes like string and vector.
(I will continue to build with make outside of eclipse, for now at least. The code compiles fine. But without a definition for string etc. almost everything is shown as an error in the editor.)
I am using Luna. CDT added to a Java oriented eclipse using Help > Install New Software.
The docs just say "install the the Tool Chains and stuff happens". But having spent several hours reading up on this, I think the phrase "Tool Chain" has several different meanings depending on the sentence. These include
The compilers and linkers themselves, e.g. minggw
Extra stuff (plugin?) added to Eclipse itself so that it can use those compilers.
Configuration within Eclipse itself
My make file uses
D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include
but sometimes CDT seems to be pointing to
D:\mingw64\include\c++\4.5.4
Which is OK, as it will have the same .h files.
I have tried fiddling with PATH (to /bin), plus the Project Properties > > Environment MINGW_HOME. The "tool chain editor" mentions MingGW and says GCC C++, but I don't know what that really means and the easy-to-use interface does not show the paths.
I also tried adding D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include to the Paths & Symbols > Include, but that does not help.
There is also "Libraries and "Library Paths". I do not know what the difference is (both want paths) but I am guessing this is for linking, not compiling. I am also guessing that the IDE parsing of the C++ during editing is done by CDT itself, and does not rely on external compilers.
A secondary question is how does CDT determine which header files are relevant? In general that is undecidable in C, in my case my header files rely on other header files that are loaded from the containing .cpp files. I am guessing that it just ignores the #include directives and loads up every header file it comes across, hoping that there are no conflicts.
My hack is as follows, after spending too much time trying to fix it properly and no posts here.
#ifdef ECLIPSE
// Dummy declarations to help with misconfigured Eclispse
class string{};
template <typename T>
class vector{
public:
unsigned size();
void push_back(T t);
T at(unsigned idx);
};
#endif
Yes, just trick Eclipse into thinking the classes are OK. I would not call this an answer though.
Strangely the class def of string seems enough to convince eclipse that casts to char * are OK.
(I access these classes with using, so no std::)
If CDT is unable to resolve standard library includes like <string> and <vector>, this is a sign that it cannot find your compiler.
Open a Command Prompt and type g++. Is it found? If not, it means the directory containing your compiler is not in the PATH environment variable. Add this directory (likely something like D:\cygwin64\bin) to PATH (how you do this depends on your Windows version, but it's something like Computer | Properties | Advanced system settings | Environment variables), then restart Eclipse and try again.

How to build the Poco C++ libraries

I'm trying to build the Poco C++ libraries manually on Android, iOS, and windows. After much effort I got them to build on Android, but I'm struggling a bit on Windows.
I've had to manually edit several files already to resolve undefined symbols -- specifically File & Path weren't #included properly by *_WIN32U.cpp versions.
I'm down to what APPEARS to be my last compiler issue for "Foundation". It's this line in Process_WIN32U.cpp:
envChars = getEnvironmentVariablesBuffer(env);
The compiler error generated is:
"getEnvironmentVariablesBuffer identifier not found"
The declaration of "getEnvironmentVariablesBuffer" is in Process.cpp but it's not a member of the root class, there are no EXTERN references anywhere, and no header file contains the function declaration.
So how the heck is "Process_WIN32U.cpp" supposed to be able to see that function?
Thanks!
So how the heck is "Process_WIN32U.cpp" supposed to be able to see that function?
ProcessWIN32U.cpp (i.e. ProcessImpl class) is able to see that function because ProcessWIN32U.cpp is included from Process.cpp and it was not designed or meant to be used standalone - it is excluded from build in POCO Visual Studio solutions.
In order to get ProcessWIN32U.cpp to be included by Process.cpp, one must manually /D_WIN32 which is not defined by Visual Studio (it defines WIN32).

Show an error (in Visual studio), when someone tries to use STL in a current .cpp or .h file

In our company sometimes we write .cpp and .h files, which are used in projects for old WM (we use Embedded Visual C++ 3.0 or something for this) and in more modern code (VS 2010).
This Embedded Visual C++ does not support STL.
So if one of developers, who works in VS2010, changes a file, which is shared, and adds some function, which uses std::vector, for instance, on his side everything will be OK, but the build (which is quite long) will fail.
So to see this mistake sooner, I would like to add something like
#if defined(%%STL%%)
#error("!!!!")
#endif
in all files, which are compiled with old toolset. In this case the developer could see compile time error even in VS2010.
But I could not find what I can put instead %%STL%% there.
Any ideas? Or maybe someone knows a better way how I can do this?
Based on a comment to the question, you could go through each of the header files that aren't supported and see what symbols they define for their include guard. Then check for those symbols being defined.
E.G. The Microsoft C++ header <algorithm> defines _ALGORITHM_ so you can check for that:
#ifdef _ALGORITHM_
#error("<algorithm> included")
#endif
A bunch of these could be collected up and put into a single header file that you could include in each shared source file, at the end.
There is quite a nice solution (at least I do not see pitfalls)
%%STL%% should be _STD_BEGIN
this macro is used for "namespace std {" in VS stl implementation

Second C Linkage in shobjidl.h

I am currently moving a C++ project from VS6 to VS2008, but I have come accross the following error for many of the functions in shobjidl.h
error C2733: second C linkage of overloaded function 'HWND_UserMarshal' not allowed c:\program files\microsoft sdks\windows\v6.0a\include\shobjidl.h 28830
Not just HWND_UserMarshall is affected, also other functions in this header, such as HWND_UserSize, HWND_UserFree and HWND_UserFree64.
I understand that this error occurs when an extern "C" function is declared with a different set of parameters, however this is in a SDK header, not one that I can change.
Does anyone have any suggestions of what my next steps should be?
EDIT: The header is a Microsoft header and at the top contains the following comments
/* this ALWAYS GENERATED file contains the definitions for the interfaces */
/* File created by MIDL compiler version 7.00.0499 */
/* Compiler settings for shobjidl.idl:
Oicf, W1, Zp8, env=Win32 (32b run)
protocol : dce , ms_ext, c_ext, robust
error checks: allocation ref bounds_check enum stub_data
VC __declspec() decoration level:
__declspec(uuid()), __declspec(selectany), __declspec(novtable)
DECLSPEC_UUID(), MIDL_INTERFACE()
*/
//##MIDL_FILE_HEADING( )
Unfortunately, I'm not familiar with this header or these functions. However, I suspect that there are C macros meant to control which functions are visible to you based on preprocessor defines. And I suspect that you somehow have defined (or not defined) preprocessor symbols in a way that you're getting duplicate function definitions.
Not being familiar with the header, I can't really recommend what to do to get just the functions you want. I would probably start by reading the documentation, looking at the configuration for similar products, and reading the header file itself.
Are those headers generated from an IDL file? If so you probably need to re-generated them using a VS2008 compliant tool.
For example if you are using the TAO ORB you would download the latest version (or the 2008 version) and run the tool:
tao_idl -Cw -GT shobjidl.idl
Using appropriate flags and paths.
EDIT: From your update it does seem like you are meant to generate this file. MIDL is the Microsoft IDL compiler. Check the docs on MSDN for info on the compiler: http://msdn.microsoft.com/en-us/library/windows/desktop/aa367300%28v=vs.85%29.aspx