When implementing the example from http://msdn.microsoft.com/en-us/library/windows/desktop/dd387907%28v=vs.85%29.aspx I have a problem with DeleteMediaType() and VisualStudio 2010: this function is not defined. I found a header Mtype.h should declare it but that does not exist for VS2010. Shouldn't all the headers and libraries be there without installing some additional SDKs?
Where is DeleteMediaType() defined?
In Windows SDK \Samples\multimedia\directshow\baseclasses\mtype.* files. You are normally supposed to include .h and link strmbas?.lib to make it available to you, but you don't have to: you might prefer to either include this into project directly, or duplicate the function (it's simple and wraps a couple of CoTaskMemFree calls).
Related
I am building a DLL using visual studio, which involves installing the following libraries :
GLM
GLFW
GLEW
I linked those libraries to visual studio using the following method :
specifying Additional Include Directories in the project property page
specifying Additional Dependencies in the project property page
specifying Additional Library Directories in the project property page
Of course GLM is a header only Library, which means that I am only required to specify the Additional Include Directories for GLM. And my dll built perfectly fine.
But the real problem occurs when using the library in a test project. I linked my test project to my library using the method mentioned above, but when I tried to build the test project, it produces the following results :
Cannot open include file <GLFW/glfw3.h>
And the same goes for glew. It seems that these libraries are not found when the library is being used by another test project. How can I fix this? Any help would be highly appreciated.
Set the Additional Include Directories correctly for all projects. The compiler doesn't magically inherit settings from a project which happens to have it's output linked into another project. So you have to provide it the correct include path for any source file it sees. To spare yourself from having hardcoded paths to include directories you could use a property sheet common for both projects. Or you could tackle the problem in code and make use of the PIMPL idiom (eventually as simple as e.g. forward declaring some GL types and using a unique_ptr to them in public classes) so the headers of your project never expose any of the external include files.
Is there a way to get all function used in code.
Actualy I have a big dll which provides me an api of third-party system and now I need list of functions from this dll I'm using.
Is it possible? What way is better: macro or vs extension?
I guess, the API has a separate namespace. Unless you use explicit calls like: Third.party.namespace.ClassName.Method() you can remove using clauses and then filter somehow the errors the compiler shows you while rebuilding.
Or you can start by removing the references to the 3rd party assemblies, which will generate errors for all usings. Then you remove the using and then see every bit of code that relies on them. As I said unless there are explicit calls (which means there were some ambiguities) this should work.
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 am getting LNK2001 errors when trying to use Crypto++. The official advice for this is:
There are two ways you can deal with this, either change Crypto++ to export those classes, by using the CRYPTOPP_DLL macro, or link with both the DLL export library and a static library that contains the non-DLL classes and functions. The latter can be built by using the "DLL-Import" configuration of the cryptlib project.
It would be preferable to use the first option, and given that I am not experienced in using Visual Studio, I cannot find the location and execution method of the macro.
In short: Where do I find the macro and how do I execute it?
Cheers.
In short: Where do I find the macro and how do I execute it?
The macro is CRYPTOPP_IMPORTS. You use it when performing dynamic linking on Windows (i.e., the Crypto++ DLL).
You can 'execute' it in one of two ways. First, you can add #include <cryptopp/dll.h> to your stdafx.h. dll.h. defines it, and dll.h must be included before any other Crypto++ defines. Second, add it to your project's preprocessor macros. In either case, CRYPTOPP_IMPORTS will be defined.
I suspect you have a different error, though. You're probably not including the Crypto++ library (for static linking) or Crypto++ import lib (for dynamic linking) in your project.
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.