We have a suite of apps which share a set of common screens. Some screens have use more functionality in some apps than others. For example, in one app our issue screen supports tags, but in the others it doesn't. In one, our regions screen supports workflows, but in the others it doesn't.
We're using core data, and the different apps have different data models; If an entity isn't used by an app's data model, the corresponding class doesn't get built into that app.
The result of this is that some of our controllers contain references to classes that may or may not exist when the controller is used in a particular app. At the moment, we get around this using "magic" #defines in our apps' PCH files; so some code in our Issue controller is wrapped in #ifdef SGB_ISSUES_HAVE_TAGS and some code in our Regions controller is wrapped in #ifdef SGB_REGIONS_ARE_FILTERED_BY_WORKFLOW.
What I'd like is to do this instead by detecting whether a file has been included in the project. So at the top of our Issue controller I'd have something like this:
#if exists_in_project("SGBIssueTag.h")
#import "SGBIssueTag.h"
#endif
and then I could put #ifdef SGB_ISSUES_HAVE_TAGS into SGBIssueTag.h; any app we built that used the issue controller would get the issue tag functionality as soon as we included the IssueTag entity, and we wouldn't have to mess around with the PCH file.
Is anything like this possible?
This issue has bitten a lot of people - the issue of header files being "global" to a project.
My suggestion is to try and force errors during compilation. You can add in a PCH or file included there defines for each App - lets say you have app A, B, and C. So during any one build, only one of these is active.
Then, in every .m file (and possibly some .h files), you will conditionally include headers:
...
#if defined(A) || defined(B)
#include "SomeInterfaceFile.h"
#endif
...
Once you start building A, you will get compilation errors in files where the source code refers to some object that is defined in a out-of-scope header file. That code you will also have to wrap in a similar if statement.
This will work perfectly, with the downside that your code gets cluttered with these conditional statements.
Related
I have inherited development of an iPhone app that was originally created overseas. The original developers are no longer available for questions. The app is currently available on the app store. So I assume the zip file that I received of the project is current and complete.
When I first open the project in xcode and do a build, I get hundreds of errors. They are all the same basic error. There are hundreds of .h files with one line:
../../../FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/Internal/ServerConfiguration/FBSDKServerConfiguration.h
I get the error "expected identifier or '(' on the first character of this line in every file.
I tried changing the line to:
#include "/../../../xxxxxxxxx"
and that worked. But as I said, there are several hundred of these files in the project. If this was a running app 'supposedly' from this source code, why should I need to go change hundreds of files and add #include to each line?
This project uses an old version of swift, and I had to go all the way back to xCode 7 to find a development environment that would support it. Is the .h syntax in these files some sort of deprecated syntax that stems from an even older version of xCode? Can some seasoned iPhone app developer tell me about this particular .h file syntax of including another .h file (and why it's failing for me now)?
Basically, if I need to change all of the .h files, then so be it. But I'm more than a bit concerned making this drastic a change to code that supposedly recently built a running app.
Suggestion? Enlightenments? Thanks.
Jerry
The "syntax" you described -- just a single line containing a file name (with a relative path)
../../../FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/Internal/ServerConfiguration/FBSDKServerConfiguration.h
has never ever been correct C/C++/Objective C (preprocessor) syntax. Either is some strange, proprietary custom preprocessing is running, or it's just garbage.
Using
#include "/../.."
is also nonsense: If you start a path with /, you start at the root directory, so navigating up with .. will lead you to root again, and xxxxxxxxx is expected exactly there in the root directory.
This was to the syntax. The semantics is hard to tell without the project.
Maybe it might just help if you completely remove those strange header files,
or comment out the erronous lines
or you need to adjust your include paths in the project to help Xcode find the files
I have 2 frameworks created by me that use (both of them) a library also created by me.
The first framework initialize the library and makes all its workflow. After finishing the first framework, the second one must start.
But when the second one is going to start, after initializing the library, the app using both frameworks crashes with a exc_bad_access error.
Apparently the library is created correctly, but if i comment the line of code to initialize the library in the second framework, the workflow continues (it crashes later because it has no library initialization).
Is there anything I'm doing wrong? Should I use two separate libraries instead?
EDIT:
Imagine the situation:
Framework A has this methods: start, stop. And while it works it delegate to the methods: infoFromA,frameworkAFinished.
Framework B has this methods: start, stop. And while it works it delegate to the methods: infoFromB,frameworkBFinished.
Both start methods initialize the static library mentioned (lets call it problematicLibrary).
Both frameworks present some views to make its functionality. So lets make an example of the app workflow.
At the app view viewWillAppear method, I start the Framework A just using:
[FrameworkA start]; , this will initialize the library and present a view. With this view (using my problematicLibrary) some info will be delegated to the infoFromA delegated method. And after all the info is delegated, it will delegate to frameworkAFinished.
When the FrameworkA has delegated to the frameworkAFinished I start the next Framework: [FrameworkB start]. As the other Framework, it will initialize the library and present a view. While debugging, all the initialization of the library is done (create the instances of the needed objects and a new instance of the library is created) and while its presenting the view it goes through the viewDidLoad method and then it throws an exc_bad_access error at the problematicLibrary initialization line (which has been done before and continued to present the view!!) without going into any other method from the view.
I have checked if the initialization is doing well, and all the variables were at null value before the initialization, and a new memory address is given to the library object.
This sounds strongly like a symbol conflict to me. I'm just surprised the linker didn't catch it, but I assume that's because you're using a static library in both your frameworks instead of simply yet another framework.
Generally speaking, I'd warn that "this is a bad idea™". What you're trying to introduce into your design is basically dependency management. Like a lot of blog articles and specifically this SO answer suggest, you should avoid packaging frameworks (and by extension libraries) into frameworks.
What most likely happens in your scenario is this (I admit I'm guessing a bit here): You linked the library into Framework A. Thus, the library becomes a fixed part of it. Its symbols are in it, even if you did not expose them to the app in any header files or the like. As long as you use only that, everything works smoothly. Then comes Framework B, of which the library is also a fixed part. Even though you can't see it from your app, the very same symbols are inside it. This, however, clashes with the symbols that were already loaded by Framework A, hence a crash (as said, this would usually be caught by the linker, but I guess you "tricked" it by building the frameworks beforehand and packaged the library in them). Maybe somebody else can explain this in more detail, but that quickly becomes besides the point as to how you would go for a solution. From how I see it, it just won't work this way.
So here's a suggestion for how you can solve your problem:
If you really, really need to split like this (two frameworks used in your app using the same dependency), I'd suggest removing the library from the frameworks (i.e. make them depend on it, but not package the actual .a file in them) and documenting that properly. Then add the library to your app project, just like you added the frameworks.
If you want to make this fancy and easily installable into other apps, I'd recommend setting up a private CocoaPods repository and turn your frameworks into private pods. You can then easily define the library (or rather "new Framework C") as a dependency for Framework A and Framework B. When you then pod install in your app, cocoapods figures out the dependency and adds Framework C automatically to your project. This scenario is exactly what cocoapods (or any dependency manager for that matter) was designed for. It automates and helps in the project setup, so that the final build (the app) doesn't have to figure out dynamically what it can and can't use. The end result is the same.
Trying to duplicate that "in code" quickly becomes messy. Frameworks trying to figure out things of the surrounding app/project that uses them (like "is my dependency so-and-so already linked? if not, can I load my own version of the library?") can lead to a lot of pain.
Okay, in response to your comment I'll try my hand at a more detailed How-To for the non-cocoapods setup. As a preface, though, let me say that that's kinda hard to do on top of my head, as I have no ready sample project to toy around with. Since this is one of those "set it up once and then forget aout it for a long time" I have to admit my recollection of these things is a bit fuzzy, so consider this as a sort of "rough direction". There might be things you need to configure differently than how I recall them. Other SO user are thus hereby invited to edit and correct my answer here, too. :)
First, I have to say I am not exactly sure whether you need to convert your static library into a framework or not for this, I think you don't so I'll go from here (I have never used a static library in that way).
That means you can leave the project that builds your library as is. On second thought, you probably have to do this to be able to link against the library without making it a part of the framework that uses it. I will still refer to this code as "library" in the below points, but assume that you're able to turn it into a dynamic framework as well.
The projects building Framework A and Framework B should be changed. I don't know how you have this set up (as one project with various targets, whether you have a "development application" as part of it to test the frameworks on themselves, etc.), but the important thing is that in the target that builds a framework, the library should be linked (i.e. in the "Link Binary With Libraries" build phase), but not copied (i.e. it must not be in the "Copy Bundle Ressources" build phase). It might be tricky to set up any development/test target you use to run, depending on how you did that so far. For example you might have to manually edit Library Search paths in your build settings to be able to properly compile the framework.
Lastly, you need to change your final app's project settings, obviously. The library that was originally part of Framework A and B now needs to be linked to from its project directly, and, obviously, it needs to be copied into the bundle as well. Note that any projects that include either of your frameworks (A or B or both) in the future must do so, otherwise they won't work, because these frameworks expect the library to be present (but no longer "bring it with them").
In spite of this long-ish text wall, it shouldn't be that complicated, I think, but you may still want to check out how cocoapods can support you with something like this, perhaps it's helpful in the future. The linked article expects basic knowledge on how to use a pod and write one, but the other guides on the site explain that pretty well. I am just saying this because in the end, when using cocoapods in a project to add multiple libraries/frameworks that introduce dependencies, it basically sets up your project in the way I described above. It uses some fancy shell scripts that ensure everything is copied to the correct folders and such, but overall speaking that's how it works: A pod's podspec tells cocoapods what additional pods to include in your app for it to work (a dependecy the pod expects to be there, but doesn't "bring in" by itself).
Check if they are both compiling for the same target.
Check if they have access to the same target membership.
Check build phases to see that they are both there.
I think because the first library is not 'well' referencing the second one.
Also i think that you can't import a framework inside another one.
To make things easier, you can merge the two frameworks on a single one.
Also you can add a callback (using protocols or closures) that informs for the end of the first workflow, and you use this callback to initialize the second framework. This way the initialization will not be made automatically.
I have two iOS projects and I want to make it as a single project and run one project at a time depending on a condition.
For example : I have 2 projects named ProjectA and ProjectB.I want to embed ProjectA and ProjectB into a single project named ProjectC.
ProjectC will have a condition depending on the condition I have to run either projectA or ProjectB code.
Note: Condition to run a project will be applied on runtime not on compile time.
I doubt is this really possible ? I need expertise guidance on how to approach this problem.
I would suggest that you create pods and call your project, you can call it based on scenario/use-case, like this you can keep any number of projects in your pods.
You can refer this link.
Another way is to keep your two projects in same path, create dynamic frameworks and use those references into project 'C' I mean the new project which you are planning for
Any one of the approach should solve your problem.
Okay, so based on reading the question and asking some questions ... it really isn't clear to me why the answer regarding pods has gotten so many votes. It does not solve the problem.
Let's say we have existing ProjectA and ProjectB. ProjectC is not yet in existence, but the desire is to make ProjectC be a "combination" of A and B where A or B will be run based on some condition. Once run, the app will stay running that version until re-launched.
Two basic approaches would be to either combine all the code and assets into ProjectC or trying to make A and B frameworks which you load. However, with either scenario, you are going to have make adjustments to your code base. The amount of work you will need to do is also a byproduct of how complicated the projects are.
I've worked on a project where we successfully did what you wanted for a large app. We essentially made a "universal app" by taking our iPhone and iPad projects, combined the code/assets. We "launched" the appropriate version at runtime.
Before you go down such an effort, you will need to weigh the consequences. I'll list a few.
If you have A/B have a dependency on bundle id, you're going to have issues. ProjectC will have it's own bundle id. For example are there any 3rd Party APIs (eg. Facebook) in use where you would want to still use them and look like ProjectA or ProjectB? If yes, but they are tied to bundle id, you'll have issues.
If you are using IAP, your product ids will need to be different. So obviously the code in A and B will need to change if those product ids are hardcoded. If they are server driven you need to ensure the server code and actually deliver the right product ids. If there is an expectation that an owner of ProjectA should still have their IAP for ProjectC, this is possible ... however the cost comes to needing server side logic on your size to manage this.
How much effort do you want when debugging the code?
Are ProjectA and ProjectB still in active development? Doing this may very much make those projects very difficult to maintain afterwards.
How much time will be set aside for this? Doing this is tedious and takes time.
You would probably get more success combining source/assets of both A and B into C. In other words you will not be adding the project files for A or B into C. Why? Because you need to be able to easily identify all the conflict points and then provide a work around. A simple example of a conflict is AppDelegate, which is what project creates by default. You'll have 3 of them (A, B, C).
Keep in mind all approaches are fraught with issues. If you go for frameworks (regardless if they are Pods or not) and you decide your assets go into the framework bundle, you have to change your code to access them, as they are no longer in the mainBundle.
Okay, what are the general guidelines?
Choose a methodology (eg. combine or framework). I am going to discuss combine.
Determine as much of your conflicts up front. For each type of conflict determine your strategy. For example, to solve AppDelegate you could always do ProjectAAppDelegate and ProjectBAppDelegate.
Examine the Info.plist. This is a good source of other conflicts. C's Info.plist will be a combination of the two.
Come up with a strategy for how you will deal with conflicts. For example, we had a naming convention we would use when we had class names that conflicted.
Add your ProjectA and ProjectC source code/asset into Project C. Start to fix conflicts.
Drink a lot of coffee.
One of your other key things you will need to get control of is your entry point based on the decision. If you can decide before calling UIApplicationMain in main.m, you could do something like:
Class appDelegate;
if (runA) {
appDelegate = [ProjectAAppDelegate class];
} else {
appDelegate = [ProjectBAppDelegate class];
}
return UIApplicationMain(argc, argv, nil, NSStringFromClass(appDelegate));
IF this does not work, then you'll have to do this in - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions. You'll probably want to then have Project C's AppDelegate be a proxy for A and B. For example:
- (void)applicationDidBecomeActive:(UIApplication *)application {
// Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
[self.projectAppDelegate applicationDidBecomeActive:application];
}
where projectAppDelegate was set to the right version you need.
Note you will also need to manually load your storyboard to make sure the right one is launched. And keep in mind that if you spend to much time making your decision during loading (you said it was a network call) your app can be booted.
You may be able to find some nifty dynamic loading you could do if they were frameworks, but the key should be maintainability/ease of debugging.
I'm going to stop here mainly because there are so many different things to do and I really I don't have the time to write them all out.
Additional info based on follow up question
Odds are high that you will have some file duplication. I gave the example of AppDelegate. enum will be less frequent, but will occur. Also keep in mind, it is not the file name you care about, it is the class or other defined data type you are concerned about. Those are the conflicts that matter to the compiler/linker.
For example say:
ProjectA:
typedef NS_ENUM(NSInteger, State) {}
Project B:
typedef NS_ENUM(NSInteger, State) {}
This was what I meant about having a strategy ahead of time. Example strategies:
ProjectA is the "winner", and hence only ProjectB will have changes
ProjectB is the "winner", and hence only ProjectA will have changes
Both Project A and Project B will have changes.
So for 1, the result would be
ProjectA:
typedef NS_ENUM(NSInteger, State) {}
Project B:
typedef NS_ENUM(NSInteger, PBState) {}
Note what I did hear. To make my life easier I used some pre-defined prefix to designate it is ProjectB. In this case PB.
For 2:
ProjectA:
typedef NS_ENUM(NSInteger, PAState) {}
Project B:
typedef NS_ENUM(NSInteger, State) {}
For 3:
ProjectA:
typedef NS_ENUM(NSInteger, PAState) {}
Project B:
typedef NS_ENUM(NSInteger, PBState) {}
It will be up to you to make the rules, but be consistent.
You will need a strategy for how you will resolve all the data type changes. For example, if you are going from State -> PBState, you obviously only want to modify ProjectB. Here is where having it in it's own project would help. However, you can use Xcode's Search Scope to help control this.
Oh some other things.
Up front, invest on a script to find all the duplicate files in ProjectA and ProjectB. You basically need to do a find on ProjectA and ProjectB based on the extensions you need (eg. .m, .h, .xib, etc). This will give you a list of potential candidates and from there you can strategize on rules.
As I was the sucker that did this part of the project, I basically kept this list in a text file. When I consolidated the file, I moved it to a different section (separated by several newlines) in the file. There are diff ways of doing the accounting on it, it is simply the method I chose.
I would also make sure you have a good diff tool like Araxis Merge (which is what I used).
Also, take frequent snapshots just in case. You can use git branching. I often just copied the actual directories so I could diff them later if needed.
I am currently migrating a large RAD Studio 2010 project to XE4. As part of this, I am recreating many of the project files. I would like to take the opportunity to ensure we are using the best possible mechanism for precompiled headers, since there seem to be a few ways to do it.
Right now we are compiling for 32-bit only but will use the 64-bit compiler in future.
Here's what we're currently doing in 2010, and why I'm unsure about what to do in XE4:
In RAD Studio 2010
We have a file PchApp.h which includes <vcl.h> and a number of other commonly-used header files, mostly headers for various commonly-used core classes in the project. This header is included at the top of every CPP file followed by #pragma hdrstop, like so:
// Top of .cpp file
#include "PchApp.h"
#pragma hdrstop
// Normal includes here
#include "other.h"
#include "other2.h"
// etc
We then have the following settings in the Precompiled Headers section of the project options:
It is not particularly fast to compile (12 minutes for circa 350,000 lines of code.) I am unsure about:
"Inject precompiled header file": should this inject PchApp.h?
"Cache precompiled headers (Must be used with -H or -H"xxx")": the -H option is the "PCH filename", so we are using it, but surely the point of a precompiled header is that it is "cached" or prebuilt once per compile. What extra difference does this make?
Should we have the two lines to include PchApp.h and the pragma hdrstop in the .cpp files? Is there a way to do this in the project options only, and not duplicate these two lines in every single file? Are they necessary?
In other words, I am not sure these are correct or optimal settings, but from reading the documentation I'm equally not sure what would be better. I am aware I don't understand all the options well enough - one reason for this question :)
In RAD Studio XE4
The XE4 32-bit compiler's options dialog is the same, but two things confuse me and/or make me uncertain the current 2010 approach is the best.
1. Default behaviour
When creating a new VCL Forms project, the IDE creates a header named by default Project1PCH1.h, which is intended to be the project's precompiled header. This header includes <vcl.h> and <tchar.h>, and is shown as a node in the Project Manager. It is not included in the default Form1.cpp, but #include <vcl.h> followed by #pragma hdrstop is at the very top of Form1.cpp, followed by other headers.
The default XE4 settings dialog for a new project using this header is:
I am (naively?) working on the assumption the defaults are actually the best / most optimal settings. Some things puzzle me:
The project's supposed precompiled header Project1PCH1.h is not mentioned in the precompiled header settings anywhere.
The headers aren't cached
The PCH filename isn't specified (should this be Project1PCH1.h?)
The .cpp files don't include Project1PCH1.h either.
In fact I have no idea how the compiler or IDE actually know that it is supposed to use Project1PCH1.h or for which .cpp files it is supposed to use it, since it isn't referred to in any way I can find.
This is the most puzzling thing to me, and the spur to ask this question and clear up all my confusion about PCHes. I had planned to copy/use the IDE's default settings, but I don't want to until I understand what they are doing.
2. PCH Wizard
Since 2010, the IDE has included a precompiled header wizard. I haven't ever been able to get it to work - I am running it again right now to get its results and explain my memory of "doesn't work", but it seems to take several hours, so I will update this question later.
Edit: it runs, though it takes several hours, and produced a list of (to me, knowing the source base) odd headers. My recollection of trying it several years ago is that it didn't run at all - a definite improvement.
Since it exists, it may be the best way to set up using precompiled headers in a newly created project file formed to upgrade the 2010 project. How do I best do so? Will all the .cpp files including PchApp.h confuse it?
Questions
With that as background, I have the following questions:
Existing settings. I am creating a new project file and adding thousands of pre-existing .cpp files, all with "#include PchApp.h; #pragma hdrstop" at the top. Should I copy the existing RS2010 PCH settings? Should I remove the above two lines and replace them with something else?
Using the PCH wizard: Does this, in your experience, create optimal settings? Does it include files that, if modified, will cause large areas of the project to be rebuilt (probably non-optimal for coding)? Is it possible to use on an existing project, or do items like our "#include PchApp.h" need to be stripped out before using it?
CPP files / units and the correct includes. Should .cpp files that use precompiled headers not include the precompiled header itself, but only the headers that the .cpp actually needs, even if the PCH includes those? What if you have our current situation, where the PchApp.h file includes several common headers and so the .cpp files don't actually include those themselves? If you remove the inclusion of PchApp.h and replace it with the subset of headers in PchApp.h that the specific .cpp files needs, should they be above or below the #pragma hdrstop? (Above, I think.) What if you then include something else above with them which is not included in the precompiled header - will it change PCH usage for that specific unit, cause the PCH to be rebuilt (performance issues?), etc?
Default setup: Assuming the default setup for a new project is optimal, how is best to migrate the current system to using it?
Non-default setup: If the default setup is not optimal, what is? This, I guess, is the key question.
32 and 64-bit: Knowing that we'll move to 64-bit soon, what should we do to have precompiled headers work on both 32 and 64 bit? Should all PCH knowledge be in the project options rather than .cpp files, so different settings for 32 and 64-bit compilation?
I am seeking a clear, detailed, explanatory, guiding answer, one that clearly explains the best
practice, setting options, items to include in the .cpp
files, header, and/or project file, and so forth - in other words, something to clear up my by now (after all the above!) rather confused understanding. A high-quality answer that can be used as the go-to PCH reference in future by other C++Builder users in future would be excellent. I intend to add a bounty in
a couple of days when I am able to.
Existing settings. In my experience I have changed these settings usually, because if you have hundreds of files - it's just does not seem to be optimal. In xCode i.e. it's the default configuration. There should be no compilation performance difference.
Using the PCH wizard Honestly I have never used it in real project, and it haven't impressed me, so just forgot about that and used manual settings.
CPP files / units and the correct includes. Different IDEs have different default settings for that. What I have usually used is:
Inject precompiled headers automatically (no manual #include in .cpp)
First include appropriate header matching .cpp if one exists (myfile.cpp - then include myfile.h)
After that include all the specific headers that do specific job (specific lib headers, etc.)
In "myfile.h" include ONLY stuff that is a must. Avoid any stuff you can avoid.
Everything you include specifically for a particular .cpp file should be below #pragma hdrstop. Everything you want to be precompiled should be above.
Default setup I don't think it's optimal. As for me it's much easier to migrate just changing a couple of options in the settings.
Non-default setup As I have mentioned above - as for me the optimal set up is with automatic injection of precompiled header. More details in item 3.
32 and 64-bit haven't experienced any problems with that. It should generate own precompiled headers for every particular configuration.
Here's what I do (although I am not sure if it is a good idea or not but it seems to work)
Make sure Project1PCH1.h exists (where Project1 is the name of the project)
Make it contain #pragma hdrstop and 2 trailing newlines (I got weird errors when I didn't have trailing newlines, maybe compiler bug)
In "All Configurations" put into "Inject precompiled header file" then name "Project1PCH1.h"
Do not do anything such as #include "PchApp.h" nor #pragma hdrstop in the other files.
Check everything builds correctly (i.e. files have the right includes on their own merit, not relying on the injected PCH)
Put some includes into the Project1PCH1.h. I use the wizard to come up with some suggestions, but you have to apply some human logic as well to get a good build.
When it's working properly in 32bit mode everything compiles lightning quick; you can tell if you have not quite got something right if you're compiling your project and one particular .cpp file takes a lot longer than the rest. The wizard makes suggestions based on how many files include the given header, but that's somewhat bogus; you need to include in it any system header (or boost header etc.) that would add significantly to the compilation time if it were not part of the PCH.
I don't bother to include my own project headers in it, just system and standard headers. That may differ for you depending on your project, IDK.
The PCH doesn't work for .c files so if you have any of those in your file you'll need to make Project1PCH1.h have #ifdef __cplusplus guards.
Also: even though bcc64 doesn't support PCH (but it does inject the file), if you do have your PCH set up right it does seem to make compilation go a fair bit faster, I'm not exactly sure why.
Things I don't understand about it yet:
Why does the New Project wizard autogenerate Project1PCH1.h but not actually set that in the "Inject Precompiled Header" field of Project Properties?
Sometimes the build fails saying it cannot open Project1PCH1.h but if I make some changes and re-save it it usually seems to fix this.
Beyond allowing one file to use another file's attributes, what actually happens behind the scenes? Does it just provide the location to access to that file when its contents are later needed, or does it load the implementation's data into memory?
In short;
The header file defines the API for a module. It's a contract listing which methods a third party can call. The module can be considered a black box to third parties.
The implementation implements the module. It is the inside of the black box. As a developer of a module you have to write this, but as a user of a third party module you shouldn't need to know anything about the implementation. The header should contain all the information you need.
Some parts of a header file could be auto generated - the method declarations. This would require you to annotate the implementation as there are likely to be private methods in the implementation which don't form part of the API and don't belong in the header.
Header files sometimes have other information in them; type definitions, constant definitions etc. These belong in the header file, and not in the implementation.
The main reason for a header is to be able to #include it in some other file, so you can use the functions in one file from that other file. The header includes (only) enough to be able to use the functions, not the functions themselves, so (we hope) compiling it is considerably faster.
Maintaining the two separately most results from nobody ever having written an editor that automates the process very well. There's not really a lot of reason they couldn't do so, and a few have even tried to -- but the editors that have done so have never done very well in the market, and the more mainstream editors haven't adopted it.
Well i will try:
Header files are only needed in the preprocessing phase. Once the preprocessor is done with them the compiler never even sees them. Obviously, the target system doesn't need them either for execution (the same way .c files aren't needed).
Instead libraries are executed during the linking phase.If a program is dynamically linked and the target environment doesn't have the necessary libraries, in the right places, with the right versions it won't run.
In C nothing like that is needed since once you compile it you get native code. The header files are copy pasted when u #include it . It is very different from the byte-code you get from java. There's no need for an interpreter(like the JVM): you just feed it your binary stuff to the CPU and it does its thing.