Can I include and make use of header files if I have C++ header and C++ Source?
How can I do so in VB 2008?
eg. I have genlib c++ header and genlib c++ source.
I want to use all functions in source to be accessible in my program when I type #include genlib.h
How can I do it when such headers and source are in bulk and may depend on each other.
eg. StanfordCs106BHeaderandSOurce
And Is there any solution so that I dont have to add any addition dependencies whenever I create a project,just like .
May be copping and pasting in program file
Related
Background: I'm using Project Euler as an excuse to test various C++ features and find holes in my knowledge. I have a project that creates an executable which solves various math problems. It's getting unwieldy and I'm splitting the problems out into separate executables. A lot of the math functions are re-used in several of the problems.
First: I want to create a DLL file with math helper functions. Rather than provide one single mathhelp.h file for the entire dll, I'd prefer to have several separate .h files e.g. primes.h, cartesian.h etc./ that each provide access to separate namespaces in the dll.
Is this possible?
Second: Separately, I do want a single mathhelp.h file for those projects big enough they just need access to every helper function without including fifty separate headers. How to do this is answered in:
How to export multiple header files as a single header file in C++?
but that answer gives me a follow-up question: If, in an executable project, I include the following header from the DLL project:
#ifndef MATHHELP_H
#define MATHHELP_H
#include "primes.h"
#include "cartesian.h"
#endif
...how does that compile if I don't also have primes.h in the executable project? Won't the pre-compiler reach the first #include and choke on the fact that I don't have primes.h in the project?
When you provide a c++ compiled API to a user ( let's say it is compiled in a .dll file) you should provide beside the .dll file also the .h files (containg all header that were used to compile that .dll) and .libfiles ( containg the exported symbols from that .dll ).
Now let's say that your user has the executable a.exe, and wants to use your compiled API. Usually you will provide them a file structure which looks more or less like that :
include / primes.h
cartesian.h
mathhelp.h
lib / Api.lib
bin / Api.dll
When an external executable uses your code he will need to add external flags in the compilation procedure like : -I/pathToInclude -L/PathToLib -l/yourLibrary ( you need to check the exact sintax for doing that).
In your code you you will have something like this:
#ifndef MATHHELP_H
#define MATHHELP_H
#include <primes.h>
#include <cartesian.h>
#endif
In this case the compiler will look firstly in the current directory ( where he won't find the headers) and then in the folders specified by the -I flag ( where he will find your headers).
I have a question about using C++ header files in Objective-C++ modules in Xcode. Specifically, why can I #include them in source files but not header files?
Here is a specific example.
I'm using Xcode 7.2.1 and have two projects. The first is a C++ framework I package into "myFramework.framework". It exposes "myFramework.h", which in turn pulls in "myLib.h". At the top of "myLib.h" is an "#include <string>".
The second project is an Objective-C iOS app which consumes the above framework. In this project, "myViewController.mm" (Objective-C++ source) has "#import "myFramework/myFramework.h" at the top and makes reference to things defined in that header file.
At this point all is well and good. It builds and runs with no issues.
When I move the "#import myFramework/myFramework.h" line to "myViewController.h", the compile fails because it cannot locate the "" header dependency.
It doesn't matter if I change the file type for "myViewController.h" to Objective-C++ header from plain old "C Header". Either way, Xcode's header search paths don't look for standard C++ headers.
So my main question is why does it behave this way? Why is a #include/#import treated differently just because it's in a header file?
My second question is if there's some way to make Xcode treat the #include/#import the same when it's in the header file instead of the source file?
Thanks much!
Are you sure that you get the error while compiling the myViewController.mm file?
Check if myViewController.h is imported into some other, non ObjC++ file (and that that one is the file that fails to compile).
I suspect the issue with including C++ headers inside other headers is that an Objective-C source file gets to see the C++ header file, which upsets it.
If you have mixed C++/Objective-C++/Objective-C then you are probably better off only exposing a pure Objective-C interface to other modules in the project and include any C++ header files in the Objective-C++ source files only.
Alternatively make everything Objective-C++ and then you don't need to worry about it at all.
Hopefully this answers your second question as well.
I have built a shared library (.dll) from a C++ source code.
Now when I want to use this library in another program, do I need to include all of the header files that were used originally for building the library, or including just the headers that belong to used functions in my (new) program suffices? There are many functions in the library that are not used directly in my new program, but, needless to say, all of them are used by the functions in the program.
(So they are indirectly used in the program too, and it would be strange if their inclusion is not necessary.)
Header files are nothing magical, they're just a convenient way of ensuring your .cpp file has access to all the declarations and definitions it needs. So only include those you actually need in each of your files(1).
The above refers to putting #include statements in your files—only do this for header files you actually need to use. Of course, the header files you include can #include other header files themselves.
Like any other well-behaved (i.e., actually usable) DLL, your DLL must supply a set of public interface header files. Under normal circumstances, you must have all these public interface header files available for building a program using that DLL. That doesn't mean you should #include them all; quite on the contrary, you should not. The compiler (preprocessor, actually) will #include what it needs.
Note that when the DLL itself was built, there were probably many more header files involved, but these were private to the implementation and not part of the public interface. You do not need them to build a program using the DLL, and in the general case you don't even have access to them.
So, when designing your own DLL, you must stricly differentiate between public and internal header files. The public header files must be made available to clients, the internal ones need not (unless the client is supposed to build the DLL themselves). Of course, this means a public header file may never #include an internal one.
(1) Note that header file inclusion is purely textual—when reading your source file, the preprocessor effectively copies the contents of the header file and pastes it in place of the #include statement, then goes on parsing. You you did this copy & paste yourself instead, the file would build and run just as well. Of course, it wouldn't pick up later changes in the header file, which is the primary reason why header files are used in the first place.
I just started learning C++ with Dev C++ as my IDE. One of the tutorials I'm using has a page in it about compiling a program made up of multiple files. It's simple stuff at this point, I have one file with a function in it, and the other file has all the other required code to call the function and output the results. The problem is that the tutorial doesn't tell me how to join these files so I can compile the program and have it work. There's seems to be multiple ways of doing this and I'd like them all but I'm mainly look for the simplest one right now.
I should also mention that I'm new at this so please try and keep your explanations simple and understandable.
In general, you would add both .cpp files to your project under the same target. It IDE will automatically add both files to the build and link them together.
That said, Dev-C++ is very, very old and unmaintained. It has not seen updates in several years. I strongly urge you to use a different IDE. There are many to choose from, including a fork of Dev-C++ called wxDev-C++. I'd actually recommend Code::Blocks or Visual Studio Express, which are both much more modern and have better support for debugging and many other features.
I am not sure of Dev-C++, but the concepts remain the same. So, here is how you can try to get both the files to work together
Each C++ file is a compilation unit - meaning, the compiler will convert one .cpp / .cxx file to one .obj / .o file (on Windows and Linux (or any Unix)) respectively
The obj files, called the object files contain the machine code (am skipping few internal details here) for the classes and functions present in that particular file
If you want to access the functions present in a different compilation unit, you need to link those two object files
Linking is a term that is used to, well, link two object files
There is a separate process (other than the compiler) which does the linking of the object files
So,in your case, you need to use the dev-c++ compiler and create separate object files
Then using the linker you link both the object files to create the final executable
If there are functions that exist in the .cpp files that you want to reference, you use the header files. The header files contain the function/class declarations. The .cpp files will have the implementations. So, in one of your .cpp file, (say) A.cpp, you include the header B.hpp and use the functions in the B.hpp file. The inclusion of headers will tell the compiler that the function declarations exist elsewhere and that the linker will take care of stringing all these references together to create the final executable.
Hope this helps, else, please don't hesitate to mention the files you are using and I can suggest how to link both the .cpp files together.
You must include the other files by using the #include preprocessor directive
in the top of the file where you have the main() function
For example:
#include "filename.h"
...
/* rest of code containing main function goes here */
...
#include "path/filename.c"
main
{
...
...
...
}
I have a Visual C++ solution with 2 projects AlgorithmA & AlgorithmB and both share a common header file RunAlgo.h with the class declaration. Each project in the solution has its own unique implementation for the header file.
I am trying to compile a DLL out of the common header file RunAlgo.h and add reference to this DLL in the projects AlgorithmA & AlgorithmB. I have then included separate RunAlgo.cpp definition file in both my projects. The problem is that I am getting linker errors while compiling the new DLL project which has only the header file.
So, the question is
Can a header file with only class declaration be compiled into a DLL (Similar to class library containing an Interface in C#)?
For the above scenario, is there a better approach to reuse the common Header file among projects?
Should the above method work (re-check my code?)
1 & 3: No, that doesn't make sense in C++.
Libraries (dynamic or otherwise) are only used during linking. During compilation declarations must be visible to the compiler in source-code form. This is why, for example, you have to explicitly #include standard library headers in addition to linking against the standard library.
2: What you're already doing is basically the only solution. Put the common header files in their own directory, and add that directory to the include path of each of the two projects.
Can a header file with only class
declaration be compiled into a DLL
No, headers typically include only declarations. Declarations when compiled don't produce any machine code, so resulting DLL would be empty.
For the above scenario, is there a
better approach to reuse the common
Header file among projects?
Reusing header is fine. In fact, every library has it's set of headers that you need to include in projects using that library.
I don't know much Visual C++, but I think you could make third project, containing common parts (i.e. RunAlgo.h header), and mark it as a dependency for AlgorithmA and AlgorithmB projects.
To 1.:
No, free-standing header files never end up in a dll. Header files are included in implementation files and that's how they are compiled. Header files are usually distributed along with a dll or library if you want to allow third parties to link against it.
To 2.:
Why don't you declare an abstract base class with the interface for the algorithm and provide two different implementations by defining two subclasses (AlgorithmA and AlgorithmB) deriving from the base class? I don't get why you want to different DLLs.
To 3.:
No, it shouldn't. See point 1.
Use 2 namespaces in C++ to write 2 different implementation with the same header file
namespace ImplementationA
{
}
namespace ImplementationB
{
}
When you want to use 1st implementation
using implementationA;
or
implementationA::function1();