Can a NSIS plugin I made contain C++ classes or can it only be C code?
I am developing a NSIS plugin as a Win32 DLL but I am getting a compile error in my header file at the line where my class is declared.
The compile error is:
error C2061: syntax error : identifier 'MyClass'
The line that causes the compile error is:
class MyClass
Whats going wrong? Am I not allowed classes in a Win32 DLL? I am compiling in MS Visual C++ 2010.
I made this mistake many years ago and spent an hour scratching my head. I was looking round for a compiler option that would select whether code is compiled as C or C++, but there isn't one that you can select in the IDE (though you can control this from the cl command-line using /Tc and /Tp). However, the answer is simple.
If a source file has a .c extensions it's compiled as C. If it has a .cpp extension it's compiled as C++.
Additionally, if you put C++ constructs (such as classes) in a header file and #include them in a C file you'll get the same problem. You can hide the C++ constructs from C using #ifdef __cplusplus.
Related
We have a VS2010 C++ project with No Common Language Runtime Support set in its project properties. Then I see that it has a source file containing some managed code and the properties for this file has "/clr" flag set. So the project does not have a /clr flag but a file inside it has. I am confused as to whether it makes the project a mixed mode one? I can open the output file in ILDisassembler which makes me believe that it indeed is a .NET assembly.
This is entirely normal, a C++/CLI project very commonly contains a mix of native C++ and C++/CLI source code files. The setting in the General setting pages merely sets the default that the compiler will assume. But turning it on for each individual source file is quite valid and common.
Other ways to do this is to keep the native C++ code in a separate library project and link it. Or by turning on MSIL code generation on and off on-the-fly in a single source code file by using #pragma managed.
The linker doesn't have to be told about it, it can tell from the content of the object file. And yes, you will get a mixed-mode .NET assembly. With the C++/CLI bits compiled to MSIL and the native C++ code compiled to machine code.
I have a native c++ dll called native.dll.
I have created a c++/cli project called cliWrapper.dll. In this I have two wrapper classes for some classes in native.dll.
And the compilation for this project works fine.
However, when I try to link cliWrapper.dll with my c++/cli console program, the linker complains that I must compile cliWrapper.dll with the compiler option /clr:safe.
Compiling with such option will generate lots of errors since most of native.dll is not verifiable code.
After googling, I see that linking two .module files requires each is compiled with /clr:safe.
Does that mean it is impossible to make a dll that will allow the user to use the wrapper class to do some stuff? I know I can always put those wrapper classes back into the console project and it will compile without problem but I'm just curious about why Microsoft wants to disable such linking?
In Xcode, I've created a "Cocoa application" project. One of its dependencies is a framework containing C++ code. I renamed AppDelegate.m to AppDelegate.mm and included the framework.
The project fails to compile. The problem is that the C++ header files in the framework are using some symbols that conflict with Objective-C or Cocoa.
The C++ header files are defining functions called verify() and check(), which conflict with /usr/include/AssertMacros.h in the MacOSX10.8 SDK.
The C++ header files contain a variable called NO, which conflicts with the Objective-C macro NO.
A workaround would be to modify the C++ code in the framework to avoid these conflicts. But since it's a large C++ project maintained by another organization, this would take time and would possibly break in future updates of the C++ project.
Is there some way just to tell Clang/Xcode to treat those C++ header files as C++ instead of Objective-C++?
Reading through the /usr/include/AssertMacros.h that comes with Mac OS 10.8, it looks like you could do:
#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
before including AssertMacros.h, which will prevent it from defining macros called verify() and check().
Regarding NO: you could use the preprocessor to rename that variable for you. For example:
#define NO NO_libraryname_renamed
#include <libraryname.hh>
#undef NO
Depending on how the NO variable is used by the library, this might cause problems — if the header is declaring it as extern, then your Cocoa app will refer to it by the wrong name, and you'll get an undefined symbol error. But as long as you're not using that variable, and the library isn't depending on your app to define that variable, then you should be fine.
(And please file a bug report with the offending library, requesting that they rename their variable.)
Mixing several languages is calling for grief. Even more so mixing Objective C++ (itself a strange hybrid) with C++. Don't do it.
I have a project in xcode where I use a c++ library, it use to work and compile correctly, but whithout any change now it won't compile telling some errors in the .h files libraries and in my view controller where I use some c++ variables, I have my file with the .mm extension and all the errors I'm having are about the c++ syntax like in the word namespace it tells it's Unknown type name or in every other line where the syntax is c++ type Xcode can't recognize it.
Found out by my self on this page http://answers.oreilly.com/topic/631-how-to-get-c-and-objective-c-to-play-nicely-in-xcode/
The problem was that the compiler was making a mess because only the files where I used c++ code I put them the .mm extension and there was some files with just .m
By changing the extension of every file in my project to .mm even if it hasn't any c++ code solved the problem.
I'm trying to use a static library created by me in Visual C++ 2005 (unmanaged C++). I declare one function "int myF(int a);" into a .h file, I implement it in a .cpp file, I compile it - the .lib file is produced.
I create a new project (a separate solution) in VC++ 2005 (also native C++), I add the paths for the include file and the lib file; when I invoke the function myF the linker reports an error: "error LNK2019: unresolved external symbol _myF referenced in function _main". if I create the client project in the same solution as the library project and then add a reference to the library projects, it works, but I'm not going to implement everything like this, but rather to add external libraries to my projects...
What is wrong?
Thank you.
You need to also include the actual .lib file in your 2nd project (not just the path to it).
There should be an option in the linker settings to do this.
It is not sufficient to list the folder in which MyStatic.lib can be found. You have to explicitly tell the linker that Dependant.vcproj is using MyStatic.lib.
In VS2005 you do this by project properties->Linker->Input->Additional Dependencies. You can also sprinkle some preprosessor stuff in the .h file to tell the compiler to tell the linker to use MyStatic.lib.
Edit:
The preprocessor magic goes like this
#pragma comment(lib, "MyStatic.lib")
(EDIT: This was a response to the question of getting the /NODEFAULTLIB error in link phase which has now been deleted... shrug)
You are mixing compiler settings if your are getting the defaultlib error. For example, if you build your library in debug and the build your main in release, you will get this error since they are built to use different versions of the CRTL. This can also happen if you use different settings for linking with the C Runtime as a object library or as a DLL. (See the C/C++ options, the "Code Generation" section, under the "Runtime Library" setting)
In many projects there isn't much you can do if you can't correct the settings of the library (for example, 3rd party libraries). In those cases you have to use the /NODEFAULTLIB switch which is a linker option in the "Input" section called "Ignore Specific Library".
But since you are in control of both the main and the library, build a debug and a release version of your LIB file or make sure your "C/C++;Code Generation;Runtime Library" settings match in both projects.
Try setting additional dependencies in the linker input for a project properties.