• game design team

    We have emerged as the leading online community for game development of all levels. Our expertise encases all facets for writing PC , Mobile and Online of 2D and 3D Gaming programming and applications development, for instance by using the latest 3D engines, scripting languages and animation techniques, our experienced and qualified team deals with all kind of requirements, whether it be a beginner's choice or an expert gaming action. Most importantly, we endeavor to offer compelling solution and eminent support to our growing community of prospective players and customers.

All the gamers, non-gamers & game-lovers! Today let’s do something more than mere game-playing. Let’s delve deep into the gaming world. Let’s meet the real heroes behind the virtual heroes;  Come; let’s see if the Gaming Industry has anything to offer you more than game-play & also what is the future of this industry?
virtual game developer
I know that you love to play those games. But if I ask youwhat does ‘Game’ mean, chances are there that you’ll laugh at me. But this casual laugh will defuse the glory of the bunch of creative people who make the games for you. A Game is a bunch of specialized applicationsdesigned to play on computers, consoles, cell phones, devices  & these days, on the internet known as Online GamingAnd there’s somebody who make these super-exciting fantasy world. Of course, it’s not a one-man army. The team consists of Game Developers, Game designers, Programmers, Animators, Graphic designers….and so many of them. The number of people involved, however may vary. Small studios may have multi-tasking employees while big studios may employ many workers for a single task. But no hurry. We will meet all of them. You must be thinking how do these people get there? Well, that is the Gaming Industry.
OMG! Even games have an industry! Yeah. They do. Games are not only for playing, dear. They also provide job. But not to all & sundry; to creative & highly skilled people only. Wait. You don’t need to be a geek for that. You are welcome if you are a regular guy with passion, devotion, creativity & not to mention high technical skills along with strong sense of Maths, Physics & Statistics.
Well, now you definitely know that making Games is not a child’s play. It’s a serious job & certainly a big business. Creating these games is really, really complex & believe me or not, quite time consuming too. A standard game may take 1-3 years to complete!
Now you must be thinking what job-profile(s) you may be offered with? Not to worry. A plethora of opportunities are there waiting for you. A quick look is here. Let’s start with the big fishes of this industry-
  • Game Developer-The games developer job title covers a broad area of work and there are many specialisms within the industry. These include:
    • quality assurance tester
    • programmer, with various specialisms such as network, engine, tool-chain and artificial intelligence
    • audio engineer
    • artist, including concept artist, animator and 3D modeller
    • producer
    • editor
    • designer and
    • special effects technician.
  •  Game Designer- . A Game Designer actually understands the logic behind the game, game play, the rules and structure of a game and the creative part.  Like a director of a movie, the Game designer controls the artistic & technical elements of the final output. The Designers are the dreamers of the game.
  • Writer-creates the fat or slim rulebook for you-the gamers.
  • Programmer- to him, a game is a series of codes & coding languages so he is the grey matter in the brain.
  • Network Programmer- writes the codes for online gaming.Certainly these are the people who does the talking part/ communication part with other systems.
  • Art Director- works upon the art-section of a game be it 2D or 3D. The lead-artist decides the overall look of the game. He also works as the creative manager.So he is like the fashion designer who takes are of the charm of the game.
  • Modeller- builds 3D/2D characters & environment.
  • Animator-digitally controls the models.
  • Game tester-ensures the quality of the game.
NO. This is not the end. In fact, these are just a few of the many. There are Lead Designers, Content Designers, Game mechanic Designers, Level Designers, Lead Programmers, Artificial Intelligence Programmers, Graphic Programmers, Physics Programmers, Tools Programmers, User-interface Programmers, Lead Artists, Concept Artists, Sound engineers, Musicians, Executives, Producers, Publishers…..PHEW.
The ability to articulate new & fresh ideas is a must in this industry. Apart from that, educational qualifications matter too. (Remember I told, game  is not a child’s play)…
  • To be a Game Designer, there is no set route , a college degree on Game Design or Graduation with reasonably high level of industry experience and knowledge. Will be helpful. Also you need expertise in a bit of scripting language., creative skill and MUST be able to understand the user point of view on how a user will feel the game.
  • For the role of a programmer, a  Science Graduate with adequate knowledge of physics , mathematics/statistics  & a deep understanding of the programming language ( I am not saying only Python or C++, LUA or C# , I am talking about logical programming also ) as well as of Operating System is needed.
  • Wanna be an artist? Expertise at & talent of forms, lines, colour, theory, drawing, anatomy and the ability to visualize -MUST.
  • A specific technical training will do for an Audio artist, who will be doing background score or VO or normal music . It requires hard understanding on what type of composition is required for the game .
But whatever you choose let your CV speak on behalf of you. Experience really counts.
Working in the Gaming Industry is both rewarding & fun. Fun because, you join here as you love it & rewarding because the salary is hefty. But certainly you have to show that you’ve got talent. DON’T join this industry ONLY for MONEY .. join only if you have the passion.
So you can guess the future is bright for the deserving candidate. The scope in the Gaming Industry is wide. The gaming technology is widely used from the medical to the marketing sector, not to mention Defense, Legal, Airline, Railways, Mines, Education & last but not the least Entertainment sectors.
Especially in recent times, the Gaming Industry in India is growing at first rate. The segment of iPhone & Android is booming fast. A stupendous increase of high-end mobile phone users, availability of DTH connections & significant growth of the urban income  has pulled out Gaming from the mere fun-zone to a much serious & profitable industry.  The Gaming Industry in India is expected to reach 38 billion by 2015.  In the outsourcing, India offers significant cost advantage. so this is another  sector where Indian Game Industry has the potential to shine. In India, women hold a strong position in the target audience as among the players, 45% are women.  Gaming will certainly continue to become much more mainstream & accepted. After all, it has come a long way from the black& white 2D games like Pong to the life-like shooters of Battlefield 3.
The rapid progress of this industry compels me to think that one day we will all have our very own virtual identities, as the rapid growth of the simulation system oriented solution. For that, the huge talent-pool needs to be properly channelized. But sadly, some widespread weird misconceptions are keeping many talented people ignorant about the possibility of this segment.

desire to be a game developer

Posted by virtualinfocom On 9:48 AM 0 comments

  • Do you love playing video games?
  • Have you ever found yourself so immersed in a game that you lose track of time?
  • Do you often stop to wonder how these worlds were created?
  • Do you believe you have the idea that could be turned into the next great video game?
  • Are you tired of all the same old games out there today? Do you have the idea for a genre-redefining video game?
  • Do you wish I would just shut up and tell you how to write your own video games?
If you answered yes to one or more of these questions, chances are you already have the desire to be a game developer. Perhaps you already have the ideas, but you just don't have the skills to make the ideas in your head actually come to life through code.

Compiler Flags in Objective C

Posted by virtualinfocom On 10:33 AM 0 comments

1.5 Compiler Flags

Compiler flags are options you give to gcc when it compiles a file or set of files. You may provide these directly on the command line, or your development tools may generate them when they invoke gcc. This section describes just the flags that are specific to Objective-C.
Tells the compiler to create an instance of ClassName for each string literal expressed with the @"string" directive. For the GNU runtime, the default class is NXConstantString; for Cocoa it is NSConstantString.
Generate code for linking with the standard GNU Objective-C runtime. This is the default option for most gcc installations.
Generate code for linking with the NeXT runtime. This is the default option for Darwin.
Write all interface declarations the compiler sees to a file named sourcename.decl.
Do not warn if methods required by a protocol are not implemented in the class adopting it.
Warn if there are methods with the same name but different signatures.

Compiler and Preprocessor Directives

Posted by virtualinfocom On 10:33 AM 0 comments

1.4 Compiler and Preprocessor Directives

Compiler and preprocessor directives are special terms in your program that tell the compiler to perform some Objective-C-specific action. All compiler directives start with the character @, and preprocessor directives start with #.

1.4.1 Class Declarations and Definitions

The following compiler directives are used to begin or conclude the declaration and definition of Objective-C classes, categories, and protocols:
Begins the declaration of a class's or category's fields and methods.
Begins the declaration of a protocol's methods.
Begins the definition of a class's methods.
Ends the declaration or definition of a class's, category's, or protocol's methods.
The use of these compiler directives is described in detail under Section 1.3, and especially in the subsections Section 1.3.2, Section 1.3.6, and Section 1.3.7.

1.4.2 Forward Declarations

The following compiler directives generate forward declarations, informing the compiler that a type exists:
@class ClassName
Forward declaration of a class.
@protocol ProtocolName
Forward declaration of a protocol.
Use forward declarations when an interface uses variables (fields or method parameters or return types) of a given type. Rather than import the header file for that type, you can simply forward reference it. For example:
@class  Point ;
@interface  Circle  : Graphic  {
  Point * center ;
  // etc.
This is sufficient because the declaration of Circle does not use any details of Point. You could import the header for Point, but this makes any other class that imports Circle.h appear dependent also on Point.h, and can cause unnecessary (and slow) recompiling in large projects.

1.4.3 Expanding Directives

Expanding complier directives look like functions, but they are really instructions to the compiler, which expands them as described in the following list:
@encode ( typeName)
Takes a type specification and evaluates to the C string used by the runtime to succinctly describe that type.
@defs ( className)
Takes the name of an Objective-C class and evaluates to a sequence of type declarations that duplicate the field declarations of the class. This directive can appear only in a C structure declaration.
@protocol ( ProtocolName)
Evaluates to a pointer to an instance of the Protocol class. You need this because you can't get a protocol class instance by using the protocol name directly, as you can with a class object.
@selector ( MethodName)
Evaluates to a SEL representing the specified method.
@ "string"
A shorthand for creating a string literal that's an instance of a user-defined string class. Use this when you need a string object constant.
The directives @encode, @defs, and @"string" deserve some additional explanation. Using @encode
The following example shows how @encode can be used to get the string that the Objective-C runtime uses to describe a type:
char * itype  = @encode (int );
The result of this statement will be to define itype as the one-character string "i", which is the runtime representation of an int type.
The @encode directive can take any C or Objective-C type. The runtime uses the mapping between types and strings to encode the signatures of methods and associate them with selectors. You can use @encode to implement your own object storage and retrieval, or other tasks that need to describe the types of values.
Table 1-1 shows the results of applying @encode to C and Objective-C types.
Table 1-1. Types and their encodings
long long
unsigned char
unsigned int
unsigned short
unsigned long
unsigned long long
An object pointer
An array of N elements of type
A structure called name with elements t1, t2, etc.
A union
A bit field of size N
A pointer to type
Unknown type
The runtime system also uses encodings for type qualifiers, shown in Table 1-2, and you may encounter them in its representation of method signatures. However, you can't get those encodings with the @encode directive.
Table 1-2. Type qualifiers and their encodings
V Using @defs
The following example shows how @defs can be used to create a C structure with fields that match the fields in a class. In this example, both the order and type of the fields of MyStruct will match those in MyClass:
@interface  MyClass  : Object {
  int  i ;
typedef  struct  {
  @defs (MyClass )
} MyStruct ;
The typedef in this example is seen by the compiler as:
typedef  struct  {
  id  isa;
  int  i ;
} MyStruct ;
Having a structure that corresponds to a class lets you bypass the normal access restrictions on an Objective-C instance. In the following example, an instance of MyClass is cast to an instance of MyStruct. Once that's done, the protected field i can be accessed with impunity:
MyClass* c = [MyClass new];
MyStruct* s = (MyStruct*)c;
s->i = 42;
Obviously this is a facility you should use with restraint. Using @"string"
The @"string" directive creates the Objective-C version of a string literal: one that you can pass to a method expecting a string object, or use to initialize or compare with another string object.
When you create a string with @"string", you get an instance of a class defined by the compiler option -fconstant-string-class. The instance is static: its contents are stored in your program's file, and the instance is created at runtime and kept around for the duration of program execution. You can't change its value, because it appears as an expression in your program, not as a variable
In the GNU runtime, the default string class is NXConstantString; for Darwin it is the Cocoa class NSConstantString.

1.4.4 Preprocessor Symbols

Objective-C adds one preprocessor directive and defines one symbol to the preprocessor before compiling:
#import fileName
Using #import has the same effect as the C directive #include, but will only include the file once.
_ _OBJC_ _
When gcc is compiling an Objective-C file, it defines this symbol for the preprocessor. If your code must compile as plain C as well as Objective-C, you can test to see if this symbol is defined:
#ifdef _ _OBJC_ _
  // Objective-C code here

Elements of the Language

Posted by virtualinfocom On 10:32 AM 0 comments

Elements of the Language

Objective-C extends the C language with the following concepts and constructs:
·         Objects (instances of classes)
·         Classes
·         Inheritance and subtyping
·         Fields
·         Methods and method calls (or messages)
·         Categories
·         Protocols
·         Declarations (extended from C to include class and protocol types)
·         Predefined types, constants, and variables
·         Compiler and preprocessor directives
The following sections will describe these aspects of Objective-C.

1.3.1 Objects

Objects are the compound values—data and operations—at the heart of object-oriented programming. They are generalizations of simple structured types found in C and many other languages. Like C structs, objects have components—data fields—that maintain state. For example, a Book object might have fields to specify the author and publisher. In addition, objects interact through message passing, which provides an alternative to the function calls of a procedural language.
Objective-C objects have these attributes:
An object type. An object whose type is MyClass is said to be an instance of MyClass.
Data members of an object. An object has its own copies of the fields declared by its class or its ancestor classes.
Fields are also referred to as "instance variables." I prefer the term "fields" for several reasons: "instance variables" is redundant since there are no class variables, it is ambiguous since it could mean variables that are instances, just "variables" would be more ambiguous, and "fields" is shorter. (An alternative term is "ivars.")
Functions provided by an object. An object responds to methods declared by its class or ancestor classes.
A few special objects (class objects) acquire their fields and methods differently. Section 1.9 describes class objects.
Objective-C objects are implemented so that:
·         They exist in dynamically allocated memory.
·         They can't be declared on the stack or passed by value to other scopes.
·         They are referred to only by pointers.
When someone says of an Objective-C variable: "c is an instance of C", you should understand that to mean that c is a pointer to an object of type C.

1.3.2 Classes

Classes are types in Objective-C. The interface of a class specifies the structure of its instances; the implementation provides its code. The interface and implementation of a class are separate, usually in different files. Categories add to an existing class without subclassing it; they also have separate interface and implementation. Protocols are pure interface declarations.
Classes declare the following attributes:
The class whose methods and fields will be inherited by the new class being declared.
Class name
The name of the class being declared.
Data members of each instance of the class.
Instance methods
Functions associated with instances of the class.
Class methods
Functions associated with the class itself.
Because Objective-C makes calling class methods syntactically identical to calling instance methods, classes themselves behave much like objects. Section 1.9 discusses class objects. Declaring an interface
An interface names a class and declares its parent (if any), fields, and methods, without specifying any implementation. (You can't use C++-style inline methods, implemented in the header.) A header file can contain any number of interface declarations, but it is conventional to put each interface in a separate header file. By default, gcc expects the filename to end in .h.
Following is an example interface declaration. (Note that the line numbers are not part of the source code.)
 1 #import  "Graphic.h "
 3 @class  Point ;
 5 @interface  Circle  : Graphic  {
 6   @protected   // or @public or @private
 7     float   radius ; 
  8     Point * center ;
 9 }
10   -(void )scaleBy :(float )factor ;
11   +(void )numCircles ;
12 @end 
Line 1. The #import directive is like C's #include directive, except that the compiler ensures that no file is included more than once. You always need to import the declaration of your class's parent class (if any). You don't need to import any other Objective-C class declarations, but it may be convenient to import some umbrella header files as a matter of routine.
Line 3. You use the ec@class declaration when your class's fields, or the return values or parameters of your class's methods, are instances of another class. You can use separate @class declarations for distinct classes, or use a single declaration with the class names separated by commas.
A class declaration doesn't need any more information about any other class, so you don't need to import a header unless the header has other declarations (e.g., macros or globals) that your class declaration needs.
Line 5. Specify the name of your class and that of the parent class (if any). The name of your class will be visible to any code that includes the header file. All class names exist in the global namespace, along with global variable names and type names.
Line 6. Access keywords control compile-time checking of access to fields. You can repeat these as often as you want; a field has the access permission specified by the most recent preceding keyword. If there is no preceding keyword, access permission defaults to protected.
In brief, public fields are visible to all subclasses and all external code, protected fields are visible only to subclasses, and private fields are visible only in the class being declared. Section 1.3.4 gives exact rules.
Line 7. Declare fields in the same manner as you declare structure members in C. Fields can be of any C type, as well as of any class or other type (described in Section 1.3.9) added by Objective-C. Fields can have the same name as methods in the same class.
Fields are not shared between instances—that is, Objective-C does not support class variables. But you can get the same effect by declaring ordinary variables as static in the implementation file. (See the following Section for an example.)
Line 8. You incorporate other objects only by pointer, not by value. Objective-C's predefined id, Class, and Protocol types are pointer types already.
Line 9. No semicolon after the closing brace.
Line 10. An instance method is marked with a - character. Instance methods operate on instances of the class. Method signatures use Objective-C's infix syntax, discussed later in Section 1.3.5.
You don't need to redeclare a method if you are inheriting it. It is conventional to redeclare a method if your class inherits and overrides it. Section explains why you should declare a method in all other cases. (But not necessarily in the header file; see Section Methods can have the same name as fields of the same class, and instance methods can share names with class methods.
Line 11. A class method is marked with a + character. Class methods perform operations or return information about the class as a whole, and don't pertain to any instance of the class.
Line 12. No semicolon after the @end keyword. Implementing a class
You implement a class by writing the code (i.e., the bodies) for each of the class's methods. A file can contain any number of class implementations, but it is conventional to put each implementation in a separate file. By default, gcc expects the filename to end in .m (for Objective-C) or .mm or .M (for Objective-C++). Even if a class has no methods, it must have an empty implementation.
If you don't provide a class implementation, the compiler will not emit support code for the class, and the linker will fail.
Here is a simple implementation for the class declared in the previous section:
1 #import  "Circle.h "
3 static  int  count ;
5 @implementation  Circle 
6   // No field section.
7   +(void )numCircles  { return  count ; }
8   -(void )scaleBy :(float )factor  { radius  *= factor ;}
9 @end 
Line 1. Always import the header file that declares your class. If your code uses other classes (e.g., it sends messages to them or their instances) you need to import the headers of those classes too. There is little point to using an @class declaration here—if you use another class in an implementation you will need its interface declaration.
Line 3. This is a pure C declaration, reserving space for a per-class variable. (In this example, it would be used to keep count of the number of objects created. That code is not shown.) It will be visible only in this implementation file.
Line 5. Specify the name of the class you are implementing.
Line 6. You can't add any more fields here, so there is no brace-delimited section corresponding to the one in the interface declaration.
Lines 7, 8. Define methods with the same signature syntax as in the header; follow each method definition with the code, in braces. For more information on writing the code, see Section 1.3.5.
Line 9. No semicolon after the @end keyword.

1.3.3 Inheritance and Subtyping

Inheritance and subtyping are the fundamental object-oriented features: inheritance lets you declare how one type differs from another, and subtyping lets you substitute one kind of object for another when their types are compatible.
A class's interface may declare that it is based on another class:
@interface  MyClass  : Parent 
This is described by saying MyClass is a subclass of Parent, and has the following runtime effects:
·         MyClass responds to any class method that Parent responds to.
·         Instances of MyClass have all the fields that instances of Parent have.
·         Instances of MyClass respond to any instance methods that instances of Parent respond to.
These effects are summarized by saying MyClass inherits Parent's fields and methods. These properties imply that inheritance is transitive: any subclass of MyClass also inherits from Parent.
Declaring a class and specifying a parent also has these effects at compile time:
·         You can refer to inherited methods and fields.
·         You can assign variables declared as MyClass to variables declared as Parent.
This is described by saying MyClass is a subtype of Parent. Subtyping is also transitive. For example, any subclass of MyClass is a subtype of Parent.
You can't redeclare fields in a subclass, either identically or with a different type. (Unlike C++, this holds even if the inherited field was declared private.)
A subclass can replace, or override , an inherited method with a different version. You do this by providing a new implementation for the method when you write the subclass. At runtime, instances of the subclass will execute the new code in the overriding method instead of the code of the inherited method. By definition, the overriding method has the same name as the inherited one; it must also have the same return and parameter types. (You can't overload methods as in C++.) You don't need to redeclare the overriding method, but it is conventional to do so.

1.3.4 Fields

Fields are data members of objects. Each object gets its own copy of the fields it inherits or declares.
Inside the methods of a class you can refer directly to fields of self, either declared in the class or (if they are not private) inherited:
@interface  Circle  : Graphic  {
  float  radius ;   // Protected field.
  // etc.
@implementation  Circle 
  -(float )diameter  {
    return  2 * radius ; // No need to say self->radius.
If an object other than self is statically typed, you can refer to its public fields with the dereference operator:
AClass* obj;      // Static typing required.
obj->aField = 7;  // Presuming aField is public. Access modifiers
Access to an object's field depends on four things:
·         The field's access permission (public, private, or protected)
·         The class of the accessing code
·         The class of the object
·         The nature of the object: whether it is the receiver (self) or another variable (global, local, or method parameter)
There is no notion of read-only members in Objective-C: if you can read a field, you can also write to it.
You declare a field's access permission in its class's interface. Any of three access keywords—@public , @protected, and @private—may appear any number of times in an interface declaration and affects all fields declared after it until the next access keyword. (See the example in Section 1.3.2.) If there is no preceding keyword, a field has protected access.
Following are the keywords and their effects on access to an object's fields:
A public field is visible to all code.
If the object is self, a protected field is visible.
If the object is not self, access depends on its class:
·     If the object's class is the same as that of the receiver, the field is visible.
·     If the object inherits from the receiver's class, the field is not visible. (You can get around this by casting the object to the receiver's class.)
·     If the object has any other relation to the receiver's class, the field is not visible.
If the object is self, a private field is visible.
If the object is not self:
·     If the object's class is the same as that of the receiver, the field is visible.
·     In all other cases, the field is not visible.

1.3.5 Methods

Methods are the functions associated with an object, and are used as interfaces for querying or changing the object's state, or for requesting it to perform some action.
Objective-C uses the terms "calling a method" and "sending a message" interchangeably. This is because method dispatch is less like dereferencing a function pointer and more like searching for a recipient and delivering a message. Most of the work of method lookup is done at runtime.
You send messages to objects using Objective-C's bracket syntax. Method names are associated with parameters using an infix syntax borrowed from Smalltalk. Objective-C provides directives for accessing the runtime dispatch mechanism directly. Declaring a method
You declare a method in an interface or protocol by specifying who handles it (either the class or an instance of the class), its return type, its name, and its parameter types (if any). The name is broken up so that part of it precedes each parameter. The form of a declaration depends on the number of parameters, as described in the following sections. No parameters
This declaration can be broken down as follows:
Indicates an instance method; use a + for class methods.
Indicates that the return type is id. Specifying a return type is optional; the default return type is id.
The method's name. One parameter
+(void )setVersion:(int )v ;
This declaration can be broken down as follows:
Indicates a class method.
Indicates that the return type is void.
The method name. This method name includes a colon, which indicates a parameter to follow.
Specifies that the parameter is an int. If you omit the parameter type, it defaults to id.
The parameter name. You need the name in both declaration and implementation, although it's only used in the implementation. 
More than one parameter
-(id )perform:(SEL )sel  with:(id )obj ;
This declaration can be broken down as follows:
Indicates an instance method.
Indicates that the return type is id.
The first part of the method name. This method name has two parts, one preceding each of the parameters. The full method name is perform:with:. Methods with more parameters follow the same pattern as shown here. The second, third, etc. parts of a method name don't need any textual characters, but the colons are required.
Specifies that the first parameter has the type SEL.
The name of the first parameter.
The second part of the method name.
Specifies that the second parameter has the type id.
The name of the second parameter. A variable number of parameters
-(id )error:(char *)format ,...;
This declaration can be broken down as follows:
Indicates an instance method.
Indicates that the return type is id.
The entire method name. In this case, the second and subsequent parameters are not prefaced by extensions of the method name.
Specifies the type of the first parameter.
The name of the first parameter.
Represents the variable-size parameter list. Ellipses like these can only appear at the end of a method declaration. In the method, access the list using the standard C variable-arguments interface. Implementing a method
The body of a method appears in the implementation section of a class. The method starts with a declaration, identical to that of the interface section, and is followed by code surrounded by braces. For example:
-(void )scaleBy :(float )factor  {
  radius  *= factor ;
Inside a method body, refer to fields the class declares or inherits with no qualification. Refer to fields of other objects using the dereference (->) operator.
Objective-C defines three special variables inside each method:
The receiver of the method call.
A reference to the inherited version of the method, if there is one.
The selector—an integer that uniquely specifies the method.
Section 1.3.9 describes these special variables in more detail. Calling a method
Every method call has a receiver—the object whose method you are calling—and a method name. You enclose a method call in brackets [ ] with the receiver first and the method name following. If the method takes parameters, they follow the corresponding colons in the components of the method name. Separate receiver and name components by spaces. For example:
[aCircle initWithCenter:aPoint andRadius:42];
If a method takes a variable number of parameters, separate them with commas:
[self  error:"Expected %d but got %d ", i , j ];
A method call is an expression, so if the method returns a value you can assign it to a variable:
int  theArea  = [aCircle  area ];
Method calls can be nested:
Circle* c1 = ... // whatever
Circle* c2 = 
  [[Circle alloc] initWithCenter:[c1 center]
                  andRadius:[c1 radius]]; Naming collisions
When the compiler encodes a method call, it needs to set up, then and there, room for the parameters and return value (if any). This is a nondynamic aspect of method calls. To encode the call properly, the compiler must know the parameter and return types.
If you leave the type of a receiver unknown (that is, declared as id) until runtime, the name of a method may be all the information the compiler has when it compiles the method call. The compiler will encode the method call based on previous uses of the same method:
·         If the compiler has not yet seen any methods with the name used, it will assume the return type and parameters are all id (a pointer whose size is platform-dependent) and will issue a warning message. If you use variables of type other than id, the compiler will convert them according to standard C rules and they may not survive intact.
·         If the compiler has seen exactly one method with the same name, it will emit code assuming the return and parameter types match those it saw.
·         If the compiler has seen more than one method with the same name, and differing return or parameter types, it will not know how to encode the method call. It will choose one option and issue a warning message. As in the first case, type conversions may play havoc with your data values.
The compiler will not let you declare, in related classes, methods with the same name but different parameter types (no C++-style overloading), but you can do this in unrelated classes. To avoid forcing the compiler to guess your intentions, methods with the same name, even in different classes, should usually have the same signature.
You can relax this restriction if you know the receiver of the call will always be statically typed. But you may not have control over all future use of your method. Private methods
Because the compiler needs to know parameter types to generate method calls, you should also not omit method declarations in an attempt to make them private. A better way to make a method private is to move the method declaration to its class's implementation file, where it will be visible to the code that uses it but not to any other part of your program.
The following example shows how to use a category (described at greater length in Section 1.3.6) to declare a method in an implementation file:
1 @interface  Circle  (PrivateMethods )
2   -(float )top ;
3 @end 
5 @implementation  Circle 
6   // Public definitions as before.
7   ...
8   // Now implement the private methods.
9   -(float )top  { return  [center  y ] - radius ; }
8 @end 
Line 1. At the beginning of your class's implementation file, declare a category that extends the class.
Line 2. Methods declared here are just as much part of the class as the ones declared in the regular interface, but will be visible only in this file.
Line 5. Your class's implementation, in the usual fashion.
Line 6. Implement the methods declared in the header file. They can call the private methods (as well as other public methods, of course).
Line 8. Implement the private methods. They can call public and private methods. Accessors
Accessors are methods for setting and returning an object's fields. Objective-C has several conventions for writing accessors:
·         To return a variable, provide a method with the same name as the variable. You can do this because methods and fields have separate namespaces.
·         To set a variable, provide a method with the same name as the variable that takes the new value as a parameter. For example, given a variable named radius, use radius:(float)r as the signature for your setter method. You can do this because the colon preceding the parameter is part of the methods' name, so radius: the setter will be differently named from the radius the getter.
Here is an example of how to write accessors for a simple field:
@implementation  Circle 
  -(float )radius  { return  radius ; }
  -(void )radius :(float )r  { radius  = r ; }
Don't use "get" in the name of your accessors. By convention, methods whose names start with "get" take an address into which data will be copied.
If you are using reference counting, there are more design patterns you should follow when writing accessors. These are discussed in Section 1.12.2. Message search paths
When you send an object a message (call one of its methods), the code that actually runs is determined by a search performed at runtime.
The dispatch of the method call proceeds as follows:
1.       The runtime system examines the object at the actual time the message is sent and determines the object's class.
2.       If that class has an instance method with the same name, the method executes.
3.       If the class does not have such a method, the same search takes place in the parent class.
4.       The search proceeds up the inheritance tree to the root class. If a method with a matching name is found, that method executes.
5.       If there is no matching method but the receiver has a forwarding method, the runtime system calls the forwarding method. (See Section 1.11.) Default forwarding behavior is to exit the program.
6.       If there are no forwarding methods, the program normally exits with an error. Section 1.9 describes how to change this.
Section 1.9 provides more details about method dispatch. Special receivers
The receiver is the object to which you are sending a message. Its instance methods will be given the first chance to handle the call, followed by the instance methods of its ancestor classes.
Besides the typical case of sending a message to a named receiver, there are several special targets:
Refers to the object that is executing the current method. At runtime, the class of self may be the class in which the call to self appears, or it may be a subclass.
Refers to the inherited version of the method.
When you use the predefined variable super as the receiver, you are sending a message to self but instructing the runtime to start method lookup in the parent class of the class in which the send occurs.
This is not the same as starting in the parent class of the receiver—the class of super is determined at compile time. If this were done dynamically, the following code would cause an infinite loop:
1 @implementation  C 
2   -(void ) f  { [super  f ]; }
3 @end 
5 // And elsewhere:
6 D * d  = [D  new];
7 // D inherits from C, does not override f.
8 [d  f ];  // Executes in C's version.
Here, D is a subclass of C that does not override f. The call at line 8 would dispatch to line 2, but the call to super would be redirected to the parent class (C) of the receiver (D)—i.e., back to line 2.
Any class name
Refers to the class object that represents the named class. When you call a class method you are actually sending a message to a class object. (See Section 1.9.) If you don't have the class object on hand, this syntax lets you use the class's name as the receiver.
It is not an error to send a message to nil (an uninitialized or cleared object). If the message has no return value (void), nothing will happen. If the message returns an object pointer, it will return nil. If the message returns a scalar value such as an int or float, it will return zero. If the message returns a struct, union, or other compound value, its return value is not specified and you should not depend on it. This behavior makes it easier to chain together method calls. For example:
id  widget  = [[[window  child ] toolbar ] widget ];
If sending a message to nil caused a runtime error, you would have to check the result of each message. This property of nil should not tempt you to be lax with your runtime checking, but it may suffice to test only the end result of a chain of method calls. Selectors
Objective-C methods are distinguished by their names, which are the concatenation of the component parts of the method name, including the colon characters. At compile time, each name is matched to a unique integer called the selector. The Objective-C type SEL represents a selector's type.
When a method call is compiled, it is distilled to its receiver, selector, and parameters. At runtime, the message is dispatched by matching the selector with a list maintained by the receiver's class object.
You can use selectors to make a runtime decision about what method to call—the Objective-C version of function or method pointers.
1 SEL  mySel  = @selector (center );
2 Point * p  = [aCircle  perform:mySel ];
Line 1. The compiler knows the mapping from selector names to SELs and will emit code assigning to mySel the value corresponding to the method name center.
Line 2. Using the selector, you can instruct the receiver to respond to the message as if it had been sent in the usual way. The effect is the same as executing the direct method call:
Point* p = [aCircle center];
Section 1.10 gives more information about the -perform: methods.

1.3.6 Categories

Objective-C provides the category construct for modifying an existing class "in place." This differs from writing a new subclass: with inheritance you can only create a new leaf in the inheritance tree; categories let you modify interior nodes in the tree.
With a category, the full declaration of a class can be spread out over multiple files and compiled at different times. This has several advantages:
·         You can partition a class into groups of related methods and keep the groups separate.
·         Different programmers can more easily work on different parts of the class.
·         For diverse applications, you can provide only those parts of the class that are needed. This gives you finer-grained control over expressing dependencies without having to provide different versions of the class.
·         You can add methods to classes from the operating system's library or from third-party sources without having to subclass them. Declaring a category
Here is an example of declaring a category to add methods to the Circle class:
1 #import  "Circle.h "
3 @interface  Circle  (Motion )
4   // No field section.
5   -(void )moveRight :(float )dx ;
6   -(void )moveUp :(float )dy ;
7 @end 
Line 1. The declaration can be in the same header file as the declaration of the class it modifies, or in a separate file. If it is in a separate header file, you may need to include the header file of the modified class.
Line 3. Declare the name of the class you are modifying and the name of your category. In this example, Circle is the class name, and Motion is the category name. Category names have their own namespace, so a category can have the same name as a class or a protocol.
Line 4. There is no fields section in the category declaration, so you can't use a category to add fields to a class.
Lines 5, 6. Declare methods here as in a class interface.
Line 7. No semicolon after the @end keyword.
You can declare a category in a header or an implementation file. If the declaration is in a header file, its methods are full members of the modified class. Any code can use the new methods with the modified class (and its subclasses). If the declaration is in an implementation file, only code in that file can use the new methods, and their implementation must appear in that file. This is a way of making methods private.
If you declare in your category a method with the same name as one in the modified class, the new method overrides the old one. When such an overriding method sends messages to super, they go to the same method in the parent class (just as they would in the overridden version) and not to the overridden method itself. You can't send messages to the overridden version. You should simply avoid using categories to override methods.
If several categories that modify the same class all declare a method with the same name, the results are implementation dependent. In other words, don't do this. The gcc compiler does not warn you about this.
You don't have to implement all or even any of the methods you declare in a category. The compiler will warn you if you have an implementation section for your category and omit any methods. If you have no implementation at all for a category, this is called declaring an informal protocol. Section 1.3.7 discusses these further. Implementing a category
You implement the methods of the category in an implementation file, like this:
1 #import  "Motion.h "
3 @implementation  Circle  (Motion )
4   -(void )moveRight :(float )dx  { ... }
5   -(void )moveUp :(float )dy  { ... }
5 @end 
Line 1. You need to include the declaration of the category you are implementing. If the declaration is in the same file as the implementation, you don't need this line.
Line 3. Specify the name of the modified class and the name of your category.
Line 4. Methods take the same form and have the same access to fields as in a regular class implementation.
Line 5. No semicolon after the @end keyword.

1.3.7 Protocols

Protocols are lists of method declarations that are not associated with a specific class declaration. Protocols let you express that unrelated classes share a common set of method declarations. (This facility inspired Java's interface construct.) Protocols let you do the following:
·         Use static type checking where you want it
·         Specify interfaces to other code
·         Factor common features of your class hierarchy
Objective-C declarations can specify that an instance must support a protocol, instead of (or in addition to) conforming to a class. (See Section 1.3.8.) Declaring a protocol
You declare a protocol in a header file like this:
1 @protocol  AnotherProtocol ;
3 @protocol  Printable  <Drawable >
4   -(void )print ;
5 @end 
Line 1. You need the forward protocol declaration if return or parameter types of methods in your protocol use the other protocol.
Protocol names have their own namespace, so a protocol can have the same name as a class or a category.
Line 3. If your protocol extends other protocols, name those in the protocol list. The list is a sequence of protocol names, separated by commas. If the list is empty, you can omit the angle brackets. You don't need to redeclare the methods of the listed protocols. When a class adopts the protocol you are declaring, it must implement all the methods declared in your protocol and all the other protocols in the list. (You can't write partially abstract classes as in C++, with some methods declared but not implemented.)
Line 4. You declare your methods here in the same form as in a class interface.
Line 5. No semicolon after the @end keyword. Adopting a protocol
When you want your class to adopt (implement) one or more protocols, you declare it like this:
#import  "Printable.h "
@interface  Circle  : Graphic  <Printable >
When you want your category to adopt a protocol you declare it like this:
#import  "Printable.h "
@interface  Circle  (Motion ) <Printable >
The list of protocols, inside the angle brackets, consists of names separated by commas. You have to import the header files where the protocols are declared. Don't redeclare the protocol's methods in your interface; just define them in your implementation. You have to define all the methods of the protocol.
When you declare a field or variable, you can specify that it represents an instance whose class conforms to a specific protocol like this:
id  <Printable > obj ;
ClassName  <Printable >* obj ;
For more about this, see Section 1.3.8. Checking for conformity to a protocol
At runtime, you can check if an object's class conforms to a protocol by using the -conformsTo: (from the root class Object) or +conformsToProtocol: (from NSObject) methods:
[obj  conformsTo:@protocol (Printable )];
Like classes, protocols have special runtime structures associated with them called protocol objects. Section 1.9 describes these. Informal protocols
You can get some of the functionality of a protocol by declaring but not implementing a category. Such a category is called an informal protocol . You can't declare that a class does or does not implement an informal protocol, so you can't use it for static type checking. You can use an informal protocol to specify a group of methods that all subclasses of the modified class may implement, but are not obliged to implement. This serves as something less than a full protocol but more than just textual documentation. If you need a protocol, you're better off using a formal protocol.
When a subclass implements an informal protocol, it doesn't refer to the original declaration, but declares in its interface which of the methods it will implement and defines the methods in its implementation in the usual way.

1.3.8 Declarations

You can declare Objective-C objects in many different ways. However, the way in which you declare an object has no effect on that object's runtime behavior. Rather, the way that you declare an object controls how the compiler checks your program for type safety. Dynamic typing
Use the id type to declare a pointer to an unspecified kind of object. This is called dynamic typing. For example:
id  obj ;
With this declaration, obj can be a pointer to an object of any type. An id has the following compile-time properties:
·         You can send any kind of message to an id. (The compiler will warn you if the method name is unknown or ambiguous; see Section If at runtime the object does not have an appropriate method or delegate (see Section 1.11), a runtime error will occur (see Section 1.8).
·         You can assign any other object to an id.
·         You can assign an id to any object. The compiler will not remind you that this can be dangerous. Using an id in this way means you assume the risk of assigning an object to an incompatible variable. Static typing
In Objective-C, any deviation from fully dynamic typing is called static typing. With static typing you instruct the compiler about the types of values you intend variables to have. All static typing is done within the inheritance relation: where a variable's class or protocol is declared, a value from a descendant class or protocol is always acceptable.
You can use static typing in three ways, shown in the following examples:
MyClass* obj
Declares obj to be an instance of MyClass or one of its descendants. This is called static typing. Declaring obj this way has the following compile-time effects:
·     You can assign obj to any variable of type id.
·     You can assign any variable of type id to obj.
·     You can assign obj to any variable whose declared type is MyClass or one of its ancestors.
·     You can assign to obj any variable whose declared type is MyClass or one of its descendants.
·     The compiler will warn you if you assign obj or assign to it in a way not covered in the previous cases. A cast will quiet the compiler but will not prevent an incompatible assignment at runtime.
·     You can send to obj any message that MyClass or one of its parent classes declares.
id < ProtocolList> obj
Does not constrain the class of obj, but declares that it conforms to the specified protocols. The protocol list consists of protocol names separated by commas. This declaration has the following compile-time effects:
·     You can assign obj to an object that does not conform to the protocol.
·     Assigning obj an object that is not declared to conform will trigger a compiler warning.
·     Sending to obj a message not included in the protocol will trigger a compiler warning.
MyClass < ProtocolList>* obj
Declares that obj is an instance of MyClass or one of its descendants, and that it conforms to the listed protocols. The compile-time effects of this declaration are the combination of the effects of the preceding two styles of declaration.
Due to a compiler bug, gcc does not always correctly use the declared protocol for type checking. Type qualifiers
Type qualifiers go before a C or Objective-C type in a method declaration, and modify that type. Supported qualifiers are:
in             oneway
out            bycopy
inout          byref
These qualifiers can only be used in formal protocols and implementations, not in class or category declarations. They specify how parameters are to be passed when you are using remote messaging. Type qualifiers can be combined, although not all combinations make sense. They are discussed at greater length in Section 1.6 .

1.3.9 Predefined Types, Constants, and Variables

Objective-C adds the special type id, which is generic like a void* in C++, but which does not preclude you from sending messages. In addition, the Objective-C environment provides some C types, constants, and variables to support object-oriented programming. Types
Along with class types that you define, Objective-C introduces these built-in types you can use when declaring variables:
A generic Objective-C object pointer type. You can send any message to the variables of this type without compiler warnings. (See Section 1.3.8.) At runtime the receiver may handle the message, delegate it, or explicitly ignore it. If it does none of these, a runtime exception occurs. (See Section 1.8.) Unspecified method return or parameter types default to id.
The name id is a C typedef for a pointer to a structure with one member: a field that points to a class object. Section 1.9 discusses this at greater length.
A pure C type: a pointer to an Objective-C class structure. The runtime system contains a structure for each Objective-C class in your program's code. Calling the -class method of any object returns a value of this type.
Provided in the GNU runtime but not in Darwin, this is identical to Class. It's used for clarity when operating with metaclass objects.
An Objective-C class. The runtime system contains an instance for each Objective-C protocol that is either adopted by a class in your program's code or referred to in an @protocol declaration directive. You can construct a Protocol instance from its name using the @protocol directive with a parameter.
A logical type whose variables have two possible values: YES and NO. The name BOOL is a typedef for the C type char.
A unique specifier for a method selector. Often implemented as a pointer to the method's name, but you should treat it as an opaque handle. You can construct a selector from a method name using the @selector directive.
A pointer to the implementation of a method that returns an id. More precisely, an IMP is defined this way:
typedef id (*IMP)(id, SEL, ...)
The first two parameters are the receiver and selector values that are passed to any method; the remaining variable-length argument list holds the method's visible parameters.
You can construct an IMP from a message selector using methods of the root classes Object or NSObject. Calling a method through its IMP is considerably faster than using regular dispatch, but may not work correctly if the method does not return an id. Section 1.15 gives an example. Constants
The following constants are all defined as preprocessor symbols:
A value describing an uninitialized or invalid id. Defined to be zero.
A value describing an uninitialized or invalid Class variable. Defined to be zero.
A value of BOOL type, describing a true state. Defined to be one.
A value of BOOL type, describing a false state. Defined to be zero. Variables
These are special variables, set up for you by the Objective-C runtime:
Inside an instance method, this variable refers to the receiver of the message that invoked the method.
Not really a variable, but it looks enough like one to be included in this list. Inside a method, if you send a message to super, method dispatch will start looking in the parent class of the method's class. That is, super represents the static parent, not the parent at runtime.
A variable of type SEL, available inside any Objective-C method, and describing the selector of the method.
This is a protected field of all Objective-C objects. You do have access to it, although it's better to get it from the class method:
Class C = obj->isa;     // Discouraged.
Class C = [obj class];  // Better.
isa points to the class object representing the object's class.