Compiler warning C4945 - c++-cli

I am trying to compile a simple CLR project, which has no dependency.
When I compile this project I get 973 warnings (C4945) stating that
c:\windows\microsoft.net\framework\v4.0.30319\system.dll : warning C4945: 'xxx' : cannot import symbol from 'c:\windows\microsoft.net\framework\v4.0.30319\system.dll': as 'xxx' has already been imported from another assembly 'System'
As I mentioned that my project has no dependency on other projects, I tried to compile my cpp files one by one, starting with stdafx.cpp.
While doing this I noticed that if I include #include <msclr\marshal.h> I get those warnings, and if I don't there are no warnings.
Now I have following queries.
Is #include <msclr\marshal.h> deprecated and replaced by something
else?
If no, how can I remove those warnings? Is #pragma warning disable the only way?

This is still a problem for VS2019, but you can force the header to skip #using <System.dll> like this:
#pragma push_macro("_CRT_WINDOWS")
#define _CRT_WINDOWS
#include <msclr\marshal.h>
#pragma pop_macro("_CRT_WINDOWS")
This works for the other marshal headers as well (marshal_cppstd.h, etc.)

Related

Header-only asio standalone

Sorry in advance for a kind-of-dumb question - I'm pretty new to all this.
So I downloaded asio from here, and tried to #include asio.hpp, but got the following error;
fatal error: boost/config.hpp: No such file or directory
I thought this was rather odd, as it was suppose to be independent of Boost. I poked around a bit, and saw that I needed to define ASIO_STANDALONE, which I promptly did, only to be met with more errors where it tried to #include something else from Boost.
Is there just a big list of all the things I have to #define to tell it to be standalone or something? That would be very helpful.
This is an old question, however i had the same problem currenlty with Visual Studio 2013 and Asio 1.10.6. In Visual there is no switch nor compiler flag for c++11 features. Even with #define ASIO_STANDALONEAsio requires Boost.
Solution is to manually specify that our compiler is c++11 compliant. Just add:
#define ASIO_STANDALONE
#define ASIO_HAS_STD_ADDRESSOF
#define ASIO_HAS_STD_ARRAY
#define ASIO_HAS_CSTDINT
#define ASIO_HAS_STD_SHARED_PTR
#define ASIO_HAS_STD_TYPE_TRAITS
#include <path_to_asio/asio.hpp>
As noted on the Asio website:
When using a C++11 compiler, most of Asio may now be used without a dependency on Boost header files or libraries. To use Asio in this way, define ASIO_STANDALONE on your compiler command line or as part of the project options.
Thus even when ASIO_STANDALONE is defined, Asio will use Boost when:
Using a non-C++11 compiler.
When using certain features, such as stackful coroutines that are based on the Boost.Coroutine library.
With asio-1.10.2, the following program:
#include <asio.hpp>
int main()
{
asio::io_service io_service;
}
compiles with gcc 4.8.1, using -DASIO_STANDALONE -std=c++11 compiler flags. Without specifying the compiler to use c++11, compilation fails when attempting to include Boost header files.

Adding C file causes pch error

I have an XCode project with objective-C files. If I add a new (empty) C file and try to build, I get a large number of errors right away while building a precompiled header, in ProcessPCH step. The errors are "fatal error: Could not build module 'Foundation'", and things in Foundation.h not being found. Remove the C file and it builds again. What is going on, and how to fix it?
(XCode 5.0, OSX 10.8.4)
EDIT I have tried Clean and Clean build folder, no effect.
EDIT Setting Precompile prefix header = No results in a bunch of syntax errors instead, in stuff like NSObject.h (and other Foundation framework header).
EDIT User Cy-4AH figured it out: there needs to be #ifdef __OBJC__ around the whole pch file.
Surround #import's with preprocessor directive #ifdef __OBJC__ #endif

When using Xcode analysis (product>analyze) is there a way of ignoring any errors in a given file?

When using Xcode analysis (product>analyze) is there a way of ignoring any errors in a given file?
Eg a pragma or something?
We just want to ignore any warnings on third party code, so that it's more obvious to us when there's a problem in our code.
Thanks
As suggested by matthew:
#ifndef __clang_analyzer__
...
#endif
#pragma clang diagnostic ignored "-Wall"
See the clang user's manual for other useful related #pragmas for clang.
This also works for GCC.
#pragma GCC diagnostic ignored "-Wall"

using libcurl without dll

I am using Microsoft Visual C++ 2010, and I need to make an application that does not require the libcurl dll. I am defining CURL_STATICLIB in the preprocessor directives and linking to libcurl.lib, libcurl_static.lib, ws2_32.lib, and winmm.lib, but it still requires the dll to work. If I only link to libcurl_static.lib, it has undefined external symbol errors. How can I get it working?
I have also tried building the source but I get 13 errors (wow, unlucky number) that all say "error C2011: 'pollfd' : 'struct' type redefinition". Could someone help me get libcurl working?
There is no simple answer :)
Libcurl depends on other third party libs (it depends on binary distribution that you are using). As you get rid of DLL - you'll have to link with corresponding third parties manually.
Ok, so the first point is that you should not link to libcurl.lib as it binds you to DLL which you don't want to.
Second point - when you are linking with libcurl_static.lib then (as mentioned above) you'll have also to link with libraries it depends on. Simple way to do that is to do something like this:
#if defined CURL_STATICLIB
#if defined _DEBUG
#pragma comment(lib, "libcurl-7.19.3-win32-ssl-msvc\\lib\\Debug\\curllib_static.lib")
#else
#pragma comment(lib, "libcurl-7.19.3-win32-ssl-msvc\\lib\\Release\\curllib_static.lib")
#endif
#pragma comment(lib, "ws2_32.lib")
#pragma comment(lib, "libcurl-7.19.3-win32-ssl-msvc\\libeay32.lib")
#pragma comment(lib, "libcurl-7.19.3-win32-ssl-msvc\\openldap.lib")
#pragma comment(lib, "libcurl-7.19.3-win32-ssl-msvc\\ssleay32.lib")
#endif
But this way - you'll get three more dependencies. Alternatively, you can search for a way to link with them statically, but it is a different story.
As another alternative - you could rebuild libcurl_static.lib from sources after disabling all the features you don't need thus removing unwanted dependencies (as described in "Disabling Specific Protocols in Win32 builds" of INSTALL file).
And final point - as libcurl has quite poor support for windows compilation from sources, I'd recommend you to revisit the idea of getting rid of curllib.dll.
I got a static build of libcurl to compile and link by specifying both HTTP_ONLY and CURL_STATICLIB in the preprocessor directives of the libcurl project and my application. This eliminates all the dependencies required by protocols you likely do not need. The application now works without requiring any DLLs at all.
Beside the above, I just needed to make sure libcurl.lib and the path to the curl include files were set in the application's visual studio project settings.
References I used:
Disabling Specific Protocols in Win32 builds:
http://curl.haxx.se/mail/lib-2011-12/0123.html
Using libcurl in Visual Studio (out-dated):
http://curl.haxx.se/libcurl/c/visual_studio.pdf

Why am I unable to #ifdef stdafx.h?

I am trying to include 2 platform-specific stdafx.h files in my .cpp file, but the compiler is unhappy when I try to #ifdef it.
#ifdef _WIN32
#include "stdafx.h"
#elif _MAC
#include "MAC/stdafx.h"
#endif
You may wonder why I am using stdafx.h in the Mac code, but that is not important at the moment :).
When I try to compile the code on Windows, I receive: Fatal Error C1018. I tried enclosing other header files with #ifdef in the same file, and the compiler was happy. Therefore, it looks like Windows doesn't like stdafx.h to be #ifdef-ed, or that Windows only allows #include stdafx.h
to be the first line in the file.
So my question is, why?
Kat
When the compiler includes a pre-compiled header, it basically "forgets" anything that came before the header. Thus your #elif isn't matched to a #if anymore.
This is because you have Precompiled Headers turned on - turn it off and you should be fine.