When I'm using big frameworks like the Three20 Framework,
I always have the choice whether to #import the whole framework or to #import only the single file of it i'd need.
I guess there's a difference in compilation-overhead since it has to open all files of the framework, but is there also a run-time difference? like bigger memory-usage? Or does the compiler-optimization already remove everything that's not needed?
And if I use the same framework pretty much in every class I use, is it recommended to include the framework in the prefix file instead of every single class?
Greetings
Infinite :)
There will be a compilation difference, yes: including everything will take longer to compile. But there shouldn't be a run-time difference.
Your idea of including the framework in the prefix is a good one for frameworks you're going to be using throughout. However, there is a catch, which is that if you change something in that framework your entire codebase will have to be recompiled.
There is no performance hit in runtime. No matter how many frameworks or files you import, if you don't use whichever classes they won't affect the resultant bytecode when you compile. The compiler doesn't even optimize anything; unused classes just "aren't there" at all.
Include the framework in the precompiled header file if you're sure it's going to be necessary.
You footprint won't be any different unless you actually use the classes however I prefer to be more frugal with my headers, only including the ones I need. If I need a lot from the same library (like Three20) then you can add the whole reference.
Only include headers in the prefix that don't change much, but it will speed up compilation greatly.
Related
I am creating my first Swift framework and I notice there is a default .h file (Obj-C). What purpose does it serve in a Swift Framwork? Can it be removed without causing problems?
It is a bridging header to make sure everything plays nice with Obj-C frameworks. You may be okay deleting it depending on the intended use of your framework, but it won't hurt anything to leave it in so that's what I would recommend for best practice and to make sure you don't accidentally break anything in different contexts that you use the framework in.
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
So, Not a very sophisticated question, but since I never did it before I need your advice.
I have my main project, which includes 2 more sub projects that produces static libraries that the main project uses.
Now, I want to add a Loggin framework to my project, and I want to be able to use it inside my main project and inside my static libraries as well.
As you can witness here, it's not very hard, only 3 files needs to be included.
However, I'm not sure what's the best way to do it.
Adding those 3 files to each of the projects would probably cause symbols redefinition.
Adding to just one of the static libraries is not enough, unless I make the other one dependent on it, which is not quite correct logically.
I can probably make another static library project from these 3 files, and make my project and my 2 other sub projects dependent on it, but it feels like an overkill.
What's the best course of action here ?
Thanks!
Putting those files in yet another separate library or framework would be my take.
You should perhaps reconsider if you really need your sub projects precompiled in static libraries (what advantage is that providing to you? are they really that huge that recompiling them now and then is that bothersome?).
A single Xcode project with everything on it might be a better solution, and is what I usuallly favor these days. That way you also don't have to worry about missing architectures in your libs or having compiled the lib with a compiler version and the main project with another, bugs within the libs can be debugged and traced more easily, etc…
TL;DR Version:
This question has arisen due to the fact that I have multiple frameworks (which I have built) and a client project that uses said frameworks. Now, when I open up the client project and try to debug into the framework, it doesn't work.
However, if I have the project associated with the framework open, then debugging appears to work (though there are some weird issues with breakpoints I don't see being triggered).
I have looked at Apple's docs, and perhaps the answer is buried there somewhere, but I couldn't find it on a skim of the Xcode Debugging Guide.
Long Version:
The reason this question is important to me is that a coworker and I had a disagreement about how headers are imported in the frameworks we build.
I have a tendency to use framework headers (with client apps) in the fashion:
#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"
He, on the other hand, favors importing the framework headers (with client apps) like this:
#import "HeaderA.h"
#import "HeaderB.h"
and specifying the header search paths in the build target of the client application.
Complicating matters further is the fact that some of these frameworks have interdependencies. For example, FrameworkB has headers from FrameworkA referenced in his format:
#import "HeaderA.h"
His argument for doing this is that debugging only works if we import headers this way. It seems dubious to me that there would be a relation between header importing style and debugging, but I am not really certain how XCode chooses the file to link to during debugging, hence the question.
Thanks in advance for any assistance with this query.
you add project references to the target, and make sure Xcode knows where to find the debug symbols.
#import <FrameworkA/HeaderA.h>
that's the way to go (for internal and external declarations). the reason? the other approach is more likely to cause issues as libraries evolve. the additional qualification disambiguates any case (unless of course there are two FrameworkA/s in your search path), it's best to qualify the file explicitly now, rather than when your clients tell you they cannot use your library with other libraries, or that they can only use them in some conditions. then you have to go fix the issues and reship (this stuff has a way of happening at inconvenient times =p). it's one simple measure to ensure you've developed a robust interface.
perhaps the most important part that people overlook is the location of the products: use a customized central build location for your targets -- many people use the default location, which is by the xcodeproject. otherwise, Xcode may not be able to locate debug information.
finally, debugging complex projects in Xcode can be quite... let's call it 'problematic'. So don't expect the debugging experience to be perfect, even if you've configured everything correctly. all the more reason to integrate assertions and unit tests into your development cycle early on with Xcode. truth is, the debugger may be useless no matter how hard you try - this is not a new issue. hopefully LLDB will improve our debugging experiences.
good luck
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.