Concise description of how .h and .m files interact in objective c? - objective-c

I have just started learning objective C and am really confused how the .h and .m files interact with each other. This simple program has 3 files:
Fraction.h
#import <Foundation/NSObject.h>
#interface Fraction : NSObject {
int numerator;
int denominator;
}
- (void) print;
- (void) setNumerator: (int) n;
- (void) setDenominator: (int) d;
- (int) numerator;
- (int) denominator;
#end
Fraction.m
#import "Fraction.h"
#import <stdio.h>
#implementation Fraction
-(void) print { printf( "%i/%i", numerator, denominator ); }
-(void) setNumerator: (int) n { numerator = n; }
-(void) setDenominator: (int) d { denominator = d; }
-(int) denominator { return denominator; }
-(int) numerator { return numerator; }
#end
Main.m
#import <stdio.h>
#import "Fraction.h"
int main(int argc, char *argv[]) {
Fraction *frac = [[Fraction alloc] init];
[frac setNumerator: 1];
[frac setDenominator: 3];
printf( "The fraction is: " );
[frac print];
printf( "\n" );
[frac release];
return 0;
}
From what I understand, the program initially starts running the main.m file. I understand the basic C concepts but this whole "class" and "instance" stuff is really confusing. In the Fraction.h file the #interface is defining numerator and denominator as an integer, but what else is it doing below with the (void)? and what is the purpose of re-defining below? I am also quite confused as to what is happening with the (void) and (int) portions of the Fraction.m and how all of this is brought together in the main.m file. I guess what I am trying to say is that this seems like a fairly easy program to learn how the different portions work with each other - could anyone explain in non-tech jargon?

People who come from other environments always seem to belive that something complicated is happening with the .c, .m, and .h files used in C and Objective-C programming.
Actually, its very, VERY simple.
For the purpose of buiding a project Integrated Development Environments - like XCode - ignore all the .h files. What they do do is to take each .c and .m file and compile it. If the programmer (thats you) has used any #include, or #import directives, the compiler inserts the entire text of the included/imported .h file where the directive was.
So, if you had a .h file - insert.h - that said:
in
And a .c file that said:
Alice
#include "insert.h"
Wonderland
The compiler would, after processing the #include & #import directives, see this:
Alice
in
Wonderland
It is this very VERY simple file merging behavior that we use to make complicated programs :)
.h is very simply a convention by which programmers can tell each other that the file is suitable to be merged in - potentially multiple times - using #include or #import.
The .c and .m files are not merged like that. Each .c and .m file is compiled seperately - to produce .o files. Each .o file is a collection of compiled functions. The .o files are then merged - or "linked" - to produce the final program.
The linking step ensures that each function exists only once, and that all functions that are called do in fact exist somewhere.
C & Objctive-C define one special function that must exist somewhere - main(). Again, the language is very relaxed - it doesn't care which .c or .m file the main() function is in. Merely that it exists in some file somewhere.

You need to take a look into Object Oriented Programming and perhaps read a little more into Objective-C development to get a good grasp on the concepts of OOP etc
To answer your question "what is the difference between .h and .m files", .h files contain the declaration for your class, so basically all of attributes and methods that it can utilise. The .m file is the implementation of these methods.
In laymans terms, the header file (.h) is the a way of saying "This is what I can do" and the .m is "This is how I do it". It's a little more complicated then that though.

The files don't interact at all, using them is merely a convention, you could also put everything in the main.m file.
A good starting point for learning Objective-C is the introduction to the Objective-C language.

In a nutshell, an Objective-C class is a C struct. An instance is a reference to such a struct that has been allocated in memory. A class has a name and an instance has a state or value.
The thing that sets an Objective-C class apart from a C struct is the ability to look up method addresses by name. In simplified terms, the struct has a hash table of function pointers keyed by name.
There are lots of other niceties in Objective-C objects, like reference counting, but calling methods by name is the crux of it. A SEL is a C string, but a C string is not a SEL.
As far as header and source files, by convention you declare the interface to a class in header files and define the methods in a source file. Defining things, other than types and constants, in a header file is a bad practice, as is including source files. You are free to declare anything you want in a source file, but it is essentially private to the source file.
A C executable, and thus an Objective-C executable, has an entry point at the main function. By convention main is defined in a file with the same name in Objective-C projects.

The below lines of code in Fraction.h are not nothing but getter methods. They are not redefining the two int variables declared above them.
- (int) numerator;
- (int) denominator;

Related

Can an Objective-C implementation be defined in a header file and also be imported by multiple source files?

I am aware this is not standard or conventional, please read on. I have a header file that defines the interface and implementation of an Objective-C class.
Person.h
#ifndef Person_h
#define Person_h
#interface Person : NSObject
-(void)speak;
#end
#implementation Person
-(void)speak
{
// Say something
}
#end
#endif /* Person_h */
I also have two source files that both include the header file.
Main.mm
#import Foundation;
#import "Person.h"
int main(int argc, const char * argv[])
{
// Do nothing
}
Test.mm
#import Foundation;
#import "Person.h"
When the project is built, I get duplicate symbol errors.
duplicate symbol '_OBJC_CLASS_$_Person' in:
/Debug/TestBox.build/Objects-normal/x86_64/main.o
/Debug/TestBox.build/Objects-normal/x86_64/test.o
duplicate symbol '_OBJC_METACLASS_$_Person' in:
/Debug/TestBox.build/Objects-normal/x86_64/main.o
/Debug/TestBox.build/Objects-normal/x86_64/test.o
ld: 2 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I want to be able to include the same header file in multiple source files. In C++, I can inline the implementation into the header file like this:
#ifndef Person_h
#define Person_h
class Person
{
public:
void speak()
{
// Say something
}
};
#endif /* Person_h */
However, I haven't been able to find a way to do that with Objective-C. I'm using Objective-C so I can subclass events from NSWindowDelegate and NSResponder.
I tried searching for solutions. Most of them said to separate the implementation into a source file, but that would break the single-header architecture. One suggestion is to use the Objective-C runtime library and create my classes at runtime. This appears to give me the results I'm looking for, but I'm wondering if there is a simpler way.
Is there some way to implement an Objective-C class in a header file so it can be included by multiple source files? Or is dynamically creating the classes at runtime my best option?
Update
I am looking for a solution that avoids using a .m or .mm file to write the Objective-C implementation. Even if doing so is not the conventional way to do it. The single-header file is required by the architecture of the project I am working on. The project is cross-platform, and the single-header design isn't an issue in C++ on Windows and Linux. Adding a source file to define Objective-C objects would break the existing architecture.
Thats not purpose of header file. In header file you will define properties and methods which you want to make available where needed.
Implementation always lies within .m file in case of Objective C.
EDIT
Sure thing, of course you can ... I've removed the previous failed attempt to remove clutter.
// main.m
#import <Foundation/Foundation.h>
#import "A.h"
#import "B.h"
#import "C.h"
int main(int argc, const char * argv[])
{
#autoreleasepool
{
NSLog(#"Hello, World!");
[[A alloc] init];
[[B alloc] init];
[[C alloc] init];
}
return 0;
}
// A.h, repeat for B.h and C.h
#import <Foundation/Foundation.h>
#interface A : NSObject
#end
// A.m
// B.m and C.m are quite similar
// BUT drop the line below from B and C
#define ZIMP
#import "A.h"
#import "Header.h"
#implementation A
- ( id ) init
{
self = super.init;
[[[Z alloc] init] msg:#"A"];
return self;
}
#end
Now for the grand finale
// Header.h
#import <Foundation/Foundation.h>
#interface Z : NSObject
- ( void ) msg:( NSString * ) src;
#end
#ifdef ZIMP
#implementation Z
- ( void ) msg:( NSString * ) src
{
NSLog( #"%# says hi", src );
}
#end
#endif
The proof of the pudding ... here is the output
2020-07-15 07:29:52.134413+0200 HdrImp[26901:700649] Hello, World!
2020-07-15 07:29:52.135121+0200 HdrImp[26901:700649] A says hi
2020-07-15 07:29:52.135297+0200 HdrImp[26901:700649] B says hi
2020-07-15 07:29:52.135389+0200 HdrImp[26901:700649] C says hi
Program ended with exit code: 0
The trick is of course to get the compiler to see the implementation only once, even though the header file is included several times. This is accomplished with nothing but a single #define.
Now we can tell the Swift guys that Objective-C can be done with just a single source file.
UPDATE
This works because I know precisely which files will be included and I can set the guard in one of them. If you do not know beforehand which of the files will be part of the compile you have a problem but you can solve that with more defines and by some code in your make file where you 'know' which of the files will be included and can take action based on that.
You need to understand the different purposes of header (.h) and module (.m) files:
The correct usage is this:
A Header file just declares the types and what they are composed of. It is like saying to the compiler: Look, somewhere is a class named Person, and you can call speak on it. It does not tell the compiler the internals of the speak function, it just announces that this type exists somewhere.
This is called a type declaration.
When the compiler translates the Main.mm file, it creates a call to a yet-unknown, external function speak. It does the same for Test.mm.
Then, after compilation of your code, the linker runs to resolve all the unknown addresses, e.g. it checks if there is one and exactly one definition of a class Personwith a function speak. If there is no such definition, you get an unresolved symbol error. If there are multiple definitions, you get your duplicate symbol error.
Therefore, you need to create a Module file to define all your classes - exactly once. In your case you need a file Person.m, which contains the #implementation of the class (and functions).
Types can be declared multiple times, but may only be defined once.
What you did wrong: When you put your type definition into the header file, the compiler creates two implementations of your class (when translating Main.mm and the other when translating Test.mm), which then confuses the linker, because the linker expects exactly one.
You can have a central header file which aggregates all types and sub-includes, but you need one (or more) separate module files - and you must not include them, because the linker resolves the references for you.

Objective C private instance variables error

I am just starting out with Objective C trying out a sample program about fractions from the Programming in Objective C book:
#import <Foundation/Foundation.h>
//---- #interface section ----
#interface Fraction: NSObject
-(void) print;
-(void) setNumerator: (int) n;
-(void) setDenominator: (int) d;
#end
//---- #implementation section ----
#implementation Fraction
{
int numerator;
int denominator;
}
-(void) print
{
NSLog (#"%i/%i", numerator, denominator);
}
-(void) setNumerator: (int) n
{
numerator = n;
}
-(void) setDenominator: (int) d
{
denominator = d;
}
#end
//---- program section ----
I keep getting the inconsistent instance variable specification error for the instane variables numerator and denominator.If I move the declarations to the #interface section, the error goes away but I want to know why I am getting this error? I am using Xcode 3.6.2 on Snow Leopard 10.6.8
You're getting an error because ivars needs to be declared in the interface.
By the way, you're using a veeeeery old version of xcode (probably too old to submit to the appstore), so you might want to look into getting xcode 4.6. There's also been many updates to the Objective-C language. In modern objective-c, there is no longer a need to manually declare ivars like this.
If you REALLY would like to keep ivars out of the header file, you can declare them in an empty category interface (also called a "class extension") like this, in the .m file:
#interface YourClass() {
ivars here
}
#end
Instance variables in #implementation blocks are only supported since Xcode 4.2 (LLVM compiler version 3.0). You must upgrade your development tools to take advantage of this feature.
The motivation for this language feature is to achieve better information hiding in your class structure. That means that clients of your interface (your .h file) may not need to be aware of the ivars the class is using, so they are "hidden" in the implementation file.
Another way to hide ivar is to include them in a class extension in your implementation (.m) file:
// Fraction.m
#interface Fraction () {
int numerator;
int denominator;
}
#end
#implementation Fraction
// ...
#end
But it also requires Xcode 4.2+ and a modern runtime environment.
For complete compatibility with old compilers, ivars can only be placed in the interface section of the .h file.

Simple self contained Objective C file

I'm trying to run through all the Objective C I possibly can as fast as I can for my new job. I've divided up my training so I do 1/2 with cocoa tutorials and I thought it also made sense to try to learn Objective C from a general perspective as well so the other 50% i'm trying to learn out of the "Programming In Objective C" book by Stephan Kochan (2004). Many of his examples up through the first 50 pages or so seem to imply that there is a way to make a simple class (interface, implementation, and main) all in the same file. I have been trying to compile this in the mac Snowleopard terminal for the sake of speed, but as soon as I call a method inside the main I get compile errors.
I know its not my gcc compiler because the file will compile, and I can even write a printf statement, but as soon as I try to call a method, I get compile errors. I would appreciate it if someone could demonstrate a simple inclusive objectivec.m file that actually works with a method call.
here's my code
#import <stdio.h>
#import <objc/Object.h>
#interface testing1 : Object
{
int number;
}
-(void) setNum:(int)a;
-(void) print;
#end
#implementation testing1;
-(void) setNum:(int) a{
number = a;
}
-(void) print{
printf("this is the number %i \n", number);
}
#end
int main(int argc, char* argv[] )
{
//testing1 *test =[testing1 new];
//[test setNum: (int)34];
printf("testing");
//[test print];
}
this will compile in the terminal with --- gcc tester1 -o myProg -l objc
I've tried to call those methods several different ways but it does not work
any help is appreciated. Perhaps I need to break it up and use make - I don't know
Thanks
MIke
You have ; at the end of #implementation -
#implementation testing1; // Semi colon shouldn't be present at the end
With that modification made, you should see the result. Online result of the program
[test setNum: (int)34];
Here typecasting 34 to int is unnecessary. You can just pass the message setNum to reference test with 34 followed by colon.
[test setNum:34 ];
Interface declarations should go in header while the implementation to source files. Only source files get compiled. Before even the compilation phase, pre-processor just copies the content of all imported files to the translation units. So,
testing.h
#import <Foundation/NSObject.h>
#interface testing1 : NSObject
{
int number;
}
-(void) setNum:(int)a;
-(void) print;
#end
testing.m
#import <stdio.h>
#import "testing.h"
// You should definitely import just stdio.h header here because of printf function usage
// testing.h also to be imported or else compiler doesn't know what is testing1.
#implementation testing1
-(void) setNum:(int) a{
number = a;
}
-(void) print{
printf("this is the number %i \n", number);
}
#end
main.m
#import <stdio.h>
#import "testing.h"
int main(int argc, char* argv[] )
{
testing1 *test =[testing1 new];
[test setNum: 34];
printf("testing");
[test print];
return 0;
}
Now you need to compile the two source files from which corresponding object files are generated. Linker combines these object files to give the final executable.
gcc -o test testing.m main.m -framework Foundation
Run -
./test
The book you're following is out of date. The Object class was effectively deprecated way back in 1994 with the introduction of OpenStep.
In Objective-C 2.0, the Object class simply isn't available at all. That's why your program produces compiler warnings/errors.
You should instead subclass NSObject and import <Foundation/Foundation.h>. Use the -framework Foundation gcc parameter, instead of -l objc.
First of all, you used #import <stdio.h>. You only need that when your using C only. Delete the sentence and use this instead.
#import <Foundation/Foundation.h>
Secondly, why are you using #import <objc/Object.h>? The "<" and ">" are only for frameworks. If you want to import another file you made, use #import "Object.h" instead. (Unless you're talking about NSObject, then you don't need to import anything because it is part of the Foundation framework.)
And lastly, you should take away the semicolon after the #implementation because it's unnecessary.

Adding .m source code files for room for long or extra routines

My Xcode .m source files are getting long due to numerous routines, some of which are rather long. I'm looking for the way to add additional .m files and then call the routines in them from my main .m file. I understand the mechanics of adding source files, I really want to know how to call routines in source files other than the one I am currently in.
Example:
mySource.h contains
-(void) myRoutine01;
-(void) myRoutine02; ...
-(void) myRoutine99;
Inside mySource.m I call a routine thusly:
[self myRoutine01];
[self myRoutine02];
[self myRoutine03];
I'd like to keep mySource.m manageable in length such that I am doing mostly logic stuff with calls to routines that are actually housed in other source files. Some routines can get very long and housing them in their own .m files would be most convenient.
How do I call routines in another source file? Do I just replace "self" with something?
What you are calling "routines" are actually methods.
You can organize your methods using Objective-C categories, placed in multiple files.
A category is a way to add methods to existing Objective-C classes. Read the documentation to learn more about this.
This way, you can organize your source files and keep them small, by grouping specific methods into a specific category.
For instance:
MyClass.h
#interface MyClass: NSObject
{}
- ( void )someMethod;
#end
MyClass+Misc.h (category)
#import "MyClass.h"
#interface MyClass( Misc )
- ( void )someOtherMethod;
#end
MyClass.m
#import "MyClass.h"
#import "MyClass+Misc.h"
#implementation MyClass
- ( void )someMethod
{}
#end
MyClass+Misc.m
#import "MyClass+Misc.h"
#implementation MyClass( Misc )
- ( void )someOtherMethod
{}
#end

how to return C++ pointer in objective-C++

I have the following objective-C++ header with the simple method to return this pointer.
#interface MyObj
{
MyCPPObj * cpp;
}
-(MyCPPObj *) getObj;
I have created the simple method
#implementation MyObj
-(MyCPPObj *) getObj
{
return cpp;
}
Everything seems to work until I actually try to use the object in another file
newObj = [createdMyObj getObj];
It complains: error: cannot convert 'objc_object*' to 'MyCPPObje *' in initialization.
It seems that the method is return an objective-c object, but I specifically requested a C++ pointer.
MyCPPObj is an honest C++ class:
class MyCPPObj
{
public:
int x;
}
How can I fix that?
On my 10.6.3 machine, the following combination worked without any problem: aho.h
#import <Foundation/Foundation.h>
class MyCPPObj{
};
#interface MyObj:NSObject
{
MyCPPObj * cpp;
}
-(MyCPPObj *) getObj;
#end
and aho.mm
#import <Foundation/Foundation.h>
#import "aho.h"
void foo(){
MyObj*objcObj=[[MyObj alloc] init];
MyCPPObj*cppObj=[objcObj getObj];
}
Two pitfalls you might have fallen into:
Unlike C++, a class in Objective-C which doesn't inherit from NSObject won't work. (Well, you can make it work, but you don't want that usually.) Note the line #interface MyObj:NSObject.
To use NSObject, do #import <Foundation/Foundation.h>
Don't forget to use the extension .mm for Objective-C++ files.
Most likely you have forgotten to #import the header file with the #interface into the .mm file where you use getObj.
The error states what happens, and JeremyP is right on the money. When you forget to include a header file with the prototypes of the selectors, the compiler assumes the selector returns an object of type id. Well id is a typedef to objc_object*, which is incompatible with your C++ class. To fix the error, you simply need to include your header file in the file where you called getObj.