Are there any tools out there for Objective-C / Xcode? Something that can do one or more of the following:
Detect unused imports
Auto-synthesize properties
Autogenerate dealloc method from retained properties
Provide method stubs for interface
-Detect unused imports
Not sure of anything that checks for dead imports.
-Auto-synthesize properties
-Autogenerate dealloc method from retained properties
User Scripts work quite well to do this inside Xcode, you can also use a program like Acessorizer as mentioned but it pastes something onto the clipboard for you to paste.
-Provide method stubs for interface
type "init" just after #implementation, and type Control-. (period).
These are user macros (not scripts), and you can easily define your own. Note they have placeholders that you can use tab to jump to the bits to fill in.
You want to look at Kevin Callahan's Accessorizer, which can do several of the things you request and more. The Google Toolbox for Mac also includes an Xcode plugin that can remove whitespace and a few other things.
You could probably do something with AppleScript or another scripting language, called via AppleScript, to operate on method or header files.
If you want static analysis, Clang is built in to all recent releases. None of what you've described has anything to do with static analysis, however.
Related
As the title says.
I use a couple of scripts that extend the Unity editor functionality, like SceneAsset class or TagSelector attribute, but now I just realized I can't build my project because of them and now I have to delete all of these and replace them with normal string and fill it myself, which I was avoiding until now.
Do I use these classes only for development? I know I can use #if UNITY_EDITOR #endif so part of the code will only work if built via Unity Editor, but in my case, this seems ugly because I want to declare fields via the inspector. Do I have to declare multiple fields for the same thing and separate the usage or is it possible to make two versions for one field so I don't have to change the code?
You can't have anything using UnityEditor in a build since this namespace is completely stripped of.
You only use it so you can implement editor scripts that simply only extend the functionality of the Unity Editor itself ... custom Inspectors/Windows etc.
Make sure you
Either put these in folders called Editor! these are excluded from the build automatically
Or use the pre-processors as you mentioned
Serialized fields should be used for both, editor and build (otherwise you will always get some warning about mismatching serialization layouts). If you need them for the editor, just keep them for the build as well even if they are not really of use there - they don't hurt and nobody will see them anyway.
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.
I have an NSLog alternative that outputs the class it's called from as well as the line number and method (selector) called PLog in a class called PLogging. It's the exact same as the DLog taken from here with the exception of the name change. The advantage of DLog as it is written is that when compiled under Release mode, the log call is changed to a comment, negating the performance impact you would otherwise be subject to. I want to be able to use this and keep it within the framework, but be able to call it from the projects I add the framework to. But still have the log calls compiled to comments when in Release mode. Is this possible?
I would suggest a white list approach: add a preprocessor definition to your debug configurations which enables DLog/Plog to log to the console. In every other case it turns to comments.
Please have a look at this blog post which seems to point a finger at your problem. Of course, assuming that you don't want to change the way you are achieving your functionality: macros. I'm quoting abit: "An example of the basic problem is you want to link to a library that has both a Debug and a Release version. So in your application you want your Debug version to link to the Debug version of the library, and you want your Release version to link the Release version of the library."
I would rather tend to use targets for that, the trouble does look uncomfortable.
Third-party frameworks aren't allowed by the App Store. I assume you've got a static library or source files that you add to your apps with a cross-project reference?
If you've set your library project up with a debug flag set for your Debug configuration and unset for your Release configuration, then all you have to do is use the same configuration names for your app project, and the library will be built with the same configuration.
probably me be stupid, but i cannot figure out how to use namespaces in the iphone sdk. Please could somebody help me. basically I need to know where to define a namespace in the files, i assume in the header, but where? I keep getting errors.
Objective-C does not have namespaces.
As Daniel A. says, no namespaces in Objective-C.
It is common practice - and recommended by Apple - that you prefix your frameworks / packages with 3 letter codes. Apple uses things like UIKit, NSString etc.
So you could use DTHCoolClass etc.
Objective-C has no namespaces. What people do is prefix their code with some capital letters. Like initials or product name abbreviation. Personally I hate it and I use normal names like SignUpViewController instead of SMASignUpViewController.
In my opinion the world would be a better place if app developers dropped the prefixes. I'm ok with libraries using this.
As others have mentioned, Objective-C doesn't have namespaces. Apple recommends that you prefix your class names with 2 or 3 letters indicating the project, framework or developer.
In practice, whether or not you should prefix depends on what sort of class you are talking about, and how it is likely to be used.
I prefix all model and utility classes, since the names could clash with Apple's (or 3rd party) libraries (e.g. use NFResourceManager instead of ResourceManager, and NFRecord instead of Record). These sort of classes may be pulled out into another project framework at some stage in the future, so prefixing them allows you to keep the names unambiguous.
I almost never prefix view controllers, unless I think there's a good chance I'll use it elsewhere, or want to share it. The majority of VCs won't get used elsewhere, so there's little benefit of prefixing (and you're unlikely to have imported code from a 3rd party library that contains VCs).
For most view classes, I prefix them, unless it's highly specific to a particular project/app, in which case there's little point.
If you're trying to use namespaced C++ code within your obj-C files then you'll need to rename your source files to tell Xcode to use the C++ compiler. Rename the relevant .m files to .mm and you should be able to use C++ namespaces.
Me being a little stupid, i was trying to create the namespace in the wrong place
Being really new to wx, I'm wondering if there is an IDE (especially for Linux) which would help me lay out a frame or dialog or whatever just to help me see what I'm doing. That means also creating the code for those changes.
I remember way back when using resource compilers for OS/2 and Windows that produced binaries that would then create the window, and was hoping for something similar (though obviously not binary if wx doesn't support that).
I use wxFormBuilder. It is written in wxWidgets, so it works on Linux quite well. It can generate C++ code or XRC files. Make sure you understand its philosophy, and use it like this:
generate C++ code for the GUI
don't edit the code wxFormBuilder generated, but create new files
in new files, derive new classes from the classes it generated
implement event handlers in you own class (wxFB creates virtual function for each event handler you wish to use)
I usually name the wxFormBuilder generated classes/files like, for example, MainFrameGUI, and one with implementation (derived one in which I write all my code) would be just MainFrame. This enables you to change the visual layout and regenerate C++ files from wxFB at any time without overwriting your code.
DialogBlocks works quite well for me, although sometimes you need to edit the code to fix errors manually. It has a property editor that seems advanced enough.
Just another options is wxGlade. It does not have the that much features as the others mentioned seem to have, but it works just good enough for me to not daring to switch.
I use Code::Blocks IDE from http://www.codeblocks.org which has
- built-in GUI editor
- Cross compilable, so you can use it under Linux, OSX and Windows.
But I still use wxFormBuilder with it instead of built-in wxSmith editor. But they are compatible with internal wxSmith.
For windows you've got "wx-devcpp" which is Blodsheed Dev C++ with some addons providing what you looking for
Here is project page
http://wxdsgn.sourceforge.net/