dequeueReusableCellWithIdentifier：forIndexPath：のindexPathはどこで使用されますか？
Appleのドキュメントには、indexPathパラメータについて記載されています。
セルの場所を指定するインデックスパス。データソースは、セルを要求されたときにこの情報を受け取り、それを渡す必要があります。このメソッドは、インデックスパスを使用して、テーブルビューでのセルの位置に基づいて追加の構成を実行します。
ただし、register(Class|Nib):forCellReuseIdentifier:は、使用する再利用識別子のみを指定し、セクションまたはインデックスパスのセットは指定しません。
おそらくUITableViewCellにはインデックスパスを取得する方法があると思ったので、セクションの最初の行にある場合は、たとえば、角を曲がることができますが、表示されません。作成時に取得されるのは、スタイルと再利用識別子（initWithStyle:reuseIdentifier:）;再利用時には、prepareForReuseだけが通知されます。
古いものとして見るdequeueReusableCellWithIdentifier:はまだサポートされていますが、とにかくそれを行う機会があることに頼ることができない場合、どのような種類のインデックスパスベースの構成を行うことができますか？
テーブルビュープログラミングガイドを確認しましたが、iOS5以降更新されていません。
WWDC 2012セッション200-Cocoa Touchの新機能によると、
- dequeueReusableCellWithIdentifier:forIndexPath:を使用してセルをデキューすると、セルのcontentView内で適切なサイズでレイアウトが可能になりますになります。
これは、UIKitエンジニアのChrisParkerからの引用です。
IOS 6までは、レイアウトを調整する場合は、UITableViewCellをサブクラス化し、- layoutSubviewsをオーバーライドする必要がありました。カプセル化の観点からは、これが依然として優れたソリューションである可能性がありますが、わずかな調整が必要な場合もあり、代わりに- tableView:cellForRowAtIndexPath:でそれを行うことができます。
dequeueReusableCellWithIdentifier:とdequeueReusableCellWithIdentifier:indexPath:の最も重要な違いは、これらが異なるメソッドであるということです。したがって、それらは異なる動作をする可能性があり、実際に動作します。これは実際にはindexPathとは何の関係もありません。それらを区別する方法が必要です。
新しい方法
特に、dequeueReusableCellWithIdentifier:indexPath:を呼び出す場合、これは新しいiOS6の登録とデキューシステムを使用していることを示しています。したがって、この識別子の登録に失敗した場合は、Niceクラッシュと、問題を説明するログメッセージが表示されます。このメソッドはnilを返すことはありません。新しいセルを作成するか、セルを再利用することにより、常にセルを返します。
古い方法
一方、プレーンでシンプルなdequeueReusableCellWithIdentifier:は古く、下位互換性が必要です。この識別子を登録していない場合でも、文句は言われません。nilが返されるだけで、高くて乾燥したままになります。古き良き時代のように、自分でセルを作成する必要があります。
編集：しかし、@ svenaによる回答も参照してください！新しい方法（indexPath:を使用）には、私が知らなかった2番目の利点があります。セルは、返されるときに正しいサイズになっています。
tableView:heightForRowAtIndexPath:メソッドが存在する場合はそれを呼び出すために使用され、セルのサイズを正しく設定できると思います。