VS and OpenCV Configuration principle essentials

One: the principle of configuration

(1) VC + + directory containing directory configuration ( pre-compilation phase )

Contains directories where the directory configuration path includes header files, such as Cv.h, that are included in # include. This doesn't have to be explained much.

(2) VC + + Directory library directory and linker input configuration ( compilation phase )

The path to the library directory configuration is the directory where the. lib file is located, where the. lib you want to configure is the input LIB file in the linker. The Lib file here is of course just index information, and the real function implementation is in the DLL file. This way, when the corresponding DLL file is missing, no errors will be found in the compilation truncation.

(3) Configuration of environment variables ( operational phase )

The environment variable configuration path is the directory where the DLL files are located, so that when the program runs, the appropriate DLL files can be used to locate the corresponding files through the computer's environment variables.

Configuration mainly includes 4 points configuration: Environment variable configuration, VC + + directory contains directory and library directory configuration, linker input configuration, this article takes VS2010 and OpenCV2.4.9 configuration as an example.

<1> Configuration of environment variables

You need to add the following to the environment variable path:D:\Program files\opencv2.4.9\opencv\build\x86\vc10\bin, if vs2013; D:\Program files\ Opencv2.4.9\opencv\build\x86\vc12\bin.

Mainly depends on the path of the OPENCV installation directory, usually choose to install in the D drive, of course, some enterprises will choose to install in the C drive.

<2> Configuration of VS2010

Disposable configuration:

Here a one-time configuration refers to each new project needs to be configured once, so it is not convenient, simply explained below:

In the VS Solution Explorer window, right-click the project

(1) Attribute->vc++ directory, adding paths in the Include directory and the library target, respectively

To add a path in the Include directory:

D:\Program Files\opencv2.4.9\opencv\build\include

D:\Program FILES\OPENCV2.4.9\OPENCV\BUILD\INCLUDE\OPENCV

D:\ProgramFiles\OpenCV2.4.9\opencv\build\include\opencv2

In the library directory, add:

D:\Program Files\opencv2.4.9\opencv\build\x86\vc10\lib

(2) Properties---linker--input, adding in additional dependencies

Opencv_core249d.lib

Opencv_highgui249d.lib

Opencv_video249d.lib

Opencv_ml249d.lib

Opencv_legacy249d.lib

Opencv_imgproc249d.lib

This completes the one-time configuration in debug, where the additional dependencies are changed to

Opencv_core249.lib

Opencv_highgui249.lib

Opencv_video249.lib

Opencv_ml249.lib

Opencv_legacy249.lib

Opencv_imgproc249.lib

Less a D, a one-time configuration to this end, this is only for the case of building a project.

There is usually no need to add so many libraries, and currently I do projects that need to add dependencies for:

In debug

Opencv_core243d.lib

Opencv_highgui243d.lib

Opencv_video243d.lib

Opencv_imgproc243d.lib

In release

Opencv_core249.lib

Opencv_highgui249.lib

Opencv_imgproc249.lib

Opencv_video249.lib

Permanent configuration:

In the Properties Manager window of VS, double-click the item-->debug| Win32-->microsoft.cpp.win32.user. At this point in the VC + + directory and the configuration of the linker and once configured content, the next re-establishment of the OPENCV Project no need to reconfigure.

Here's how LIB is related to DLL files:

Reference: Http://www.cnblogs.com/devilmsg/articles/1266336.html What is a lib file, what is the relationship between Lib and DLL
(1) Lib is required at compile time, DLL is required at runtime.
If you want to complete the compilation of the source code, there is Lib enough.
If you also make a dynamically connected program run, there is enough DLL.
In the development and commissioning phase, of course, it is best to have.
(2) The General Dynamic Library program has lib files and DLL files. Lib files must be connected to the application at compile time, and DLL files are not called until the run time. If there are DLL files, then the corresponding LIB file is generally some index information, specifically implemented in the DLL file. If only the Lib file, then the Lib file is statically compiled, the index and implementation are in it. A statically compiled LIB file has the advantage of not having to hang up the dynamic library when installing to the user. But there are drawbacks, that is, the application is larger, and the flexibility of the dynamic library is lost, and when the version is upgraded, a new application will be published at the same time.
(3) In the case of the dynamic library, there are two files, one is the introduction library (. LIB) file, a DLL file that contains the name and location of the function exported by the DLL, the DLL contains the actual functions and data, the application uses the Lib file to link to the DLL file that is needed, the functions and data in the library are not copied to the executable file, Therefore, in the application's executable file, it is not the called function code, but the memory address of the function to be called in the DLL, so that when one or more applications run, the program code and the called function code are linked together, thus saving memory resources. As you can see from the instructions above, DLLs and. lib files must be released with the application or the application will produce an error.
One, the development and use of DLLs need to pay attention to three kinds of files
1. dll header file
It refers to the. h file that describes the output class or symbol prototype or data structure in a DLL. When other applications call the DLL, the file needs to be included in the application's source file.
2, DLL of the introduction of the library file
It is the file that the DLL generates after compiling and linking successfully. The main effect is that when other applications call the DLL, the file needs to be introduced into the application. Otherwise, the DLL cannot be introduced.
3. dll file (. dll)
It is the actual executable file that the application calls when the DLL runs. DLL files exist after compiling and linking successfully. When a successful development application is published, only the. exe file and the. dll file are required, and there is no need to have. lib files and DLL header files.
A dynamic-link library (DLL) is an executable file that acts as a library of shared functions. Dynamic linking provides a way for a process to invoke a function that is not part of its executable code. The executable code of the function is in a DLL that contains one or more functions that have been compiled, linked, and stored separately from the processes that use them. DLLs also help to share data and resources. Multiple applications can access the contents of a single copy of a DLL in memory at the same time.
Dynamic linking differs from static linking in that dynamic linking allows executable modules (. dll files or. exe files) to contain only the information required to locate the executable code of the DLL function at run time. In a static link, the linker gets all the referenced functions from the static link library and places the library with the code in the executable file.
There are several advantages to using dynamic links instead of static links. DLL saves memory, reduces switching operations, saves disk space, is easier to upgrade, provides after-sales support, provides mechanisms to extend the MFC library classes, supports multi-language programs, and makes the creation of international versions easy.
Lib and DLL files differ most in terms of invocation
DLLs can be statically trapped
LIB and DLL
From this chapter, what I'm telling you will be specific to the Windows platform. In fact, this article can also be seen as a summary of my development experience under Windows, because later I decided to switch to UNIX.
There is a chapter in front of the compilation and link, said very briefly, in fact, should be put together in this chapter. Many single-speaking C + + books are actually too academic school, for the real work environment, hundreds of source files how to combine, almost no mention. I lead the reader step by step to see what Lib and DLL are going on.

One of the simplest C + + programs, only need a source file, the source file contains the following statement
int main () {return 0;}
Naturally, this program does nothing.
When a program needs to do something, we add more and more statements to the source file, for example, we'll start adding code to the main function:
#include <stdio.h>
int main ()
{
printf ("Hello world!\n");
return 0;
}
Because of the limits of human intelligence, when a function contains too many statements, it is not easy to be understood, and the child function begins to be needed:
#include <stdio.h>
void Showhello ()
{
printf ("Hello world!\n");
}
int main ()
{
Showhello ();
return 0;
}
The same reason, a source file contains too many functions, it is also difficult to understand, people began to split multiple source files
Main.cpp
void Showhello ();//[1]
int main ()
{
Showhello ();
return 0;
}
Hello.cpp
#include <stdio.h>
void Showhello ()
{
printf ("Hello world!\n");
}
Add these two files to a VC project, they will be compiled separately, and finally linked together. In the VC compiler Output window, you can see the following information
--------------------Configuration:hello-win32 Debug--------------------
Compiling ...
Main.cpp
Hello.cpp
Linking ...
hello.exe-0 error (s), 0 warning (s)
This shows the process of compiling the links.
Next, even if you do not know also should guess, when a project has too many source files, it is also difficult to understand, so, people think of a means: a part of the source file pre-compiled into a library file, that is, lib file, when you want to use the function, only need to link lib file can be, Instead of having to ignore the original source files.
Create a new static library type project in the VC, add the Hello.cpp file, and then compile, the Lib file is generated, assuming the file name is Hello.lib.
There are two ways to use this lib for other projects:
1 Add hello.lib to the Project Options-〉link-〉object/library module
2 You can add a line of instructions to the source code
#pragma comment (lib, "Hello.lib")
Note that this is not a part of the C + + language, but rather a preprocessor directive for the compiler to notify the compiler of the need to link hello.lib
Use one way or another according to your hobbies.
The format of this LIB file can be simply described, which is actually a collection of any obj files. Obj file is generated by the CPP file compilation, in this case, the Lib file contains only one obj file, if more than one CPP file will be compiled to generate multiple obj files, resulting in the Lib file also contains multiple obj, note that here is only a collection, does not involve link, so, When compiling this static library project, you will not encounter link errors at all. Even if there is a mistake, the error will only be exposed in the EXE or DLL project using this lib.
About static Lib, there is only so much content, really simple, now we introduce another type of LIB, it is not a collection of obj files, that is, there is no actual implementation, it just provides the information needed to dynamically link to the DLL. This lib can be generated by the compiler when compiling a DLL project. Related to the DLL, the problem began to complicate, I do not expect in this article can be the principle of the DLL is clear, this is not the goal of this article, I introduce the operational level of things.
To put it simply, a DLL project differs from an EXE project in two points:
The entry function for 1 exe is main or WinMain, and the DLL's entry function is DllMain
2 EXE's entry function marks the beginning of a process, after the function exits, the process is finished, and the DLL's entry function to the system, just pass by, load the DLL time pass by once, unload the DLL when the time passed again [2], you can in the DLL entry function to do process processing, But this is usually not the purpose of the DLL, the purpose of the DLL is to export the function for use by other DLLs or EXE. You can think of the relationship between DLL and EXE as the relationship between Main.cpp and Hello.cpp, there are similar, different means of implementation.
First look at how to write a DLL and how to export the function, the reader should first try to create a new dynamic link library project with VC, the creation of the option is not empty project, so you can get an example, in order to start working on the basis of this example.
Look at the header file in the example you created with a statement like this:
#ifdef Dll_exports
#define DLL_API __declspec (dllexport)
#else
#define DLL_API __declspec (dllimport)
#endif
This is the whole mystery of the function's export and use of the exported function. Your DLL project has defined a macro dll_exports in the project settings, so your function declaration as long as the previous add DLL_API means to export it, and the user of the DLL because there is no definition of the macro, so it contains this header file when you think of your function as imported. By imitating This example, you can write a series of functions marked for export.
There is another way to export the function, is to use the Def file, the role of the Def file, in the present only to restrict the function of the name of the exported functions, here, we want to draw the second method of [4] using the DLL: called display loading, through windows API LoadLibrary and GetProcAddress these two functions to implement [5], here GetProcAddress parameters need a string form the function name, if the DLL project does not use DEF file, Then it is likely that you will use a very strange function name (like:[email protected]@YAHXZ) can be called correctly because the function overloading mechanism in C + + encodes the function name, and if you use a DEF file, you can explicitly specify the function name before the code is not encoded.

With this knowledge, you can start to write some simple DLL applications, but I can be absolutely sure that you will encounter crashes, and the previous non-DLL version is fine. If you use the DLL through explicit loading, it is possible that the calling convention is inconsistent and cause a crash, the so-called calling convention is a function declaration preceded by a __stdcall __cdecl and so on, note that some macros such as WINAPI will be defined as one of these qualifiers, do not understand their okay, But remember to be consistent, that is, declaration and definition are consistent, this is not a problem with implicit loading, but the display load is not using the header file, it is possible to produce inconsistencies. The
calling convention is not what I really want to say, although it is a possibility. What I want to say is the memory allocation and release problem. Take a look at the following code:
void foo (string& str)
{
str = "Hello";
}
int main ()
{
String str;
Foo (str);
printf ("%s\n", Str.c_str ());
return 0;
}
There is no problem when the function foo and main are in the same project, or Foo is in a static library, but if Foo is the exported function of a DLL, do not write it, it may cause a crash [6]. The reason for the crash is that "the memory allocated in one module is released in another module", the DLL and EXE are two modules, in the example foo inside the assignment result in memory allocation, and after the return statement in main, the string object destruction caused by memory release.
I don't want to be poor in all of these cases, just ask everyone to consider the memory allocation release problem when designing the DLL interface, follow the principles of who is assigned, who releases.
If you do not know how to design, please copy our common DLL interface-Microsoft's API practices, such as:
CreateDC
ReleaseDC
Paired calls, one function allocated memory, another function to free memory.
Back to the example of a possible crash, how can it be avoided?
This can be done as an exercise for the reader to do, this exercise may take a long time, and if you do, then you are almost apprenticeship. I have seen at least two programmers with more than five years of experience still making such mistakes.

Note [1]: In order to illustrate the need, I use the direct declaration method here, the actual project should use the header file.
Note [2]: also thread creation and destruction will pass through the DLL's entrance, but this is of little significance to the novice.
Note [3]:def file format is simple, for examples of def files can be seen by creating a new ATL COM project.
Note [4]: The first method is similar to using a static library, including a header file, a link library file, and then just like using a normal function, called implicit loading.
Note [5]: Refer to MSDN for specific invocation methods.
Note [6]: It is possible that if both projects are set up to dynamically connect to the runtime, then the allocation release is actually done in the runtime's DLL, so this situation does not crash

VS Configuration OpenCV Methodology:

Reference: HTTP://WWW.TUICOOL.COM/ARTICLES/6VBJJ2

I think that one-second of people who install OpenCV are surfing the web for information, and then follow the steps they have outlined to managernent. I also have such a period, in that period, always thought that programming is the most important work, as for these installation systems, configuration files and so on, is what I despise, I think programming is king, like the former Soviet Union focused on the development of heavy industry, like North Korea's first military politics. However, installing the system, configuration files these seemingly trivial activities, are you embody your computer skills, you have to understand the computer knowledge contained in these activities.

Tell me about the VS installation OpenCV, or, to be exact, configure OPENCV on vs. First you will be the next OpenCV executable file, that is, the three-color "product" word, although the suffix of this file is an. exe, but you can think of this is a compressed file, you double-click to get a copy of the source code, rather than install a software.

OK, get the source code, related to the first question, some documents let you compile the source code with CMake, some no, in the meantime, where is the difference? The essential reason is that OPENCV is an open source project, it allows you to change the source code of OPENCV, so since there are changes will be involved in the compilation, in addition, some third-party files, such as TBB if you want to embed OPENCV use, it is necessary to compile this process, so there will need not compile this code thing. Some versions of OPENCV will publish the compiled version directly, such as the 2.3 version, at this point, you directly in the VS inside configuration can be, some released the source code, no DLL files, then you will compile.

Resolves a problem that solves the second problem, configuring vs. Configure VS, a big lump what introduces the Include directory, library directory What, is there a line in it? When we program, we always include some header files, where are the header files? If there is no IDE record, these things are for us to do, we have to tell the program the path of these libraries. It's not a matter of course, but for the IDE, the path to embedding some runtime libraries is neat, because some of the library functions of the Windows system are fixed, such as folder C:/windows, so when we write such statements in the program "# Include <stdio.h> ", the program will not error, because the IDE on our computer on the day of rooting, it already knows the path of stdio.h, also know the corresponding real library function executable code path. So for opencv such a "outsider", not every computer has, we must let the IDE know the path of the header file in the OpenCV, the path of the library function executable file , so you have to join the Include directory and Lib Such two processes.

Okay, the last thing left is a really big lump of. Lib's accession. The generation of an executable file is generally divided into two processes, one is the compilation, the first is the link, the above inclusion in order to compile the process, then the appearance of Lib is to link the process, Lib is a collection of DLL files, DLL is a dynamic link file, white is also some executable files, The process of linking is to "combine" The code you write with these library files. In the VS configuration OpenCV process, you will have a process to update the "Additional dependencies", at this time, you join the **.lib is the link to use the library file, wrote the Makefile's colleagues on the process familiar with it?

Well, without doubt, we can use OpenCV's library without worrying, just like standard C and standard C + + libraries. Regardless of the compiler to add what the path of the library and dependencies, I believe we can know it, but also know why.

VS and OpenCV Configuration principle essentials