My project is a static library and has a common .h file that will be used by both C and C++ versions, using the _cplusplus definition for correct section including.
I´m using VS2012 and when I set my project to use plain C language on Project->Properties->C/C++->Advanced->Compile As->Compile As C Code (/TC), intellisense still thinks I´m using C++ as the main language,
It gives me warnings on some C functions (like strcpy_s) and does not highlight sections defined by the #ifndef _cplusplus commands.
If I try to build or compile (F7) it works perfectly and it is compiled as a C project.
How can I tell intellisense to interpret the code as C language instead of C++ ?
Help appreciated...
Related
I have built Xerces-c_3_1.dll from source using the Visual Studio solution provided in the download package. It works with the sample applications that are part of that package (as long as they're built with VS).
But I need to use the DLL with apps developed in C++ Builder 10 Seattle. The incompatible linkage and COFF-vs-OMF format issues (import lib) mean I need to tweak the build instructions. I believe I need to change the calling convention in the project properties from __cdecl to __stdcall, and add a DEF file to translate the exported functions for my environment.
(I believe this because I wrote and support a DLL that is used by programmers writing in many languages. I do my development in C++ Builder [familiarity with the environment], and create the release version in VS Express 2015 [massive performance improvement over Embarcadero, I'm sorry to say]. Added a DEF file for just the 32-bit version [not needed for VC++ 64-bit, just to make me nuts], and it works for everybody.)
Running TDUMP.exe on my DLL gets me output that looks like this:
EXPORT ord:0060='Edit_RunEdits'
Running tdump -ee xerces-c_3_1.dll >tdump.txt on the Xerces-c_3_1.dll built using __cdecl gets output like this:
EXPORT ord:1763='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
EXPORT ord:1764='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
Running impdef def.txt xerces-c_3_1.dll on the __cdecl build gets output like this:
?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z #1763; ?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z
Repeating TDUMP and IMPDEF on the __stdcall build gets similar results.
And this is expected.
But how can I create a DEF file from this noise? I would be perfectly happy with a sample of the format to use to turn "Initialize#XMLPlatformUtils" into something the linker can match to "XMLPlatformUtils::Initialize()" in my client app.
By the way, I also used IMPLIB on both versions (__cdecl and __stdcall) to create an import library, which I added to my test project, but the linker continues to issue "unresolved external" errors for my calls to XMLPlatformUtils::Initialize and XMLPlatformUtils::Terminate. I believe that should be expected because of the name mangling.
I am writing a managed DLL in VC2010 (i.e. /CLR is enabled for a VC++ DLL project). Following code wouldn't compile:
System::Collections::Generic::List<int>^ my_list;
for each(auto elem in my_list)
{
}
It raises error C3539: 'auto': a template-argument cannot be a type that contains 'auto'.
I don't understand the reason. I tried compiling the same in VS2012, and it raises same error (which is not appropriate error).
Why compiler fails to deduce the type for a colleciton? The same type of code would work in C# with var keyword.
First, the most importand point from the comments:
presented code does compile in VS2013 c++/cli dll .net 4.5 (Zee, 2014-05-03)
When you compile C++/CLI, which is the .NET binding for C++, you are using a different feature set of the Microsoft compiler. Whether something works either
when /clr is in effect
or, additionally, when you're using a "managed" construct (as in your code)
has nothing to to with if the "normal", native, MSVC compiler accepts it.
So as for "why": It would simply appear that auto type deduction did not work for the managed handle types in VS2010 and VS2012, but, according to Zee's comment, has then been implemented in VS2013. (A quick Search Engine check didn't find any official statement wrt. this, so I may be wrong.)
My solution contains several c# projects.
It's easy to add "refernce" from one project to another(References-Add Reference-Project). After that I can use classes from referenced project.
How can I do the same for native c++ projects? What kind of projects should I create? Console application/DLL/Static library?
There are two things in C / C++ :
Headers file, that will tell your program what they can use (e.g. class, function prototype declaration)
Implementation, either as a
source code that you recompile with your program
static lib (.lib on windows)
dynamic lib (.dll on windows)
You need both to compile your program with parts from another project.
If you only need a class from a big library and you have the source of this library it may be easier to reference the file corresponding to this class (and its dependencies of course). But if you need more, you should add the other project's directory to the include path of your current project in VCC, and link against the library (either static or dynamic, according to your needs).
I am trying to create a dynamic library of the Armadillo linear algebra library, which is originally a header-only library, using VC++ 2010 on Win XP. I created a new project, added the source files, and created a .def file specifying to export only one Armadillo function (the Col class), and I get the LNK2001 error for the Col class. I can create a main and use Col just fine, so I think Col is being included correctly.
I have also tried using "__declspec(dllexport)" on the function definition and it compiles, but the function is not exported since using dumpbin shows nothing, and I can not use the .dll sucessfully. Am I missing something here?
As Armadillo is a C++ template library that uses expression templates, I don't think it's possible to create a DLL out of it.
The expression templates are executed (run) at compile-time by the C++ compiler, whenever compiling code that uses Armadillo classes. Whenever a C++ library uses expression templates (part of template metaprogramming), the library can be thought of as an extension to the C++ compiler.
All the Armadillo code is in headers. As such, even if you managed to export one of the classes (eg. the Col class), none of the associated mathematical machinery (eg. addition, multiplication, etc) would be exported, which is defined all throughout the other parts of the library.
I have pdflib_py.so library i want to call from haskell. I do not have a header file. And as you can see the lib's name is not in the standard libbla form.
How do i access it from haskell ?
I followed c2hs tutorial. But it requires a header file (which i do not have) and ghc requires a library name to be in libbla format. I could of course rename pdflib_py.so to libpdfpy.so, in fact i tried it (it did not work), but that's silly to assume that you cannot access a library from haskell because of its name. I'm surely missing something here.
You can download the pdflib library from here http://www.pdflib.com/download/pdflib-family/pdflib-8/
They have bundles for c++, java, php, python etc.
Why don't i use c++ library but a python one ? Well, c++ library libbpdf.a requires to be compiled with g++. And haskell does not work with g++, I would have to write a C wrapper first. Luckily someone already did it for me. That's what a pdflib_py.so is - a c wrapper over libpdf library.
So, how do i use a library with non standard name and no header file from haskell ?
I dont think your approach is correct. You should compile pdflib with g++ into a shared library and then link against it. The C++ library they provide already uses "extern C" wrapper so the symbols exported will be excatly as you would expect them to be.
To sum up, I propose the following solution:
Download C++ bundle
Compile with g++ to make shared .so library
Use header .h file from bundle to make Haskell bindings
Link Haskell code against .so library