I am trying to port a Windows FileMaker plugin to OS X and am thinking that I should be doing this in Cocoa not Carbon,
but I am struggling to get anything to compile as soon as I include Cocoa.h
Are you importing it into a .c file? Cocoa requires Objective-C, so you'll need to rename any files you want to import its header into from .c to .m.
Of course, how practical that is depends on FileMaker's plug-in API on the Mac (assuming it has one). If the API, including UI hooks, is entirely Carbon-based, switching the plug-in's source to Cocoa may be futile. I can't say for sure without knowing that API.
Actually the FileMaker Framework is C++. You can mix C++ and Objective-C code so you could use Cocoa instead of Carbon. Beware that the file would be .mm not .m
An Objective-C wrapper to the C++ framework would make it possible to use .m Objective-C. Unfortunately I'm totally ignorant of C++ (and expect to stay) so it is beyond my competence.
Related
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
Assume I'm developing a typical Mac or iOS application using Apple's latest Xcode tools. Further assume that I am primarily developing this application using Objective-C and leveraging all of the relevant APIs from Apple's Cocoa or Cocoa Touch frameworks.
Let's say that I don't currently have any plans to use C++ or Objective-C++ in my code base, but I suspect that some time in the future I might want to sprinkle in a little Objective-C++ here an there.
So I'm considering naming all of my .m files as .mm instead, just in case. (This will have the desireable effect of a cleaner history in my SCM system, as I won't have to rename files later.)
Is this a bad idea? Is there any reason why using .mm files is definitely or significantly worse than using .m when the file doesn't actually contain any Objective-C++?
Presumably this file extension flips some switch in the compiler which will then have to parse the source code for not only ObjC, but also C++. Does this have a significant negative effect on build times for moderate-to-large code bases?
Does it have any other negative (or positive) effects that I should keep in mind?
NOTE: please do not respond with any comments about whether ObjC or C++ is better. That is not what this question is about.
It's not the worst idea, but it's not really a good idea, either.
The main purpose of Objective-C++ is to act as a bridge for Objective-C code that needs to use a C++ library. Thus, in most projects, almost all of the code is plain old Objective-C, with maybe a few .mm files to create a "wrapper" object to talk to the C++ library.
Therefore, it is extremely unlikely that you will need to change significant parts of your code over from Objective-C to Objective-C++. You shouldn't have a lot of file renames in your SCM history.
The main problem with using Objective-C++ everywhere is that you will be following "the road less traveled": 99% of the tutorials you read and open-source code you use and learn from will all be written to be compiled by the Obj-C compiler. Using the Obj-C++ compiler will be mostly the same, and probably won't make a difference most of the time, but you will eventually run into some problem that is due to Obj-C++ being compiled slightly differently, but when you find the bug it won't be obvious, and you'll spend a lot of time trying to diagnose it before you realize that it is because you are using a less well-tested compiler setup.
If you have a lot of C++ experience and find yourself "needing" features from C++ in your code, you probably don't really need them, you probably need to spend a little more time figuring out how to do the equivalent in Objective-C. When in Rome, do as the Romans do.
In general, "just in case" is not a good reason to stray from standard practice. You often wind up spending a lot of effort on something you aren't going to need.
Quote from Barry Wark:
The major disadvantage to using .mm over .m for "normal" Objective-C
is that compile times are significantly higher for Objective-C++. This
is because the C++ compiler takes longer than the C compiler. With
Xcode 3.2 and higher, Objective-C code can use the Clang frontend tool
chain to significantly speed up Objective-C/C compiling times. Since
Clang does not yet support Objective-C++/C++, this further widens the
gap in compiling times between the two.
BUT
UPDATE Feb 17, 2012 As of Xcode 4.0 (with LLVM 3.0), Clang has
supported Objective-C++. Even C++11 support is quite strong now.
So I think that its ok to use .mm as long as if you only use C features, .mm files should generate code that performs very similar to .m
As I wrote in a comment, C++ is not a strict superset of C, so it's possible you'd run into cases where you use e.g. C99 code which will not compile if you put it in an Objective-C++ file. I had this problem recently using C99 compound literals.
Yes, it's bad idea.
When I see a .mm file, I expect it to have C++ code (in addition to Objective-C of course). There are a few things not directly related to OOP that are a bit different in C++ comparing to C.
So name all your Objective-C files as .m. As soon as you need any C++ features – rename it to .mm and verify that everything works.
You get bonus points if you keep your header files C++–less.
.mm extension means Objective-C++ file. Compiler takes more time to compile c++ code than C code.
So, if it is not required, keep the extension as .m only.
From my experience (at Apple):
1) the xcode team thinks about c++ last (took forever to get blocks support in objc++)
2) objc++ is much slower in compiling
Using Delphi XE2 we can export sources into xcode and compile them with free pascal compiller. But all examples i'v ever seen dont modify .pas files in xcode, just export and run.
I wonder if I could add any delphi units or libraries into Objective C application and compile them together? How to include .pas unit into .xcodeproj?
I wish to port delphi application to iOS, exporting all project is impossible, it seems a good idea to make a GUI for iOS in native ObjectiveC and import logic and methods from delphi units. Is it possible?
Since Delphi XE2 is using the Free Pascal Compiler when targeting iOS, you can use any programming technique of FPC.
In fact, if you do not need FireMonkey, and prefer using native User Interface, you do not need Delphi XE2 at all!
You can use the free FPC to compile your application from XCode.
The best reference web site is http://web.me.com/macpgmr/ObjP
In particular, "Developing with Objective Pascal" articles is exactly what you are looking for:
Develop the UI within XCode;
Use FPC to code your business logic in Pascal;
For both Max OSX and iOS.
See just the introduction page, and I suspect you'll be amazed, like I was.
From my POV, the "Object Pascal" paradigm used with FPC (i.e. object pascal "dialect", which can coexist with the default object pascal code) is more advanced, lightweight and integrated than the interface-based "plumbing" of Delphi XE2 compiler (with on-the-fly marshalling using RTTI). This is perhaps a matter of taste...
I am writing a Mac OS X desktop application in which I want to be able to parse fragments of Objective-C such as variable and method declarations, as well as full Objective-C header and source files.
It looks to me as if I should be making use of Clang to do this, but I could do with some pointers and examples on how to integrate it as a library in my project, and how to invoke it to parse strings and files.
Can anyone provide me with any help on this?
You probably want libclang, code browsable at http://llvm.org/svn/llvm-project/cfe/trunk/tools/libclang/ (though you'll need to checkout the entire Clang repo to build it). There's very little documentation around on it, sadly. There is a presentation at http://llvm.org/devmtg/2010-11/Gregor-libclang.pdf that might help kickstart things, but mostly just some hunting through the code is the way to go.
Clang is actually more modular than libclang provides for (you can import just the components you want). If you've adventurous, there are examples at http://llvm.org/svn/llvm-project/cfe/trunk/examples/.
I believe i can learn thing or two if i can see the implementation files (.m files). Is there any way the i can view NSString.m or NSNumber.m files? and others? If i try to find these files using spotlight, i get nothing.
No, most (all?) of the Cocoa library implementations are only distributed in a compiled binary form. You could disassemble them, but that's probably against the Mac OS X EULA, and it also wouldn't help you understand them at all.
You could take a look at Cocotron, which is an open-source implementation of Cocoa. It won't be exactly the same, but at least for the core classes, it will be virtually identical.
Many of the basic cocoa classes, like NSString and NSNumber, are implemented in core foundation and "toll-free bridged" to objective-c classes. Core foundation is a C (not ObjC) API and the source is available as part of the Darwin open-source project.
So, to see how NSString or NSNumber is implemented under the hood, follow the link above and take a look at CFString and CFNumber, respectively (you'll need an Apple developer account, but registration is free).
Also worth looking at the mySTEP sources.
This helped me when doing something that subclassed NSMatrix some time ago.
I would guess they are already compiled into libraries.
I just did a quick check on my mac and could not find a NSString.m file as well. Are you utilizing Xcode's documentation? I find it has most everything I need.