Objective-C

1988年、NeXTはStepStone（Objective-Cの商標権者であるPPIの新しい社名）からObjective-Cのライセンスを取得し、GCCコンパイラを拡張してObjective-Cをサポートしました。NeXTは、NeXTSTEPユーザーインターフェースとインターフェースビルダーの基盤となるアプリケーションキット（AppKit）とファウンデーションキットライブラリを開発しました。NeXTワークステーションは市場で大きな成功を収めることはできませんでしたが、そのツールは業界で広く称賛されました。NeXTはハードウェア生産を中止し、ソフトウェアツールに注力し、NeXTSTEP（およびOPENSTEP）をカスタムプログラミングのプラットフォームとして販売しました。

GPLの条項を回避するため、NeXTは当初、Objective-Cフロントエンドを別々に出荷し、ユーザーがそれをGCCとリンクしてコンパイラ実行ファイルを生成できるようにする予定だった。当初はリチャード・M・ストールマンに受け入れられたものの、ストールマンがGNUの弁護士と相談し、NeXTがObjective-CをGCCの一部にすることに同意した後にこの計画は却下された。^{[ 12 ]}

GNU Compiler Collection (GCC) の拡張作業は、StepStone から NeXT に移籍した Steve Naroff が主導した。コンパイラの変更はGNU General Public License (GPL) の条件に従って公開されたが、ランタイムライブラリは公開されなかったため、オープンソースの貢献は一般には利用できなかった。このため、他の関係者がオープンソースライセンスの下でそのようなランタイムライブラリを開発することになった。その後、Steve Naroff は Apple でClangの Objective-C フロントエンドを構築する作業の主要な貢献者にもなった。^{[ 13 ]}

GNUプロジェクトは、OpenStep標準に基づいて、GNUstepと呼ばれるCocoaのフリーソフトウェア実装の開発に着手した。 ^{[ 14 ]}デニス・グラッティングは1992年に最初のGNU Objective-Cランタイムを作成した。1993年から使用されている現在のGNU Objective-Cランタイムは、クレステン・クラブ・トーラップがデンマークの大学生だったときに開発したものである。^{[ 15 ]}トーラップは1993年から1996年までNeXTでも働いていた。^{[ 16 ]}

1996年にNeXTを買収した後、Apple Computerは当時新開発だったオペレーティングシステムMac OS XにOpenStepを採用しました。これには、Objective-C、NeXTのObjective-Cベースの開発ツールであるProject Builder、そしてインターフェース設計ツールであるInterface Builderが含まれていました。これらは後にXcodeという1つのアプリケーションに統合されました。Appleの現在のCocoa APIのほとんどはOpenStepのインターフェースオブジェクトに基づいており、活発な開発に使用されている最も重要なObjective-C環境となっています。

2014年の世界開発者会議（WWDC）で、Appleは「C言語のないObjective-C」と特徴づけられる新しい言語Swiftを発表しました。 ^{[ 17 ]}

Objective-C のオブジェクト指向プログラミングモデルは、オブジェクトインスタンスへのメッセージパッシングに基づいています。Objective-C では、メソッドを呼び出すのではなく、メッセージを送信します。これは、C++で使用されるSimulaスタイルのプログラミングモデルとは異なります。これら 2 つの概念の違いは、メソッド名またはメッセージ名によって参照されるコードの実行方法にあります。Simula スタイルの言語では、ほとんどの場合、メソッド名はコンパイラによってターゲットクラスのコードセクションにバインドされます。SmalltalkとObjective-C では、メッセージのターゲットは実行時に解決され、受信オブジェクト自体がメッセージを解釈します。メソッドはセレクタまたは(各メッセージ名の一意の識別子、多くの場合、その名前を表す で終わる文字列) によって識別され、それを実装するC メソッドポインタ( ) に解決されます。[ ^{22 ]この}結果、メッセージパッシングシステムには型チェックがありません。メッセージの宛先オブジェクト (受信側) はメッセージに応答することが保証されておらず、応答しない場合は例外が発生します。^{[ 23 ]}SELNULIMP

methodポインタが指すオブジェクトにメッセージを送信するには、C++objで次のコードが必要になります。

obj ->メソッド(引数);

Objective-Cでは、これは次のように記述されます。

[オブジェクトメソッド:引数]

「メソッド」呼び出しは、コンパイラによってobjc_msgSend(id self, SEL op, ...)ランタイム関数のファミリーに変換されます。^{[ 24 ]}さまざまな実装では、などの最新の追加機能を扱いますsuper。^{[ 25 ]} GNU ファミリーでは、この関数はという名前ですobjc_msg_sendvが、の最新のルックアップ システムに置き換えられ、非推奨になっていますobjc_msg_lookup。^{[ 26 ]}

どちらのプログラミングスタイルにも、それぞれ長所と短所があります。Simula ( C++ ) スタイルのオブジェクト指向プログラミングでは、可能な限りコンパイル時バインディングを使用することで多重継承と高速な実行が可能になりますが、デフォルトでは動的バインディングはサポートしていません。また、抽象メソッドでない限り、すべてのメソッドに対応する実装が必須となります。Objective-C で使用される Smalltalk スタイルのプログラミングでは、メッセージを未実装のままにすることができ、メソッドは実行時にその実装に解決されます。例えば、メッセージをオブジェクトのコレクションに送信し、そのうちの一部のみが応答することを期待しても、実行時エラーが発生する心配はありません。メッセージパッシングでは、コンパイル時にオブジェクトを定義する必要もありません。ただし、派生オブジェクトでメソッドを呼び出すには、実装が必要です。（動的（遅延）バインディングのその他の利点については、下記の動的型付けのセクションを参照してください。）

Objective-Cでは、クラスのインターフェースと実装を別々に宣言されたコードブロックに記述する必要があります。慣例として、開発者はインターフェースをヘッダーファイルに、実装をコードファイルに配置します。通常、拡張子が.hとなるヘッダーファイルはC言語のヘッダーファイルに似ており、拡張子が.mとなる実装（メソッド）ファイルはC言語のコードファイルに非常によく似ています。

@interface ClassName : SuperclassName { // インスタンス変数} + classMethod1 ; + ( return_type ) classMethod2 ; + ( return_type ) classMethod3: ( param1_type ) param1_varName ;- ( return_type ) instanceMethod1With1Parameter: ( param1_type ) param1_varName ; - ( return_type ) instanceMethod2With2Parameters :( param1_type ) param1_varName param2_callName :( param2_type ) param2_varName ; @終わり

class ClassName : public SuperclassName { protected : // インスタンス変数public : // クラス (静的) 関数static void * classMethod1 (); static return_type classMethod2 (); static return_type classMethod3 ( param1_type param1_varName );// インスタンス（メンバ）関数return_type instanceMethod1With1Parameter ( param1_type param1_varName ); return_type instanceMethod2With2Parameters ( param1_type param1_varName , param2_type param2_varName = default ); };

- ( void ) setRangeStart: ( int ) start end: ( int ) end ; - ( void ) importDocumentWithName: ( NSString * ) name withSpecifiedPreferences :( Preferences * ) prefs beforePage :( int ) insertPage ;

@implementation classname + ( return_type ) classMethod { // 実装} - ( return_type ) instanceMethod { // 実装} @end

- ( int )メソッド: ( int ) i { return [ self square_root : i ]; }

int function ( int i ) { return square_root ( i ); }

- ( void ) changeColorToRed: ( float ) red green: ( float ) green blue: ( float ) blue { //... 実装 ... }// 次のように呼び出されます: [ myColor changeColorToRed : 5.0 green : 2.0 blue : 6.0 ];

MyObject * foo = [[ MyObject alloc ] init ];

MyObject * foo = [[ MyObject alloc ] initWithString : myString ];

MyObject * foo = [ MyObject new ];

MyObject * foo = [ MyObject object ]; MyObject * bar = [ MyObject objectWithString : @"Wikipedia :)" ];

- ( id ) init {self = [ super init ];if ( self ) {// ここでオブジェクトの初期化を実行します}return self ;}

他のプログラミング言語では、これらはインターフェースと呼ばれます。

Objective-C はNeXTで拡張され、プロトコルの導入により、実装ではなく仕様の多重継承の概念が導入されました。これは、 C++の抽象的な多重継承基底クラスとして、またはインターフェース(Java やC#のように)として実現できるパターンです。Objective-C は、非公式プロトコルと呼ばれるアドホックなプロトコルと、公式プロトコルと呼ばれるコンパイラによって強制されるプロトコルを使用します。

非公式プロトコルとは、クラスが実装するかどうかを選択できるメソッドのリストです。言語自体には存在しないため、ドキュメントで規定されています。非公式プロトコルは、 NSObject のカテゴリ(下記参照) として実装され、多くの場合、実装するとクラスの動作を変更できるオプションのメソッドが含まれています。たとえば、テキストフィールドクラスには、ユーザーが入力したテキストの自動補完を実行するオプションのメソッドを持つ非公式プロトコルを実装するデリゲートがあるかもしれません。テキストフィールドは、デリゲートがそのメソッドを実装しているかどうかを (リフレクションプログラミング(リフレクション) によって) 検出し、実装している場合は、デリゲートのメソッドを呼び出して自動補完機能をサポートします。

正式なプロトコルは、Java、C#、およびAda 2005のインターフェースに似ています。これは、どのクラスでも実装を宣言できるメソッドのリストです。Objective-C 2.0より前のバージョンでは、クラスは採用を宣言したプロトコルのすべてのメソッドを実装する必要がありました。クラスが宣言したプロトコルのすべてのメソッドを実装していない場合、コンパイラはエラーを出力します。Objective-C 2.0では、プロトコル内の特定のメソッドをオプションとしてマークする機能が追加され、コンパイラはオプションのメソッドの実装を強制しなくなりました。

クラスがそのプロトコルに準拠しているとみなされるには、そのプロトコルを実装するように宣言されている必要があります。これは実行時に検出可能です。形式的なプロトコルは実装を提供することはできません。プロトコルに準拠するクラスが実装を提供することを呼び出し元に保証するだけです。NeXT/Appleライブラリでは、分散オブジェクトシステムがリモートシステム上で実行されるオブジェクトの機能を表すために、プロトコルが頻繁に使用されます。

構文

@protocol NSLocking - ( void ) lock ; - ( void ) unlock ; @end

これは、ロックという抽象的な概念が存在することを示しています。クラス定義でプロトコルが実装されていることを述べることで、

@interface NSLock : NSObject < NSLocking > // ... @end

NSLockのインスタンスは、2つのインスタンスメソッドの実装を提供すると主張しています。

Objective-C は Smalltalk と同様に動的型付けを使用できます。つまり、オブジェクトはインターフェースで指定されていないメッセージを送信できます。これにより、オブジェクトがメッセージを「キャプチャ」して、そのメッセージに適切に応答できる別のオブジェクトに送信したり、同様にメッセージを別のオブジェクトに送信したりできるため、柔軟性が向上します。この動作はメッセージ転送または委譲として知られています(下記参照)。あるいは、メッセージを転送できない場合は、エラー ハンドラを使用できます。オブジェクトがメッセージを転送しない、メッセージに応答しない、またはエラーを処理しない場合、システムは実行時例外を生成します。^{[ 29 ]}メッセージがnil (null オブジェクト ポインタ)に送信された場合、コンパイラ オプションに応じて、メッセージは黙って無視されるか、汎用例外が発生します。

変数には、オプションで静的型情報を追加することもできます。この情報はコンパイル時にチェックされます。以下の4つのステートメントでは、型情報が段階的に詳細化されています。これらのステートメントは実行時には同等ですが、追加情報によって、渡された引数が指定された型と一致しない場合にコンパイラがプログラマに警告を発することができます。

- ( void ) setMyValue: ( id ) foo ;

上記の記述において、fooは任意のクラスである可能性があります。

- ( void ) setMyValue: ( id < NSCopying > ) foo ;

上記の記述において、fooはプロトコルに準拠する任意のクラスのインスタンスである可能性があるNSCopying。

- ( void ) setMyValue: ( NSNumber * ) foo ;

上記の文において、fooはNSNumberクラスのインスタンスでなければなりません。

- ( void ) setMyValue: ( NSNumber < NSCopying > * ) foo ;

上記のステートメントでは、foo はNSNumberクラスのインスタンスである必要があり、NSCopyingプロトコルに準拠する必要があります。

Objective-Cでは、すべてのオブジェクトはポインタとして表現され、静的初期化は許可されていません。最も単純なオブジェクトは、id ( objc_obj* )が指す型であり、その型はクラスを記述するisaポインタのみを持ちます。値や構造体など、C言語の他の型は、オブジェクトシステムの一部ではないため、変更されません。この決定は、構造体とクラスが統合されているC++のオブジェクトモデルとは異なります。

Objective-Cでは、応答しない可能性のあるオブジェクトにメッセージを送信できます。オブジェクトは、応答したりメッセージを破棄したりするのではなく、応答可能なオブジェクトにメッセージを転送できます。転送は、オブザーバーパターンやプロキシパターンなどの特定のデザインパターンの実装を簡素化するために使用できます。

Objective-Cランタイムは、次の2つのメソッドを指定します。Object

• 転送方法:

  - ( retval_t ) forward: ( SEL ) sel args: ( arglist_t ) args ; // GCC の場合- ( id ) forward: ( SEL ) sel args: ( marg_list ) args ; // NeXT/Apple システムの場合

• アクション方法:

  - ( retval_t ) performv: ( SEL ) sel args: ( arglist_t ) args ; // GCC の場合- ( id ) performv: ( SEL ) sel args: ( marg_list ) args ; // NeXT/Apple システムの場合

転送を実装したいオブジェクトは、転送メソッドをオーバーライドして、転送動作を定義する新しいメソッドを追加するだけで済みます。アクションメソッドperformv::は、セレクタと引数に基づいてアクションを実行するだけなので、オーバーライドする必要はありません。型はSEL、Objective-C におけるメッセージの型です。

注：Objective-Cで一般的に使用されるフレームワークであるOpenStep、Cocoa、およびGNUstepでは、クラスは使用しませんObject。クラスのメソッドを使用して転送を行います。-(void)forwardInvocation:(NSInvocation*)anInvocationNSObject

#import <objc/Object.h>@interface Forwarder : Object { id recipient ; // メッセージを転送したいオブジェクト。}// アクセサメソッド。- ( id ) recipient ; - ( id ) setRecipient: ( id ) _recipient ; @end

#import "Forwarder.h"@implementation Forwarder - ( retval_t ) forward: ( SEL ) sel args: ( arglist_t ) args { /*  * 受信者が実際にメッセージに応答するかどうかを確認します。 * これは望ましい場合もそうでない場合もあります。たとえば、受信者が * 今度はメッセージに応答しない場合、 自身で転送を行う可能性があります。 */ if ([ recipient respondsToSelector : sel ]) { return [ recipient performv : sel args : args ]; } else { return [ self error : "受信者が応答しません" ]; } }- ( id ) setRecipient: ( id ) _recipient { [ recipient autorelease ]; recipient = [ _recipient retain ]; return self ; }- ( id ) recipient { return recipient ; } @end

#import <objc/Object.h>// シンプルな受信者オブジェクト。@interface Recipient : Object - ( id ) hello ; @end

#import "Recipient.h"@implementation受信者- ( id ) hello { printf ( "受信者がこんにちはと言っています！\n " );return self ; }@終わり

#import "Forwarder.h" #import "Recipient.h"int main ( void ) { Forwarder * forwarder = [ Forwarder new ]; Recipient * recipient = [ Recipient new ];[ forwarder setRecipient : recipient ]; // 受信者を設定します。/*  * フォワーダーは hello メッセージに応答しないことに注意してください。 * 転送されます。認識されないメソッドはすべて * 受信者 に転送されます * (フォワーダーに記述されているように、受信者がそれらに応答する場合)  */ [ forwarder hello ];[受信者リリース]; [転送者リリース];return 0 ; }

$ gcc -x objective-c -Wno-import Forwarder.m Recipient.m main.m -lobjc main.m: 関数 `main' 内: main.m:12: 警告: `Forwarder' は `hello' に応答しません$

$ ./a.out 受信者がこんにちはと言っています！

Objective-C の設計において、主な懸念事項の 1 つは、大規模なコード ベースの保守性でした。構造化プログラミングの世界からの経験から、コードを改善する主な方法の 1 つは、コードをより小さな部分に分割することであることがわかっています。Common Lisp オブジェクト システムのミックスインからヒントを得て、Objective-C のカテゴリの概念が開発され、このプロセスを支援しています。^{[ 30 ]}

カテゴリを使用すると、クラスのメソッドをランタイム時に動的に拡張できます。これにより、プログラマはオープン クラスを再コンパイルしたり、ソース コードにアクセスしたりすることなく、オープン クラスを使用できるようになりました。たとえば、システムに文字列の実装にスペル チェッカーが含まれていない場合、文字列のソース コードを変更することなく追加できます。^{[ 30 ]}

プログラムを実行すると、カテゴリ内のメソッドはクラス内のメソッドと区別がつかなくなります。カテゴリは、プライベート変数を含む、クラス内のすべてのインスタンス変数に完全にアクセスできます。

あるカテゴリが、クラス内の既存のメソッドと同じメソッドシグネチャを持つメソッドを宣言した場合、そのカテゴリのメソッドが採用されます。したがって、カテゴリはクラスにメソッドを追加するだけでなく、既存のメソッドを置き換えることもできます。この機能は、他のクラスのメソッドを書き換えることでバグを修正したり、プログラム内でクラスの動作を全体的に変更したりするために使用できます。2つのカテゴリが同じ名前でメソッドシグネチャが異なるメソッドを持っている場合、どちらのカテゴリのメソッドが採用されるかは未定義です。

他の言語もさまざまな方法でこの機能を追加しようと試みてきました。TOMはObjective-Cのシステムをさらに一歩進め、変数も追加できるようにしました。他の言語では代わりにプロトタイプベースのソリューションを使用しており、最も有名なのはSelfです。

C# とVisual Basic (.NET)言語は、拡張メソッドの形で表面上は似たような機能を実装していますが、^{[ 30 ]}クラスのプライベート変数にアクセスできません。^{[ 31 ]} Rubyや他のいくつかの動的プログラミング言語では、この手法を「モンキーパッチ」と呼んでいます。

Logtalkは、Objective-Cのカテゴリ機能を包含するカテゴリ（第一級エンティティとして）の概念を実装しています（Logtalkのカテゴリは、例えば新しいクラスやプロトタイプを定義する際の構成の細粒度単位としても使用できます。特に、Logtalkのカテゴリは、任意の数のクラスやプロトタイプによって仮想的にインポートできます）。

$ gcc -x objective-c main.m Integer.m Integer+Arithmetic.m Integer+Display.m -lobjc 

Objective-Cでは、プログラム内でクラスが別のクラスを完全に置き換えることが可能です。置き換えを行うクラスは、対象クラスを「なりすます」と言われます。

クラスポージングは​​Mac OS X v10.5で非推奨となり、64ビットランタイムでは利用できなくなりました。同様の機能は、カテゴリ内でメソッドスウィズリングを使用することで実現できます。メソッドスウィズリングとは、同じシグネチャを持つメソッドの実装を別のメソッドの実装と入れ替える機能です。

ポージングをサポートするバージョンでは、ターゲットクラスに送信されたすべてのメッセージは、代わりにポージングクラスによって受信されます。ただし、いくつかの制限があります。

• クラスは、直接または間接のスーパークラスのいずれかとしてのみ振る舞うことができます。
• ポージングクラスは、ターゲットクラスに存在しない新しいインスタンス変数を定義してはならない（ただし、メソッドを定義したりオーバーライドしたりすることはできる）。
• ターゲットクラスは、ポージングが行われる前にメッセージを受信して​​いない可能性があります。

カテゴリと同様に、ポージングは​​既存のクラスを全体的に拡張することを可能にします。ポージングは​​、カテゴリにはない2つの機能を提供します。

• ポージングクラスは、スーパークラスを介してオーバーライドされたメソッドを呼び出すことができ、それによってターゲットクラスの実装を取り込むことができます。
• ポージングクラスは、カテゴリで定義されたメソッドをオーバーライドできます。

例えば、

@interface CustomNSApplication : NSApplication @end@implementation CustomNSApplication - ( void ) setMainMenu: ( NSMenu * ) menu { // メニューに対して何らかの処理を行う} @endclass_poseAs ([ CustomNSApplicationクラス], [ NSApplicationクラス]);

これは、NSApplication に対する setMainMenu の呼び出しをすべてインターセプトします。

C言語では、#includeプリコンパイルディレクティブによって、ファイルのコンテンツが常にその時点でソースに挿入されます。Objective-Cにも同様のディレクティブがありますが、コンパイル単位ごとに各ファイルが一度だけ含まれるため、インクルードガード#importは不要です。

Objective-C ディレクティブは、C++ モジュールをインポートするために使用される C++ キーワード (C++20 以降) と混同してはなりません。これimportはプリプロセッサディレクティブではありません。また、 Microsoft Visual C++ (MSVC)のプリプロセッサ ディレクティブとも混同してはなりません。これは非標準であり、タイプ ライブラリをインポートするために使用されます。^{[ 32 ]}#import

2006年のWorldwide Developers Conferenceで、AppleはObjective-C言語の改訂版である「Objective-C 2.0」のリリースを発表しました。これには「最新のガベージコレクション、構文の強化^{[ 33 ]} 、ランタイムパフォーマンスの向上^{[ 34 ]} 、および64ビットサポート」が含まれています。 2007年10月にリリースされたMac OS X v10.5には、Objective-C 2.0コンパイラが含まれていました。GCC 4.6は、宣言および合成されたプロパティ、ドット構文、高速列挙、オプションのプロトコルメソッド、メソッド/プロトコル/クラス属性、クラス拡張、および新しいGNU Objective-CランタイムAPIなど、多くの新しいObjective-C機能をサポートしています。^{[ 35 ]}

Objective-C 2.0という命名は、NeXTの最後のObjective-Cバージョンが「objc4」であったことから、言語のバージョン管理システムの中断を意味する。^{[ 36 ]}このプロジェクト名は、Mac OS X Leopard (10.5)のレガシーObjective-Cランタイムソースコードの最後のリリースでも維持された。 ^{[ 37 ]}

@interface Person : NSObject { @public NSString * name ; @private int age ; }@property ( copy ) NSString * name ; @property ( readonly ) int age ;- ( id ) initWithAge: ( int ) age ; @end

@implementation Person @synthesize name ;- ( id ) initWithAge: ( int ) initAge { self = [ super init ]; if ( self ) { // 注: プロパティセッターではなく、インスタンス変数への直接代入age = initAge ; } return self ; }- ( int ) age { return age ; } @end

Person * aPerson = [[ Person alloc ] initWithAge : 53 ]; aPerson . name = @"Steve" ; // 注: ドット表記は合成セッターを使用し、// [aPerson setName: @"Steve"] と同等です。NSLog ( @"メッセージ (%@)、ドット表記 (%@)、プロパティ名 (% @)、およびインスタンス変数への直接アクセス (% @) によるアクセス " , [ aPerson name ], aPerson . name , [ aPerson valueForKey : @"name" ], aPerson -> name );

- ( void ) introduceMyselfWithProperties: ( BOOL ) useGetter { NSLog ( @"こんにちは、私の名前は%@です。" , (useGetter ? self.name : name ) ) ; //注: getterとインスタンス変数へのアクセス}

int i ; int propertyCount = 0 ; objc_property_t * propertyList = class_copyPropertyList ([ aPerson class ], & propertyCount );for ( i = 0 ; i < propertyCount ; i ++ ) { objc_property_t * thisProperty = propertyList + i ; const char * propertyName = property_getName ( * thisProperty ); NSLog ( @"Person has a property: '%s'" , propertyName ); }

// NSEnumerator を使用NSEnumerator * enumerator = [ thePeople objectEnumerator ]; Person * p ;while (( p = [ enumerator nextObject ]) != nil ) { NSLog ( @"%@ は %i 歳です。" , [ p name ], [ p page ]); }

// インデックスを使用for ( int i = 0 ; i < [ thePeople count ]; i ++ ) { Person * p = [ thePeople objectAtIndex : i ]; NSLog ( @"%@ は %i 歳です。" , [ p name ], [ p page ]); }

// 高速列挙を使用for ( Person * p in thePeople ) { NSLog ( @"%@ は %i 歳です。" , [ p name ], [ p age ]); }

Blocks は Objective-C (およびCとC++ )の拡張機能で、クロージャを作成するために特別な構文を使用します。Blocks はMac OS X 10.6 "Snow Leopard"以降、iOS 4以降、および libobjc2 1.7 とclang 3.1 以降を使用した GNUstepでのみサポートされています。 ^{[ 46 ]}

#include <stdio.h> #include <Block.h> typedef int ( ^ IntBlock )();IntBlock MakeCounter ( int start , int increment ) { __block int i = start ;return Block_copy ( ^ { int ret = i ; i += increment ; return ret ; });}int main ( void ) { IntBlock mycounter = MakeCounter ( 5 , 2 ); printf ( "First call: %d \n " , mycounter ()); printf ( "Second call: %d \n " , mycounter ()); printf ( "Third call: %d \n " , mycounter ());/* コピーされたので、解放する必要もあります */ Block_release ( mycounter );return 0 ; } /* 出力: 最初の呼び出し: 5 2 回目の呼び出し: 7  3回目の呼び出し: 9 */

Apple は、Objective 2.0 に時間の経過とともにいくつかの追加機能を追加してきました。Apple はこれらの変更が「Apple LLVMコンパイラ」（clang）のみに適用されると述べていますが、これらの変更は clang のオープンソース版にも見られます。紛らわしいことに、Apple が使用するバージョン管理は LLVM アップストリームのバージョン管理とは異なります。オープンソース LLVM のバージョン番号への変換については、Xcode § ツールチェーンのバージョンを参照してください。 ^{[ 47 ]}

NSArray * myArray = [ NSArray arrayWithObjects : object1 , object2 , object3 , nil ]; NSDictionary * myDictionary1 = [ NSDictionary dictionaryWithObject : someObject forKey : @"key" ]; NSDictionary * myDictionary2 = [ NSDictionary dictionaryWithObjectsAndKeys : object1 , key1 , object2 , key2 , nil ]; NSNumber * myNumber = [ NSNumber numberWithInt : myInt ]; NSNumber * mySumNumber = [ NSNumber numberWithInt : ( 2 + 3 )]; NSNumber * myBoolNumber = [ NSNumber numberWithBool : YES ];

NSArray * myArray = @[ object1 , object2 , object3 ] ; NSDictionary * myDictionary1 = @{ @"key" : someObject } ; NSDictionary * myDictionary2 = @{ key1 : object1 , key2 : object2 } ; NSNumber * myNumber = @( myInt ) ; NSNumber * mySumNumber = @( 2 + 3 ) ; NSNumber * myBoolNumber = @YES ; NSNumber * myIntegerNumber = @8 ;

id object1 = [ someArray objectAtIndex : 0 ]; id object2 = [ someDictionary objectForKey : @"key" ]; [ someMutableArray replaceObjectAtIndex : 0 withObject : object3 ]; [ someMutableDictionary setObject : object4 forKey : @"key" ];

id object1 = someArray [ 0 ]; id object2 = someDictionary [ @"key" ]; someMutableArray [ 0 ] = object3 ; someMutableDictionary [ @"key" ] = object4 ;

Objective-C++ は、 GNU Compiler CollectionおよびClangのフロントエンドで受け入れられる言語バリアントであり、 C++と Objective-Cの構文を組み合わせたソース ファイルをコンパイルできます。これは、 1989 年にImprovスプレッドシート プログラムの開発中に、Lotus Developmentの要請により NeXT によって開発されました。^{[ 55 ]}「Objective-C++」という用語は、かつてAppleの Objective-C コンパイラのドキュメントにも記載されていましたが、現在は削除されています。^{[ 56 ]}

Objective-C++は、Objective-CがCに追加した拡張機能をC++に追加します。さまざまな言語機能の背後にある意味論を統一するための措置は何も講じられていないため、いくつかの制約が適用されます。

• C++クラスはObjective-C クラスから派生することはできず、その逆も同様です。 ^{[ 55 ]}
• C++の名前空間は、Objective-Cの宣言内で宣言することはできません。
• Objective-Cの宣言はグローバルスコープ内でのみ使用可能であり、C++の名前空間内では使用できません。
• Objective-C クラスは、デフォルト コンストラクタを持たない、または 1 つ以上の仮想メソッドを持つC++ クラスのインスタンス変数を持つことはできませんが、 C++ オブジェクトへのポインタは制限なくインスタンス変数として使用できます (-init メソッドで new を使用して割り当てます)。
• C++の「値渡し」のセマンティクスは、ポインタを介してのみアクセス可能なObjective-Cオブジェクトには適用できません。
• Objective-C の宣言はC++ テンプレート宣言内に含めることができず、その逆も同様です。ただし、Objective-C の型 (例: Classname *) は C++ テンプレートのパラメータとして使用できます。
• Objective-C と C++ の例外処理は別物であり、それぞれのハンドラはもう一方の型の例外を処理できません。そのため、オブジェクト デストラクタは実行されません。最近の「Objective-C 2.0」ランタイムでは、Objective-C 例外が完全に C++ 例外に置き換えられるか (Apple ランタイム)、Objective-C++ ライブラリがリンクされている場合は部分的に置き換えられるため ( GNUStep libobjc2)、この問題は軽減されています。^{[ 56 ]}
• Objective-C のブロックと C++11 のラムダは別個のものです。ただし、macOS では、ブロックが期待される場所にラムダを渡すと、ブロックが透過的に生成されます。^{[ 57 ]}

AppleによるNeXT買収後、 SmalltalkよりもJavaに慣れ親しんだプログラマーにとってより受け入れやすい言語にするための試みが行われた。その試みの一つが、当時Objective-Cに「モダン構文」と呼ばれたものを導入することであった^{[ 58 ]}（現在の「クラシック」構文とは対照的）。動作に変更はなく、これは単なる代替構文であった。メソッド呼び出しを次のように記述する代わりに、

object = [[ MyClass alloc ] init ]; [ object firstLabel : param1 secondLabel : param2 ];

代わりに次のように書かれました

object = ( MyClass.alloc ) .init ; object.labels ( param1 , param2 ) ;​​​

同様に、宣言は

- ( void ) firstLabel : ( int ) param1 secondLabel : ( int ) param2 ;

に

- ( void ) labels ( int param1 , int param2 );

この「現代的な」構文は、現在のObjective-C言語の方言ではサポートされていません。

GNUプロジェクトは、NeXTおよびObj-Cプログラムを移植するためのプラットフォームに長年関心を寄せてきた。GCCのlibobjcディレクトリの変更履歴は、それが1998年（GCC 2.95）以前から存在していたことを示唆しており、READMEには1993年（GCC 2.4）に書き直されたことがさらに記されている。^{[ 59 ]}

NeXTフロントエンドのソースコードは、GCCの一部として作成されたため、派生作品を作成する者にライセンスの公開を義務付けるGNU General Public Licenseに基づいて公開されました。Appleはこの伝統を受け継ぎ、GCCのフォークを4.2.1までリリースしましたが、その後コンパイラを放棄しました。GCCのメンテナーは変更を取り入れましたが、Objective-C 2.0言語などの新しい機能のサポートにはあまり投資しませんでした。^{[ 36 ]：どのコンパイラ}

GNUstepの開発者たちは、新しい言語に興味を持ち、 2009年にGCCのlibobjcをフォークして、GCCとは独立したプロジェクトであるlibobjc2を作成しました。また、新しい言語構文を活用するために、ランタイムをClangで使用するように手配しました。^{[ 36 ]：どのコンパイラか}。GCCは同時期にゆっくりと動いていましたが、GCC 4.6.0（2011年）ではlibobjcでもObjective-C 2.0に移行しました。^{[ 35 ] [ 60 ]} GNUstepのドキュメントによると、GCCの実装ではブロック、非脆弱変数、および新しいARCのサポートがまだ不足しているとのことです。^{[ 36 ]：どのランタイムか。}

Microsoft は2015 年にObjFWのランタイムをWinObjC (Universal Windows Platform用の iOS ブリッジ)の一部としてフォークしましたが、2016 年にlibobjc2のフォークに切り替えました。独自のCocoa Touch実装と基盤となる API と組み合わせることで、このプロジェクトは UWP アプリ内で iOS アプリケーション コードを再利用することを可能にします。^{[ 61 ]}

Windows では、Objective-C 開発ツールが GNUStep の Web サイトからダウンロードできます。GNUStep 開発システムは、GNUstep MSYSシステム、GNUstep Core、GNUstep Devel、GNUstep Cairo、ProjectCenter IDE (Xcode に似ていますが、それほど複雑ではありません)、Gorm (Xcode のような NIB ビルダーであるインターフェースビルダー) で構成されています。これらのバイナリインストーラーは 2016 年以降更新されていないため^{[ 62 ]} 、 CygwinまたはMSYS2でビルドしてインストールする方が良いかもしれません。

LLVMプロジェクトの一部であるClangコンパイラスイートは、Objective-Cやその他の言語を実装しています。GCC 4.3（2008年）がGPLv3に移行した後、AppleはGCCを放棄し、より法的に修正権限のあるclangを採用しました。その結果、最新のObjective-C言語機能の多くはClangでのみサポートされています。^{[ 47 ]}

Appleのclangベースの「LLVMコンパイラ」のバージョン管理方式は、LLVMのオープンソース版のバージョン管理とは異なります。翻訳については、Xcode § ツールチェーンのバージョンを参照してください。 ^{[ 47 ]}

mulle-objc は、パフォーマンス重視の Objective-C 実装です。純粋なC11で書かれたランタイム ライブラリを使用しており、移植性を確保しています (Linux、FreeBSD、Windows などのプラットフォームをサポートしています)。ランタイム ライブラリはmuslと静的にリンクできます。コンパイラとして clang/LLVM のフォーク、デバッガとして gdb のフォークを使用しています。^{[ 63 ] [ 64 ]} mulle-objc は、意図的に機能セットを削減しており、「Objective-C 1.0 にいくつかの厳選された 2.0 機能を追加したもの」と表現するのが最も適切です。^{[ 65 ]}

Portable Object Compiler は Objective-C の代替実装でした。Portable Object Compiler によって実装された拡張機能のセットは、GCC/NeXT/Apple の実装とは異なります。特に、 Objective-C 用のSmalltalkのようなブロックが含まれていますが、OpenStep とその派生および関連で広く使用されているプロトコルとカテゴリという 2 つの機能は含まれていません。全体として、POC は言語の進化における古い、NeXT 以前の段階を表しており、Brad Cox の 1991 年の著書にほぼ準拠しています。^{[ 66 ]}

また、ObjectPakと呼ばれるランタイムライブラリも含まれており、これはCoxのオリジナルのICPak101ライブラリ（さらにSmalltalk-80クラスライブラリから派生したもの）に基づいており、OpenStep FoundationKitとはかなり根本的に異なっている。

Objective-Cの初期バージョンでは、ガベージコレクション（GC）はサポートされていませんでした。当時、この決定は議論の的となり、多くの人が、Smalltalkがガベージコレクションを実行する際の長い「デッドタイム」によってシステム全体が使い物にならなくなると考えていました。一部のサードパーティ製実装ではこの機能が追加されており、中でもBoehmガベージコレクタを使用するGNUstepが有名です。

Apple はMac OS X v10.5から Objective-C 2.0 の一部として GC を実装しました。^{[ 67 ]}この新機能は開発者の間で不評でした。Apple 自身もXcodeを除いて、社内アプリケーションを GC を使用するように変更しませんでした。^{[ 17 ]}ソフトウェアのパフォーマンスに関する懸念から iPhone では GC が利用できなかったため、採用は著しく阻害されました。^{[ 17 ] [ 67 ]} macOS のより新しいバージョンでは、ガベージ コレクションは非推奨となり、2011 年に導入された自動参照カウント(ARC) が採用されています。 ^{[ 17 ]}

ARC を使用すると、コンパイラは静的コード解析に基づいて、Objective-C コードにリテインおよびリリース呼び出しを自動的に挿入します。この自動化により、プログラマはメモリ管理コードを記述する必要がなくなります。ARC はまた、Objective-C 言語に弱い参照を追加します。^{[ 68 ] [ 69 ]}

C++とObjective-Cの設計と実装は、 C言語を拡張するための根本的に異なるアプローチを表している。

C++は、C言語の手続き型プログラミングに加えて、オブジェクト指向プログラミング、ジェネリックプログラミング、メタプログラミングの特定の形式を直接サポートしています。また、C++には、いくつかのコンテナクラスを含む大規模な標準ライブラリが付属しています。同様に、Objective-Cは、 C言語にオブジェクト指向プログラミング、動的型付け、リフレクションを追加します。Objective-C自体には標準ライブラリはありませんが、Objective-Cが使用されるほとんどの場所では、 OPENSTEP、Cocoa、GNUstepなどのOpenStepライクなライブラリが使用され、C++の標準ライブラリと同様の機能を提供します。

注目すべき違いの一つは、Objective-Cがリフレクティブプログラミング機能の実行時サポートを提供しているのに対し、C++はCにわずかな実行時サポートを追加するにとどまっている点です。Objective-Cでは、オブジェクト自身のプロパティ（例えば、特定のメッセージに応答するかどうかなど）について問い合わせることができます。C++では、外部ライブラリを使用しない限り、これは不可能です。

リフレクションの使用は、言語の動的（実行時）機能と静的（コンパイル時）機能という、より広範な区別の一部です。Objective-CとC++はどちらも両方の機能を組み合わせて使用​​しますが、Objective-Cは実行時決定を優先し、C++はコンパイル時決定を優先します。動的プログラミングと静的プログラミングの間の緊張関係には、プログラミングにおける多くの古典的なトレードオフが関係しています。動的機能は柔軟性を高め、静的機能は速度と型チェックを向上させます。

ジェネリックプログラミングとメタプログラミングは、実行時ポリモーフィズム（動的ディスパッチ）を使用して、どちらの言語でも実装できます。C++ では、これは仮想関数と実行時型識別という形で実現されますが、Objective-C では動的型付けとリフレクションが提供されます。Objective-C と C++ はどちらもコンパイル時ポリモーフィズム（ジェネリック関数）をサポートしており、Objective-C は 2015 年にこの機能を追加しました。