I am working with Qt and Cryengine in visual studios. I am very new to large projects such as this one, but I am nearly to the point of actually adding something to this engine. My code compiles piece by piece, but when I try to compile my "Indie Game" project I get linking errors that after researching I still have no idea how to solve. I know the errors relate to my code InventoryGUI, because when I remove that file the project compiles fine with no linking errors.
This is my InventoryGUI code and the error that is displayed when trying to build Indie Game
http://imgur.com/hzmGdvH
This is the header file that it includes.
http://imgur.com/o22GHXg
I appreciate any help you guys can give on this. Of course, if you need to see different parts of my code, let me know and I will post it as well.
Thanks
Edit: Forgot to add that the function "createInventory()" calls the function InventoryGUI from a different project. I believe going between projects is very likely the cause of the errors.
if InventoryGUI class is defined in a shared library ("dll") and used in an executable, then you have to export its symbols (on Windows build that is).
so try something like :
#ifdef WIN32
# ifdef MY_LIB_EXPORTS
# define MY_LIB_DLL __declspec(dllexport)
# else
# define MY_LIB_DLL __declspec(dllimport)
# endif
#else
# define MY_LIB_DLL
#endif
class MY_LIB_DLL InventoryGUI
{
...
};
Then, the library defining InventoryGUI should have defined MY_LIB_EXPORTS.
For example if you use pro files system, it would look like
DEFINES += MY_LIB_EXPORTS
Other projects should not.
Check if there is a similar mechanism for the other classes of the library.
Related
I am new to Visual Studio, so if I say something wrong, please point me to the right direction.
I have a large C++ project that consists of shared library of around 20 classes and 7 executables, built by CMake in Linux. Each executable has its own CMake setup that links against the library.
I watched couple of videos on VS, managed to understand how to structure code and dependent libraries and successfully compiled the library statically.
I even managed to setup CMake in Visual studio, but started receiving an error that my .dll file is not Win32 application when I tried to build a project that links to it, so I dropped CMake and built the library by first making empty project and then adding necessary files (I thought it's CMake issue).
Long story short, now I have new setup for my library in VS that builds without issues. However I want my library to be dynamic because it makes ton of sense as 7 different projects depend on it and that's how I did it in Linux.
To my big surprise, even though selecting .dll will build, it cannot be linked to (I started all of this as empty project, not .dll template).
What I just discovered that building .dll library requires a macro that looks like (taken from https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=msvc-170):
#ifdef MATHLIBRARY_EXPORTS
#define MATHLIBRARY_API __declspec(dllexport)
#else
#define MATHLIBRARY_API __declspec(dllimport)
#endif
and before return type of any function in library I need to add the macro as:
MATHLIBRARY_API double some_function();
So if I understand correctly, this macro is "exporting" function names to .dll. Does that then mean that I need to open all 20 header files and wrap every single function in it with the macro?
Note that most header files are class declarations, do I need to wrap every single class method, just the public methods and is there a way to make a whole class "exported"?
It seems quite a cumbersome task just to build a shared library. I realize now this is why cmake failed and kinda begs the question on its cross platform capabilities if this wrapping to make .dll in VS needs to be done like this.
I am considering building my library statically, and in the same solution, add additional projects, and make a reference to the static library.
It kills modularity of the project, but it should work fine.
I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.
I want to build C++ desktop applications using visual studio and wxWidgets on windows 7. I'm coming from C++ Builder.
I downloaded and built the wxWidgets libraries successfully and I can run the minimal_vc14 solution just fine. Now it comes time to create my Hello World app. I've created a new, empty C++ project and using NuGet added the wxWidgets template. Then I use class wizard to add a new class (Test3) with a base class of wxApp.
I immediately get 45 errors. The first of which is
Severity Code Description Project File Line Suppression State
Error (active) cannot open source file "../../../lib/vc_dll/mswud/wx/setup.h" Test3 c:\wxWidgets-3.1.0\include\msvc\wx\setup.h 121
digging into that file I find the following bit. The last include statement is the problem line identified above, but the problem I think is in the wxConcat6 statement. All of those ../ lead nowhere. Shouldn't that point to $(WXWIN)?
// the real setup.h header file we need is in the build-specific directory,
// construct the path to it
#ifdef wxSUFFIX
#define wxSETUPH_PATH \
wxCONCAT6(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, wxSUFFIX, /wx/setup.h)
#else // suffix is empty
#define wxSETUPH_PATH \
wxCONCAT5(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, /wx/setup.h)
#endif
#define wxSETUPH_PATH_STR wxSTRINGIZE(wxSETUPH_PATH)
#include wxSETUPH_PATH_STR
Also, smaller problem but further up the setup.h file I see that WXUSINGDLL has been defined, but I want to use libs. I can't figure out where that is being set either.
Obviously there is a configuration step I missed somewhere. Please advise.
As usual the answer can be found by reading EVERYTHING.
There are 2 things that need to be configured for this process to work correctly.
After creating the project go to the project properties and set the character set to Unicode. The default is Multi-Byte. My next quest will be to find where to change the default!
After installing the package template (or is it a template package?) go to the project properties and set shared to "statically linked build".
Presto changeo, you are ready to go. Add the following for the absolute minimum to make a compilable application. This is based on the tutorial here:creating-wxwidgets-programs-with-visual-studio-2015
bool MyProjectApp::OnInit()
{
wxFrame* mainFrame = new wxFrame(nullptr, wxID_ANY, L"MyProject");
mainFrame->Show(true);
return true;
}
wxIMPLEMENT_APP(MyProjectApp);
I suggest you make a copy of minimal sample (or widgets, as it uses more controls and links more libs), in the same location, and modify the source file as you need.
When you have played enough with it, for sure you'll find it quite easy to change the project file so that it'll use $(WXWIN) or any other custom settings.
p.s. I don't know what "wxWidgets template" from NuGet contains, but I strongly doubt it is provided by wxWidgets maintainers.
I am using Visual Studio 2013 to write code for AVR. I have been following this tutorial.
Whilst writing the code, I noticed that Visual Studio kept on underlining things like DDRB or PORTB and I keep on getting errors like Error: identifier "PORTB" is undefined, however, the program compiles correctly.
Interestingly enough, upon pressing alt-F12 Visual finds numerous files where they are defined.
Your Makefile runs compiler with an option -mmcu=YOURCHIP. This implicitly defines macro corresponding to your chip. For instance for atmega32u4 the macro is AVR_ATmega32U4. Intellisense is run 'outside' of your compiler so it's not aware of this macro and when parsing standard avr header - like avr/io.hit skips the proper inclusion of header file for your particular MCU. It's something like:
#elif defined (__AVR_ATmega32U4__)
# include <avr/iom32u4.h>
So, if you want to have intellisense support for stuff defined in those headers you might need to define that macro, at the top of your source, like this:
#define __AVR_ATmega32U4__
#include <avr/io.h>
int main() {
char a = PORTB;
}
You may find what macro corresponds to which MCU in the middle of this page
i would suggest to simply use the original IDE as Make-File generator and just call that makefile from the VS2013. This has the overhead for maintaining two different projects (but mostly actions that require changes to makefile are rare) but leaves the comfort of the good VS IDE and leaves you the way back to original IDE for debugging.
you also have to set the include directories in the vs2013 project settings to get the intellisense 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.