I'm working on a utility (for practice) that has two tools that a user can run.
I want to know if there's an outer layer within a solution where I can build classes that are recognized by all projects of said solution.
I'm at the point where both tools are finished and I want to add the two projects to one solution. However, these tools can share a few non-static classes and I really want to avoid having multiple of the same .cpp/.h files for each project so if I need to edit or add to a shared class, I don't have to copy/paste the edits into each project.
I tried using resource files, but they won't add .h or .cpp files. I tried adding the classes to their own project and then using them as references in the other projects, but the classes within the other projects won't recognize them. I also looked around at creating a library, but I'm not sure if it's possible to create non-static libraries as these projects will have multiple objects of the shared classes.
I'm very visual and I'm not sure if I explained my issue well so here's a simple diagram of what I want. Each arrow shows who each project can "be aware of" so-to-speak (conceptually similar to class inheritance). The bold First Project is the solution's entrance; essentially just where the user specifies which tool to run.
From what you described a class library would be the solution. This would allow you to share your two classes between both projects. In C++ there are two types of class libraries the Static Link Library and the Dynamic Link Library.
Here is a nice answer from a previous StackOverflow question which should aid you in determining which type of class library to use.
I have also included two separate links from Microsoft, since you tagged your post with Visual Studio, on how to create and use a library of each type.
MSDN: Static Link Library Tutorial
MSDN: Dynamic Link Library Tutorial
Related
In the past I have created a jar file that contained many "helper functions" that I used and made common to many different applications. I felt this was important as anytime I used my "helper" jar file in any new applications or when making changes to any existing ones, the latest and most up to date version of my "helper" jar was always used. It was developed separately and had it's own version control.
I'm looking to do something similar with C/C++
At the moment I have a collection of headers, doing something similar to my "helper" jar in java but finding it cumbersome managing changes, ensuring the most up to date collections are used. So for example, if I made some changes to these "helper" headers, I need to copy them into each project and rebuild.
If we take the below as an example of what I do in Java;
and the below is the structure that I'd like to do something similar with in C++;
I'd like some way of keeping my_includes separate so that any changes I made to my_includes are automatically included in any existing or new applications, in the way Utilities.jar is in the above Java example
I accept that I cant build a library or such as it won't then be as portable, right?
I suspect I'm missing something quite obvious, just not to me.
All helpful comments appreciated, thanks in advance...
At first you could create a library from your utilitis.cpp and all include files independently and add this library to any project. I just provide URL for sample generate the static and shared library.
Create static and shared library (GCC)
And then you can add custom include files to any project in c++ just need to add the specific directories to your include Path in compile time base your platform or if you use cmake you can edit the "include_directories". And also you should link the generated library to your project as described in provided URL.
I have an object file library that exists as a standalone VC++ solution. I have a number of other completely separate VC++ solutions, and I would like some of them to utilise the classes included in this library.
However, since they are in the same solution, I cannot seem to add them as a dependency. I have attempted to investigate so-called "linker" dependencies but can't get it to work.
Does anyone know of a standard, modern efficient way to do this. Eventually my plan is to conglomerate these projects into a single solution as I believe they should be, but that is not something I have the time to deal with right now.
I think you are mixing terms project and solution. Generally speaking, solution is a collection of projects, with specified dependencies between them.
Library should be a project (possibly dependent on another projects), but not a solution. If you would like to include your library in another solutions, simplest way to do that would be to add project for library (and any dependent projects) to solutions you would like to add them by right clicking on solution->add->add existing project->add your project. This will ensure library will be compiled as part of solution.
You would need to set dependencies between projects (in your solution), and add include/linker path for the library to any projects using it within the solution.
This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
I am working on a game engine project in C++ with VS2010. We have one main project, OgreProject, which includes some Ogre3D stuff for rendering. Then, we have a class library project called AudioLibrary. AudioLibrary uses fmod, and has includes to the appropriate headers and libs. The problem arises when a class in OgreProject wants to use the SoundPlayer.h in AudioLibrary. Then, OgreProject does not know where #include is. It feels wrong to tell OgreProject where fmod is, since it will not directly use these headers. What is the correct way to using header files from AudioLibrary in OgreProject, without OgreProject knowing of ?
There is no correct way. There's no magical way for one library to know about the other library; you'd have to configure them to do that. If you put them in the same solution you can add one project to another as a project reference.
You might try the Pimpl idiom (or pattern).
It will let you remove everything related to fmod from your project's header file. Only the implementation files will need the fmod headers, not client projects.
See this answer which explains the benefits.
You should probably define a heirarchy for all the components of your project and keep all the header files from a particular component which other components are going to use at a pre-defined place. Other components can then always look at this place. There is nothing wrong in telling the components where to look for these dependencies explicitly
I am working on a neural network project that requires me to work with C++. I am working with the Flood Neural Network library. I am trying to use a neural network library in an unmanaged C++ project that I am developing. My goal is to create an instance of a class object within the Flood library from within another project.
There is plenty of documentation online regarding how to reference an unmanaged C++ project from within a C# project, but there is not enough information on how to reference one C++ project within another. Similar to how I would do it in C#, I added the Flood project as a reference in my other project, but I have tried all sorts of techniques to work with the object. I have attempted to use the #include directive to reference the header file, but that gives me errors stating that I need to implement the methods declared in the header file.
How to add a reference in unmanaged C++ and work with the class objects?
Yes. You need to do two things:
#include the respective header files, as you did
Add a reference (Visual C++ supports two types, "dependencies" which are outdated and should not be used anymore, and "references" which are the correct ones). Use them to reference the other project, which must be a part of your solution. Meaning, in this case you must be able to COMPILE the other project.
Alternatively, if you do not have the source code, or you do not wish to compile the 3rd-party code for any other reason, you may also reference a compiled binary. The best way to do it is pragma comment lib. If this is what you need, please comment and I will edit my response.
Looking at the provided vcproj file, the flood distribution is really weird, and builds an exe file.
As such, the supported way to use Flood in your own project is not via two projects (being your application and a "libflood" project) - But simply to add all the flood cpp files to your own project and build that.