I have a project written en c++ in which i use tesseract and opencv libraries.
the project contain one function which return an Int ant it has as parameter sting an int
int image_blanche(string nom_img,double k);
My question how can i convert it to dll file to use it in an other .net project
Add a header file (e.g. "Defines.h") containing:
#pragma once
#ifdef COREDLL_EXPORTS
#define COREDLL_API __declspec(dllexport)
#else
#define COREDLL_API __declspec(dllimport)
#endif
Your function should then be defined in a header like this:
#include "Defines.h"
extern "C"
{
COREDLL_API int image_blanche(char const* nom_img,double k);
};
...and implemented in a source file.
Compile that Project with COREDLL_EXPORTS defined as a DLL Project and use the dll in another project.
When building the DLL having COREDLL_EXPORTS defined you basically produce (=export) the symbols and place them in the DLL. When using the DLL in another project not having COREDLL_EXPORTS defined, you consuming/reading (=import) the symbols from the DLL.
Here is a good explanation of how you can then invoke the function from the DLL: Dynamic Invoke C++ DLL function in C#
Update: As MSalters correctly pointed out, using C-Style datatypes should be considered, as it plays friendly across DLL bounds. I changed the string parameter to use a character array instead.
Related
I had a question about DLL building / linking in Visual Studio 2005 and later. Basically my understanding and experience is this:
To build a DLL, I specify the project properties to build a DLL, and then I but __declspec(dllexport) in front of any functions or members that I want to publically expose from the DLL. Building the project will result in a DLL, a Lib, and a header file that can be deployed as say an API or something.
On the other end, to have your other compiled executable application dynamically link to the DLL and use its functions, you simply need to have your executable project include the header files and link with the small lib file that was created when the DLL was built. As long and the compiled application can find the DLL, everything will work.
That has been my experience and that is also how the Microsoft DLL building tutorial described everything on MSDN. I am wondering: is this standard practice? When would you ever need to use __declspec(dllimport) anywhere? Am I missing something?
Thanks!
Yes you would use __declspec(dllimport) and you generally have a macro that controls whether a source file either exports (if it's part of your DLL) or imports (if it's part of the using-executable) symbols.
In your DLL you can set a manifest constant to the build settings of some sort, say 'BUILDING_MY_DLL' and then create the macro like this within your header file:
#ifdef BUILDING_MY_DLL
#define MY_DLL_EXPORT __declspec(dllexport)
#else
#define MY_DLL_EXPORT __declspec(dllimport)
#endif
and then decorate your exported functions like this:
MY_DLL_EXPORT int func(int y);
You can also export entire classes this way too:
class MY_DLL_EXPORT InterestingClass
{
...
};
I had a question about DLL building / linking in Visual Studio 2005 and later. Basically my understanding and experience is this:
To build a DLL, I specify the project properties to build a DLL, and then I but __declspec(dllexport) in front of any functions or members that I want to publically expose from the DLL. Building the project will result in a DLL, a Lib, and a header file that can be deployed as say an API or something.
On the other end, to have your other compiled executable application dynamically link to the DLL and use its functions, you simply need to have your executable project include the header files and link with the small lib file that was created when the DLL was built. As long and the compiled application can find the DLL, everything will work.
That has been my experience and that is also how the Microsoft DLL building tutorial described everything on MSDN. I am wondering: is this standard practice? When would you ever need to use __declspec(dllimport) anywhere? Am I missing something?
Thanks!
Yes you would use __declspec(dllimport) and you generally have a macro that controls whether a source file either exports (if it's part of your DLL) or imports (if it's part of the using-executable) symbols.
In your DLL you can set a manifest constant to the build settings of some sort, say 'BUILDING_MY_DLL' and then create the macro like this within your header file:
#ifdef BUILDING_MY_DLL
#define MY_DLL_EXPORT __declspec(dllexport)
#else
#define MY_DLL_EXPORT __declspec(dllimport)
#endif
and then decorate your exported functions like this:
MY_DLL_EXPORT int func(int y);
You can also export entire classes this way too:
class MY_DLL_EXPORT InterestingClass
{
...
};
I am trying to create a DLL from C++ code using visual studio 2015.
I have a DLL_Tutorial.h file :
#ifndef _DLL_TUTORIAL_H_
#define _DLL_TUTORIAL_H_
#include <iostream>
extern "C"
{
DECLDIR int Add( int a, int b );
}
#endif
\\
\ Then I created a DLL_Tutorial.cpp
#include <iostream>
#include "DLL_Tutorial.h"
#define DLL_EXPORT
extern "C"
{
__declspec(dllexport) int Add(int a, int b)
{
return(a + b);
}
}
I got a Dll file
I would like to call my function in VBA and apply that to an excel sheet
so in VBA I did :
Public Declare Function Add _
Lib "C:\Users\hasna\Desktop\Projet VBA-C++\projet5\Debug\projet5.dll" (byval a As integer,byval b As integer) As integer
Then in an excel sheet, I enter 2 values (for example 6 and 4 ) I call add function but it gave me : #VALEUR!
Where is the problem ?
Could you please help me resolve that
Thanks
In your DLL header file, it does not appear that you've prefixed the exported API with __declspec(dllexport). Which is usually defined so that the API can use __declspec(dllexport) when building the DLL, and __declspec(dllimport), when the header is being used in an external project. The best thing would be to just create the DLL using the VS 2015 project template, it includes the correct headers, and export definitions for you, so you just need to focus on writing the APIs. Here's a working example from a VS 2015 project:
Example *.h:
#pragma once
// The following ifdef block is the standard way of creating macros which make exporting
// from a DLL simpler. All files within this DLL are compiled with the DLLAPI_EXPORTS
// symbol defined on the command line. This symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see
// DLLAPI_API functions as being imported from a DLL, whereas this DLL sees symbols
// defined with this macro as being exported.
#ifdef DLLAPI_EXPORTS
#define DLLAPI_API __declspec(dllexport)
#else
#define DLLAPI_API __declspec(dllimport)
#endif
// This is an example of an exported function.
DLLAPI_API int fnDLLAPI(void);
Example *.cpp:
// DLLAPI.cpp : Defines the exported functions for the DLL application.
//
#include "DLLAPI.h"
// This is an example of an exported function.
DLLAPI_API int fnDLLAPI(void)
{
return 42;
}
The Windows Via C/C++ book is also a very good resource regarding writing DLLs. Now regarding the VB import, I am not sure as I am not familiar with importing APIs via VB.
I created by the first time a dll to use with C++ (and then C#, I have plans to share this dll between a C++ and C# applications) using QT creator but when I try to use it I get SEGFAULT error.
Here's my files:
mydll.h
#ifndef MYDLL_H
#define MYDLL_H
#include "mydll_global.h"
class MYDLLSHARED_EXPORT MyDll
{
public:
MyDll();
int getAnswer();
};
MYDLLSHARED_EXPORT int getNumber();
#endif // MYDLL_H
mydll_global.h
#ifndef MYDLL_GLOBAL_H
#define MYDLL_GLOBAL_H
#include <QtCore/qglobal.h>
#if defined(MYDLL_LIBRARY)
# define MYDLLSHARED_EXPORT Q_DECL_EXPORT
#else
# define MYDLLSHARED_EXPORT Q_DECL_IMPORT
#endif
#endif // MYDLL_GLOBAL_H
mydll.cpp
#include "mydll.h"
MyDll::MyDll()
{
}
int MyDll::getAnswer()
{
return 42;
}
int getNumber()
{
return 10;
}
So I build it and created mydll.dll: then I went to other C++ project wheere I want to use this dll and put in the .pro file:
LIBS += "C:\path\to\mydll.h"
and in the main.cpp
#include "mydll.h"
and when I use function from dll like this:
qDebug() << getNumber();
I get a SEGFAULT error.
I thought that the header to provide the compiler type information and the dll to compiler to provide the function body was all I needed but as I'm getting a SEGFAULT I'm acessing NULL or someone else memory or so (I can't see the value on debug).
What am I missing?
First off, to link the DLL you need the link .lib file for that DLL. That file has all the binary manifest for linking.
Second, project file LIBS clause specify the list of .lib files to link with. Some of them may represent dynamic libraries (.dll).
See the example: Linking to Shared Library in Qt
Even better article covering both creation of DLL with Qt and using DLL in your Qt project: https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
I had this same issue. Almost every example I looked at had a class as their example, but I wanted to export functions like getNumber(). It's in the qt5 docs as you probably know by now.
This line needs to be in your header file:
extern "C" MYDLLSHARED_EXPORT int getNumber();
and it is either the mydll_global.h or mydll.h depending on what you are using.
mydll_global.h would be what qtcreator creates and puts export definitions in if you create a new Shared Library project.
I was thrown off guard by the extern "C" part as I wasn't using C and wasn't as familiar with how compilers export symbols.
Trying to add a public static function to a class definition using static MYDLLSHARED_EXPORT int getNumber(); or simply using a namespace (function defined with or without static) will give a not found for architecture x86_64 error using clang on osx.
I currently have a console application written in unmanaged C++, the source code consists of an entry-point main and some other functions. I need to create a DLL from this code so that I can use it from other projects, specifically from managed C++. (Another question: would I have to write a wrapper class for this purpose?)
As I know next to nothing of managed/unmanaged C++ and creating DLLs, I followed this tutorial and managed to get a simple Hello World DLL up and running by using only VS2010 (no CMake).
However, this project of mine has a lot of dependencies (e.g. Point Cloud Library), and so I normally use CMake to generate the Visual Studio 2010 solution that then builds into an executable, as described in the PCL Tutorial. How can I use CMake to build a VS2010 project that will build into a DLL?
To summarise my problem:
I have a project of unmanaged C++ code that needs a lot of dependencies.
I want to create a DLL from this code that can be called from managed C++.
Extra information:
Windows 7, Visual Studio 2010 Ultimate, CMake 2.8.10.2
EDIT:
I used CMake with your line changed, and it worked as expected. This is what I have since added to my header file, am I on the right track?
MyCode.h
#ifdef MyLib_EXPORTS
#define API_DECL __declspec( dllexport )
#else
#define API_DECL __declspec( dllimport )
#include <iostream>
#include <pcl/...>
etc...
API_DECL void myFirstFunction();
API_DECL void mySecondFunction();
#endif
MyCode.cpp: I have not made any changes to the source file, should I make any?
Unfortunately, I cannot help you with the managed code part, but this is how you create a DLL in CMake:
First of all, instead of using
`ADD_EXECUTABLE( YourLib SHARED yourclass.cpp yourclass.h )`
in your CMakeLists.txt, use
`ADD_LIBRARY( YourLib SHARED yourclass.cpp yourclass.h )`
This will configure the solution to create a DLL rather than an executable.
However, to be able to use this DLL with your projects, you need to export the symbols you want to use. To do this, you need to add __declspec( dllexport ) to your class and/or function declarations. Building the library will then yield two files, a .dll and a .lib. The latter one is the so-called import library that you need when you want to use this library in your other projects. The .dll will be required at runtime.
However: When you want to use your library, you need to use __declspec( dllimport) (rather than dllexport). To avoid using two header files, the usual way to do this is to use the preprocessor. CMake actually helps you by providing a YourLibrary_EXPORTS define in your library project.
To summarize:
#ifndef YOUR_CLASS_H
#define YOUR_CLASS_H
#ifdef YourLib_EXPORTS
#define API_DECL __declspec( dllexport )
#else
#define API_DECL __declspec( dllimport )
#endif
class APIDECL YourClass {
void foo();
void bar();
};
#endif // YOUR_CLASS_H
EDIT:
If you want to be able to use those functions from C (and languages that are able to use C functions) you should wrap your declarations with extern "C" {
extern "C" {
API_DECL void myFirstFunction();
API_DECL void mySecondFunction();
}