例

あるいは、Live++に同梱されているサンプル（別個のダウンロードとして入手可能）を見てください。これらのサンプルには、Visual Studio 2017、2019、および2022用の既製のソリューションとプロジェクトが付属しており、Live++が提供するさまざまな機能を実演しているため、自分で何もセットアップすることなく実験することができます。

ディレクトリ構造

Live++ビルドのディレクトリ構造の例です：

Broker

Brokerは、Live++のメイン・アプリケーション・プロセスです。Live++のAgentが接続するサーバーとして動作します。Brokerは、一度起動すれば、ずっと実行し続けることができる長時間実行アプリケーションです。ターゲット アプリケーションを閉じたり、再度開いたりするたびに、Brokerを再起動する必要はありません。さらに、Brokerは、.pdbや.obj形式のファイルなど、Live++に必要なファイルの内部キャッシュを保存するため、アプリケーションの一部だけが再起動の間に変更された場合のロード時間が大幅に改善されます。

ローカル接続の場合、Live++ Agentがターゲット アプリケーションにロードされると同時に、Brokerが自動的に起動します。

Brokerは特定のポートで着信接続をリッスンするサーバーとして動作するため、複数のBrokerを同時に実行できるのは、各Brokerが異なるポートを通信に使用する場合に限られます。

Agent

AgentはBrokerまたはBridgeから指示されたタスクを実行します。エージェントは、小さな共有ライブラリ（Windows と Xbox の .dllなど）として出荷され、対応する API を通して利用可能なエージェントのいずれかを作成する際に、ターゲットアプリケーションにロードされます。

このアプローチにより、Unity Nativeプラグイン、Autodesk Mayaプラグインなど、Live++について何も知らず、ホットリロード機能が組み込まれていないアプリケーションであっても、完全に任意のターゲットアプリケーションにロードされるモジュールでLive++を使用することが可能になります。

Bridge

特定のプラットフォーム（WindowsやXboxなど）では、BridgeはAgentとBrokerの間の中間プロセスとして機能し、Brokerは必ずしもAgentと同じマシン上で実行されないため、ネットワークホットリロードなどの機能を提供するために必要です。しかし、Bridgeはユーザにとって完全に透過的でなければなりません。

通信

Agent と Bridge は常に同じマシン上で動作するため、互いに Named Duplex Pipes を介して通信します。

Bridge と Broker は、グローバル環境設定で設定したホスト名または IP アドレスを使用して、ポート 12216 で TCP/IP 経由で互いに通信します。

コンパイラ設定

MSVC/Visual Studio

Live++を使用する各プロジェクトの構成プロパティで、これらのコンパイラ設定を有効にする必要があります：

C/C++ -> General -> Debug Information Format、C7 compatible (/Z7)またはProgram Database (/Zi)に設定する必要があります。

C/C++ -> Code Generation -> Enable Minimal RebuildをNo (/Gm-)設定する必要があります。

x86/Win32プロジェクトでは、さらに以下のコンパイラ設定が必要です：

C/C++ -> Code Generation -> Create Hotpatchable ImageをYes (/hotpatch)に設定する必要があります。

Clang-cl

clang-clを使ってコンパイルしたコードは、以下のオプションを設定する必要があります：

-Z7 - オブジェクトファイルのCodeViewデバッグ情報を有効にする。

-hotpatch - ホットパッチ可能なイメージを作成します。

-Gy - 各関数をそれ自身のセクションに置く

-fstandalone-debug - バイナリからデバッグ情報を削除する内部最適化を無効にする。

-Xclang -mno-constructor-aliases - コンストラクタとデストラクタを折りたたむ/エイリアスする内部最適化を無効にする。

Clang++

clang++はMSVC/Visual Studioコンパイラオプションを理解しないので、clang++を使ってコンパイルしたコードには以下のオプションを設定する必要があります：

-g - ソースレベルのデバッグ情報を生成する。

-g - ソースレベルのデバッグ情報を生成します。

-fms-hotpatch - 実行時にすべての関数をホットパッチできるようにします。

-ffunction-sections - 各関数を独自のセクションにまとめる

-fstandalone-debug - バイナリからデバッグ情報を削除する内部最適化を無効にする。

-Xclang -mno-constructor-aliases - コンストラクタとデストラクタを折りたたむ/エイリアスする内部最適化を無効にする。

リンカ設定

MSVC/Visual Studio

これらのリンカー設定は、Live++を使用する各プロジェクトの構成プロパティで有効にする必要があります：

Linker -> General -> Create Hotpatchable ImageはEnabled (/FUNCTIONPADMIN)。

Linker -> Optimization -> ReferencesはNo (/OPT:NOREF)。

Linker -> Optimization -> Enable COMDAT FoldingはNo (/OPT:NOICF)。

Linker -> Debugging -> Generate Debug InfoはGenerate Debug Information optimized for sharing and publishing (/DEBUG:FULL)。

lld-link

lld-linkは MSVC/Visual Studio のリンカー・オプションと完全に互換性があります。したがって、lld-linkを使用してリンクされるコードでは、上記と同じオプションを使用する必要があります。

互換性のない設定

Live++では、コンパイラとリンカのオプションをほとんど自由に組み合わせてコードをビルドできますが、C/C++ -> Optimization -> Whole Program Optimizationをオンにしたり、Link Time Code Generation（LTCG）やLink Time Optimization（LTO）をオンにしたりすることはサポートされていません。LTCG/LTOを使用して構築されたオブジェクト・ファイルは、サポートされていない独自の形式で情報を保存するため、Live++では使用できません。

必須ファイル

モジュールに必要な情報を読み込んで再構築するために、Live++には以下のファイルが必要です：

• すべての Live++ 対応モジュールの PDB ファイル：
  PDB ファイルには、実行可能なイメージ・セクション、パブリック・シンボル、関係する翻訳ユニットやツールチェーンに関する有用な情報が含まれています。
• Live++対応モジュールにリンクされたオブジェクト・ファイル（.obj）：
  Live++が必要とするシンボル情報のほとんどすべてが、オブジェクト・ファイルから抽出され、再構築されます。
• 上記のオブジェクト・ファイルをコンパイルするために使用されたソース・ファイル（.cpp & .h）。

サポートされるセットアップ

Live++は、.exe、.dll、および.libプロジェクト、makefileベースのプロジェクト、およびカスタム セットアップとビルド システムを完全にサポートしています。技術的な観点からは、Live++はどのような種類のプロジェクトで使用されるかを気にしません。実際、Live++はプロジェクトの種類をまったく知りません。
とはいえ、プロジェクトの種類が異なると、コーディング・セッションの動作も異なります：

• アプリケーション（.exe）プロジェクト：
  Live++は、オリジナルのコンパイラー・コマンドライン・オプションを使用して.objファイルを再コンパイルし、実行プロセスのアドレス空間にロードされるパッチを生成し、既存のシンボルに対してランタイムリンクします。.exeは、2つのLive++セッション間で、ネイティブ・ツールチェーンによって自動的に再コンパイルおよびリンクされます。
• ダイナミック・ライブラリ（.dll）プロジェクト：
  アプリケーション・プロジェクトと同様に、個々の .obj ファイルが再コンパイルされます。.dllは、セッション間でネイティブツールチェーンによって自動的に再コンパイルおよびリンクされます。
• 静的ライブラリ（.lib）プロジェクト：
  アプリケーション プロジェクトと同様に、.lib ファイルの一部である個々の .obj ファイルは再コンパイルされます。ただし、Live++はこれらの.objファイルを含む静的ライブラリをリンクしません。2 つの Live++ セッションの間に、ネイティブ ツールチェーンは、まず、再コンパイルされたオブジェクト ファイルを含むすべての .lib ファイルをコンパイルおよびリンクし、次に、これらの .lib ファイルを消費するすべてのアプリケーションおよびダイナミック ライブラリを再リンクします。
• Makefile ベースのプロジェクト:
  makefile の内容に応じて、上記のいずれかと同様です。
• カスタムセットアップとビルドシステム:
  上記のいずれかと似ていますが、セットアップを使用してビルドされるものに依存します。

FASTBuild

FASTBuildをビルド・システムとして使用する場合、特別な設定は必要ありません。

唯一の例外は、/FI コンパイラ・オプションと組み合わせて分散コンパイルを使用する場合です。この場合、FASTBuild は個々の翻訳ユニットをローカルで前処理してからリモート・エージェントに分散しますが、その際に /FI オプションは削除されます。その結果、生成される PDB ファイルから /FI オプションが欠落し、Live++ を使用した再コンパイルに失敗する可能性があります。

この場合、プロジェクト環境設定で指定できる追加コマンドラインオプションを使って、/FIオプションをLive++に与える必要があります。

Incredibuild

Incredibuild は、プリコンパイルされたヘッダー・ファイルと一緒に分散ビルドを使 用すると、異なる PDB に対してビルドされた同じプリコンパイルされたヘッダー (例:C:˶ProjectPCH.pch)を使用する複数の個別の PDB (例:C:˶ProjectSourceFile_cpp_ib_1.pdb、 C:˶ProjectSourceFile_cpp_ib_2.pdb、など)を生成することがあります。厳密に言えば、これはMicrosoftのコンパイラツールチェーンでは許可もサポートもされておらず、再コンパイルしようとするとLive++がエラーC2858を出すことになります。

この場合、ファイルを再コンパイルするときに、対応するPCHと同じPDBを使用するようにLive++に強制するために、「プリコンパイルされたヘッダーPDBの使用を強制する」設定を使用する必要があります。

分散ビルド

分散コンパイルを使用する場合、ビルド・システムはコンパイラ実行ファイルと必要なすべての補助ファイルをリモート・マシンにコピーし、リモート・マシンでコンパイル・プロセスを開始し、出力をビルドを開始したマシンにコピーして戻します。この場合、Live++がコンパイラとリンカの実行ファイルを見つけるために使用する PDB ファイルには、リモート・マシン上のパスが含まれる。

Live++を使用してファイルを再コンパイルする場合、このパスは使用できないため、「コンパイラ・パスを上書きする」設定を使用し、ローカル・コンパイラが見つかる場所をLive++に伝える必要があります。

エージェント

要件に応じて、現在2種類のエージェントから選択できます。ほとんどのAPIはすべてのエージェントで共有されていますが、細かい制御のための追加APIを提供するエージェントもあります。エージェントは、以下のAPIを使用して作成および破棄できます：

デフォルトエージェントの作成

ほとんどのアプリケーションやプロジェクトでは、最初にデフォルトエージェントを作成します：

// include the API for Windows, 64-bit, C++
#include "LivePP/API/x64/LPP_API_x64_CPP.h"

int main(void)
{
  // create a default agent, loading the Live++ agent from the given path, e.g. "ThirdParty/LivePP"
  lpp::LppDefaultAgent lppAgent = lpp::LppCreateDefaultAgent(nullptr, absoluteOrRelativePathWithoutTrailingSlash);

  // bail out in case the agent is not valid
  if (!lpp::LppIsValidDefaultAgent(&lppAgent))
  {
    return 1;
  }

  // enable Live++ for certain modules
  // ...

  // run the application
  // ...
  Application::Exec();

  // destroy the Live++ agent
  lpp::LppDestroyDefaultAgent(&lppAgent);

  return 0;
}

内部的には、要求されたプラットフォームと言語用の正しい共有ライブラリをロードし、いくつかの整合性チェックを実行してから、利用可能なすべてのAPIで返されたオブジェクトを満たします。返されるLppDefaultAgentオブジェクトは、関数ポインタを使用して共有ライブラリにAPIを格納する、プラットフォームに依存しない型です。

上記のコード例では、デフォルトのエージェントがメイン ループ、エンジン フレームなどについて何も知る必要がないことに注意してください。このアプローチの利点は、ゲームやゲーム エンジンのような典型的なUpdate, Render, Presentループに従わないアプリケーションと美しく統合できるため、イベントベースのアプリケーションでも動作することですQtを使って構築しました。

同期エージェントの作成

フレームベースのアプリケーションに特に有用な同期エージェントを使用すると、ホット再読み込みとホット再起動の要求をいつ、どのように処理するかを制御できます：

// include the API for Windows, 64-bit, C++
#include "LivePP/API/x64/LPP_API_x64_CPP.h"

int main(void)
{
  // create a synchronized agent, loading the Live++ agent from the given path, e.g. "ThirdParty/LivePP"
  lpp::LppSynchronizedAgent lppAgent = lpp::LppCreateSynchronizedAgent(nullptr, absoluteOrRelativePathWithoutTrailingSlash);

  // bail out in case the agent is not valid
  if (!lpp::LppIsValidSynchronizedAgent(&lppAgent))
  {
    return 1;
  }

  // enable Live++ for certain modules
  // ...

  // run the main loop
  while (MainLoop::NextFrame())
  {
    // listen to hot-reload and hot-restart requests
    if (lppAgent.WantsReload(lpp::LPP_RELOAD_OPTION_SYNCHRONIZE_WITH_RELOAD))
    {
      // client code can do whatever it wants here, e.g. synchronize across several threads, the network, etc.
      // ...
      lppAgent.Reload(lpp::LPP_RELOAD_BEHAVIOUR_WAIT_UNTIL_CHANGES_ARE_APPLIED);
    }

    if (lppAgent.WantsRestart())
    {
      // client code can do whatever it wants here, e.g. finish logging, abandon threads, etc.
      // ...
      lppAgent.Restart(lpp::LPP_RESTART_BEHAVIOUR_INSTANT_TERMINATION, 0u, nullptr);
    }

    MainLoop::Update();
    MainLoop::Render();
    MainLoop::Present();
  }

  // destroy the Live++ agent
  lpp::LppDestroySynchronizedAgent(&lppAgent);

  return 0;
}

デフォルトエージェントと同様に、返されるLppSynchronizedAgentオブジェクトは、関数ポインタを使用して共有ライブラリにAPIを格納するプラットフォームに依存しない型です。

同期エージェントは、コードパッチがフレーム中の特定の時点、例えばフレームの開始時または終了時にのみ発生することを保証するために使用できます。古いメモリレイアウトを使用して割り当てられたオブジェクトが、異なるメモリレイアウトを期待する新しいコードでアクセスされるのを防ぐためです。

さらに、同期エージェントを使用することで、フレーム途中で関数にパッチが適用されることがなくなり、古いコードを使用して更新されたオブジェクトと新しいコードを使用して更新されたオブジェクトなどの間で、わずかな動作のずれが生じることがなくなります。次の例はこれを示しています：

void UpdateNumber(float deltaTime, size_t index)
{
  g_numbers[index] += 1.0f*deltaTime;
}

void Update(float deltaTime)
{
  for (size_t i = 0u; i < numberCount; ++i)
  {
    UpdateNumber(deltaTime, i);
  }
}

void Update(float deltaTime)のループが実行されている間に、void UpdateNumber(float deltaTime, size_t index)変更された場合を考えてみましょう。この場合、いくつかの数値は古いコードで更新され、残りの数値（変更後に処理された数値）は新しいコードで更新されることになる。これはおそらくほとんどの場合問題にはなりませんが、もし問題になる場合は、synchronized Agentを使用することで、すべてのコードパッチが適用されるまで処理が保持されるようにすることができます。

Live++の有効化

エージェントを作成した後、Live++に、どのモジュールに対して有効にするかを指示する必要があります。これは、以下のエージェントAPIで行うことができます：

これらの API を呼び出す場合は、該当するモジュールがすでにプロセスにロードされていることを確認する必要があります。API自体はノンブロッキングでスレッドセーフであり、どのスレッドからでもいつでも呼び出すことができます。期待されるパスは、絶対パスでも、これらのAPIを呼び出すモジュールからの相対パスでもかまいません。

LppModulesOption列挙型には、以下のオプションがあります：

フィルター関数のコールバックを使用する場合、フィルター関数がtrue返したモジュールだけが Live++ で有効になります。

さらに、その戻り値を、モジュールへのパスを期待するAPIに直接渡すことができるため、現在/呼び出し中のモジュールのLive++を有効にするための簡単なAPIがもう一つあります：

Live++は、Enable*APIが呼び出された後にファイルの読み込みと解析を開始しますが、これらのAPIを呼び出すタイミングは完全に自由であることに注意してください。Live++がマシンに不要な待ち時間を発生させ（たとえば、非常に大きなPDBや非SSDドライブが原因）、アプリケーション起動のたびに待ち時間を発生させたくないと感じる場合は、必要なときだけLive++をロードしてもまったく問題ありません。
この場合、キーボードショートカット、ゲーム内コンソール、デバッグメニューなどを使用して、Live++のロードと有効化のみを手動で行うことが有益となる場合があります。

動的にロードされるモジュール

実行時に動的にモジュールをロードおよびアンロードする場合、アンロードする前にLive++にモジュールを無効にする必要があることを伝える必要があります。これは、いくつかの Agent API を使用して行うことができます：

これらのAPIによって無効にされたモジュールは、APIが呼び出されたときに、まだプロセスにロードされていなければなりません。繰り返しますが、API自体はノンブロッキングでスレッドセーフであり、いつでもどのスレッドからでも呼び出すことができます。期待されるパスは、絶対パスでも、これらのAPIを呼び出すモジュールからの相対パスでもよい。

上記のAPIを使用する場合、モジュールを有効にするときに使用したのと同じLppModulesOption options必ず使用してください。

さらに、Agentは、モジュールがロードされたとき、またはアンロードされたときに、それぞれLive++を自動的に有効化および無効化するAPIを提供します：

他のAPIと同様に、フィルター関数コールバックを使用すると、フィルター関数がtrue返したモジュールだけがLive++で有効になります。フィルタ関数を使用すると、どのモジュールを自動的に有効にしたり無効にしたりするかを細かく制御できます。どちらの引数もオプションなので、nullptr渡すとフィルタリングは実行されません。

ホット・リロード

ソース・コード・ファイルを変更したら、保存してctrl + alt + F11 を押します。このショートカットは、Live++アプリケーションにフォーカスがあるかどうかに関係なく機能します。

あるいは、ツールメニューから"すべての変更をホットリロード"を呼び出すこともできます：

さらに、エージェントは、任意の時点でホット・リロード操作をスケジュールするAPIも提供しています：

これは、独自のショートカットをリッスンしたり、カスタムデバッグメニューなどからLive++ホット再ロードを呼び出したりする場合に便利です。

内部的には、この操作はバックグラウンド・コンパイル処理をトリガします。コンパイルが成功すると、新しいコードがアプリケーションにロードされ、既存のコードとリンクされます。当然、元の実行ファイルに含まれていない関数も正しくリンクされます。

ユニティ分割

Live++ は、登録されたモジュールの一部である unity/jumbo/blob ファイルを自動的に検出して分割します。そのようなすべてのunityファイルに対して、Live++は、次の例に示すように、含まれるすべての.cppファイルを独自の.objファイルに分割し、再構築と再コンパイルに使用します：

// these are the contents of Unity.cpp:
#include "FileA.cpp"
#include "FileB.cpp"
#include "FileC.cpp"

Unityの分割は、統合/Jumbo/BLOB/Amalgamated ファイルの分割を有効にする設定を利用することで、プロジェクトごとに制御できます。より細かく制御したい場合は、分割したいすべてのコンパイランドのコマンドラインオプションのプリプロセッサ定義としてLPP_FORCE_UNITY_SPLITTINGを設定することで、コンパイランド単位で unity 分割を有効にすることができます。

停止したプロセス

通常、Live++は、ホット・リロード操作がスケジュールされるとすぐに、変更されたファイルを自動的に収集し、バックグラウンドでコンパイルを開始します。しかし、Live++が有効なプロセスがデバッガーに保持されている場合（ブレークポイントなど）、プロセスは何も進行しないため、Live++はそのプロセスと通信できません。

Visual Studio および Rider デバッガー

Visual Studio または Rider でデバッグする場合、Live++ はプロセスを Live++ と通信を継続できるモードにするために必要なアクションの自動化を試みます。成功すると、Broker UI ログに"自動化されたデバッガーを PID が XXXXX のプロセスにアタッチ" と表示され、Live++ は変更をコンパイルしてコード パッチをインストールします。その後、プロセスは再びデバッガの同じ命令で保持されます。

その他のデバッガ

自動化に失敗した場合、または WinDbg などの他のデバッガーを使用している場合、UI ログに"PID が XXXXX のターゲットプロセスを待っています。プロセスがデバッガーで保留中の場合は、「続行」(Visual Studio および Rider では F5) を押します。"ホット・リロード操作のスケジューリング時に表示されます。アプリケーションを再開すると、Live++がコンパイルし、行った変更をインストールします。コンパイルが終了するまで、プロセスは新しい命令を実行しません。Live++ によってパッチがインストールされると、プロセスは自動的に実行を続行します。

この場合の一連の流れを以下に示します：

1. デバッガがブレークポイントに遭遇し、プロセスを停止します。
2. 通常どおりデバッグが開始されます。
3. 現在デバッグ/実行中のコードに1つまたは複数の変更を加え、Live++のホット・リロードを呼び出します。
4. Live++は変更されたファイルをピックアップし、デバッガで処理を続行するのを待ちます。
5. F5キーを押すなどしてプロセスを続行します。
6. プロセスはまだ停止していますが、今度はLive++によって停止されます。
7. Live++はあなたの変更をコンパイルし、コード・パッチをインストールし、プロセスを続行させます。
8. プロセスは中断したところから実行を続けます。

Natvisビジュアライゼーション

Natvis 可視化は、Visual Studio デバッガによって理解されるカスタム タイプの可視化ルールです。

通常、.natvisファイルは Live++ で作成されたパッチに対してデバッガーによって自動的にピックアップされます。しかし、そうでない場合は、これらのファイルをユーザー固有またはシステム全体のNatvisディレクトリに置くことが役立ちます。

ホット・リスタート

アプリケーションを終了して再起動するときに発生するビルド時間とリンク時間に対処するため、Live++は、ロードされたデータと内部キャッシュを持続させたままアプリケーションを再起動するメカニズムを提供しています。

アプリケーションがメイン・ループに入ると、メイン・ループに入る前に呼び出されるスタートアップ関数などに加えられた変更の効果を確認するために、アプリケーションを再起動する必要があります。この場合、通常は次のような一連のイベントが発生します：

1. ユーザーがアプリケーションを閉じる。
2. ビルド・システムが実行ファイルをリンクする。
3. ユーザーがアプリケーションを再度起動する。
4. Live++でモジュールが有効になる。これにより、PDBからデバッグ・データがロードされ、内部キャッシュが構築されます。

ステップ2.と4.は、特にAAAプロジェクトではかなりの時間がかかることがあります。Live++が提供するホット・リスタート機能を利用することで、この状況をかなり改善することができます：

1. Live++は、興味のあるすべてのプロセスに再起動の準備を指示します。
2. プロセスは、何らかのクリーンアップを実行したい場合に備えて、オプションのコードを実行します。
3. Live++は、PDBからロードされたすべてのデータと内部キャッシュを維持したまま、関係するすべてのプロセスを再起動します。
4. Live++ではモジュールが有効になっている。これにより、既存のデバッグ・データとキャッシュが再利用され、以前にコンパイルされたパッチがインストールされる。

ホット再起動メカニズムを使用すると、リンク時間とLive++のロード時間がほとんど完全になくなることに注意してください。

ホット・リスタートの要求

ホットリスタートのリクエストには4つのオプションがあります：

• デフォルトのショートカットctrl + alt + R を押します。このショートカットは、Live++アプリケーションにフォーカスがあるかどうかに関係なく機能します。

• ツール・メニューから"プロセスをホットリスタート"を実行する：

  

  これにより、現在Brokerに登録されているすべてのプロセスにホット再起動要求が送信されます。

• Brokerの処理ビューで1つまたは複数のプロセスを選択し、右クリックしてコンテキスト・メニューを開き、"選択したプロセスをホットリスタート"を選択します：

  

  これにより、個々のプロセスをホットスタートさせることができ、クライアント/サーバシナリオで役立ちます。

• さらに、エージェントは、任意の時点でホットリスタート処理をスケジュールするための API も提供します：

  API	説明
  void Agent::ScheduleRestart(LppRestartOption option);	ホット再起動操作をスケジュールし、WantsRestart()ができるだけ早く true を返すようにします。

  これは、独自のショートカットをリッスンしたい場合や、カスタムデバッグメニューなどから Live++ ホット再起動を呼び出したい場合に便利です。

デフォルト・エージェント

デフォルト・エージェントを使用する場合、内部実装がホット・リスタート要求に自動的に応答します。

同期エージェント

同期エージェントを使用する場合、以下のAPIを使用してホット再起動要求に応答する必要があります：

再起動の準備

ホット リスタートが要求された後、Live++ は、再起動の準備をする必要があることを関係するすべてのプロセスに通知します。再起動が要求されると、アプリケーションは定期的に（たとえばフレームごとに）bool WantsRestart()を呼び出してtrueを返す必要があります。再起動を開始する前に、任意のクリーンアップ（ファイルのフラッシュなど）を実行できます。

再スタートの開始

アプリケーションが任意のクリーンアップタスクを実行し終わったら、すぐにvoid Restart(LppRestartBehaviour behaviour, unsigned int exitCode, const wchar_t* const commandLineArguments)呼び出す必要があります。これは Live++ にプロセスの再起動を知らせ、プロセスを終了します。const wchar_t* const commandLineArgumentsパラメータはオプションで、再起動されたプロセスに渡されます。nullptr使用すると、元のコマンドライン環境でプロセスを再起動します。

再起動されたプロセスのいずれかにアタッチされている Visual Studio または Rider デバッガは、ホット再起動操作が完了した後、Live++ によって対応するプロセスに自動的に再アタッチされます。

終了時の動作は、次の表に示すように、LppRestartBehaviour引数によって異なります：

ホットフィックス

Live++は、裏で構造化例外処理（SEH）使用するカスタムのベクトル化例外ハンドラ（VEH）を介して、すぐに使用できる強力なエラー回復を提供します。Live++のホット・リロード機能と組み合わせることで、アクセス違反やゼロによる除算など、致命的なエラーからの回復が可能になります。Live++の例外ハンドラを使用すると、プロセスが未処理の例外（アクセス違反など）を発生させるたびに、このハンドラが呼び出されます。

Visual Studio や Rider などのデバッガがプロセスにアタッチされている場合、デバッガは常に例外を処理する最初のチャンスを得ます。

デバッガでプロセスを続行すると、Live++の例外ハンドラが起動され、Brokerのダイアログが開いて、この例外の処理方法を決定することができます：

表示されたコール・スタックの行をダブルクリックすると、Visual Studio または Rider でその場所に対応するソース・ファイルが開きます。

例外ハンドラが提供するオプションは以下のとおりです：

• "命令を無効にする":
  フォールトを起こしたマシン命令を完全に無効にします。これは、再コンパイルが可能な独自のモジュール/ソースファイルから例外が発生した場合に便利なオプションですが、Visual Studio Runtime のようなサードパーティのコードなどには決して使用しないでください。
• "命令を無視":
  フォールトを発生させたマシン命令を一度だけ無視します。次に対応する関数が呼び出されたとき、その間にコードが再コンパイルされない限り、その命令は同じ例外を引き起こします。
• "終了関数":
  現在の関数を離れ、親関数で実行を継続する。さらに、完全なSEH情報が利用可能な場合、スタックは巻き戻され、ローカル変数はデストラクタが呼び出されます。
• "実行を続行":
  この例外を一旦無視して実行を続ける。この例外は、もしあれば、次にインストールされる例外ハンドラに渡される。最後にインストールされた例外ハンドラが例外を処理する機会を得た後、プロセスは（デバッガがアタッチされていれば）デバッガ内で停止するか、終了します。

例外ハンドラ・ダイアログが表示されている間は、通常どおりLive++を使用してコードを変更したり再コンパイルしたりすることができます。ただし、新しいコードはバックグラウンドでインストールされますが、プロセスの実行は障害発生時点から継続されるため、問題の例外をどのように処理するか決定する必要があることに注意してください。

ホット・デオプティマイズ

コードをその場で最適化解除することで、アプリケーションのデバッグ性と反復時間のバランスをとることができます。最適化されていないデバッグビルドは、最適化されたリテールビルドよりもはるかにデバッグしやすいのですが、開発中に使用するには遅すぎることがよくあります。一方、最適化されたビルドははるかに優れたパフォーマンスを提供しますが、デバッグが非常に困難です。

これを緩和するために、Live++ は、実行中のアプリケーションで、コードの最適化解除、コードのデバッグ、完全に最適化されたビルドへの復帰を簡単に行える機能を提供します。Hot-Deoptimize 機能を使用する場合、翻訳単位は必要に応じて最適化解除されるため、初期費用は発生しません。これは他のアプローチとは異なり、さらに Hot-Deoptimize は IDE に完全に依存せず、サポートされているすべてのプラットフォームで使用できます。

これは、最適化フラグが無効になる以外は、元のコンパイラー・オプションを使用してファイルを再コンパイルする。これは、マクロを定義するために使用されるプリプロセッサ定義やその他のフラグが、最適化解除バージョンでも設定されることを意味します。アサーションなどの機能は、デバッグビルドでのみ定義されるマクロを使用することが多いからです。

Live++が提供するオプションは以下の通りです：

• Brokerのコンパイル単位ビューで1つまたは複数のファイルを選択し、右クリックしてコンテキスト・メニューを開き、選択したコンパイル単位の最適化を切り替える選択すると、選択したコンパイランドが即座に最適化解除されます。
• また、選択したコンパイル単位を最適化戻しのために待ち行列に入れる選択することで、後で最適化を解除するためにコンパイランドをキューに入れることもできます。キューに入れたコンパイランドの最適化は、待ち行列の最適化戻しアクションを選択することで開始できます。

  

• Visual Studio または Rider のデフォルトのショートカットctrl + alt + O を押すことで、現在開いているファイルの最適化状態を切り替えることができます。
• また、ファイルの先頭にマクロLPP_DISABLE_OPTIMIZATIONSを置き、変更をホット・リロードすることでも、ファイルの最適化状態を切り替えることができます。この方法の欠点は、Live++ API"LivePP/API/x64/LPP_API_x64_CPP.h "をこのファイルで表示する必要があり、最適化解除の状態をコンパイル単位ビューで追跡できないことです。
• キューに入れられたコンパイランドは、コンテキスト・メニューの選択したコンパイル単位を最適化戻しのために待ち行列に入れる選択することで、再びキューに入れることができます。
• すべてのコンパイランドを元の最適化状態に戻したい場合は、すべてを最適化戻しアクションを選択します。

現在最適化解除状態にあるソースファイルはコンパイル単位ビューで の記号で、現在キュー状態にあるソースファイルは の記号で、それぞれ示されます：

マルチプロセス編集

ある種のクライアント/サーバーやエディター/ゲームのセットアップでは、変更を複数のプロセスや同じアプリケーションの複数のインスタンスに一度にホット・ロードできると、非常に便利です。Live++では、これはすぐに機能し、特別なセットアップを必要としません。

Brokerの処理ビューには、現在Live++に登録されているすべてのプロセスが表示されます：

Live++がサポートするすべての操作は、登録されている数に関係なく、影響を受けるプロセスまたは選択されたプロセスに対して実行されます。Live++は、複数のモジュールまたはアプリケーションの一部であるソース・ファイルの変更が、影響を受けるすべてのプロセスにコンパイルされ、ホット・ロードされることを自動的に確認します。

さらに、Live++は、実行可能ファイルがリンクされなかったり、ディスク上で変更されなかったりしても、すべてのコード変更をLive++アプリケーションの後続インスタンスにロード中に自動的に注入し、新しい動作をもたらします。その後、コードが変更されると、実行中のすべてのプロセスにホット・ロードされます。

ネットワーク編集

マルチプロセス編集と同様に、Live++を任意のマシン上で実行されているリモートプロセスで動作させるために、特別なコード設定は必要ありません。唯一の要件は、それらのリモート・プロセスがLAN接続を介してローカルBrokerに接続することであり、これは次のように設定する必要があります：

• ローカル・マシンでBrokerを起動し、ウィンドウ・タイトルに表示されているホスト名またはIPアドレス（例：192.168.8.147）をメモする：

  

• リモートマシンでBrokerを起動し、編集 -> グローバル設定... -> ネットワークに進み、Brokerを実行するローカルマシンのホスト名またはIPアドレスを入力し、保存を押します：

  

  これにより、リモートマシンのグローバル環境設定が保存されます。

ネットワーク編集を機能させるには、まずローカルマシンのアプリケーションを起動し、次にリモートマシンのアプリケーションを起動する必要があります。ただし、Live++はローカルとリモートのプロセスが混在していても、また同じアプリケーションの複数のインスタンスがどのマシンにあっても動作します。

接続されたマシンとプロセスは、それぞれターゲットビューと処理ビューで確認できます：

アクティベーション

Live++を使用する前に、まずマシン上でライセンスをアクティベートする必要があります。これを行うには、Brokerを起動し、メインメニューからライセンス許諾 -> アクティベート...選択し、ライセンスをアクティベートするプラットフォームと言語を選択します（例：Windows、C++）。アクティベーションコードとユーザーIDを入力するダイアログが開きます：

アクティベーションコードは、Live++の購入時に配布されたもので、XXXX-XXXX-XXXXという形式の12文字のキーです。

ユーザーIDは自由に選択することができ、指定されたアクティベーションコードに関連付けられたライセンスプール内であなたのライセンスを識別します。これは、オフラインでライセンスを無効化する必要がある場合に必要となります。例えば、既存のライセンスを無効化せずにマシンを再インストールした場合などです。一般的なユーザーIDの例は、"Jane home office "または"John laptop "です。

ダイアログで「OK」を押すと、Live++は入力されたデータを使ってアクティベーション・サーバーにコンタクトしようとします。指定されたアクティベーションコードが有効な場合、Live++はあなたのマシンに関連付けられ、あなただけが使用できるライセンスを生成します。それ以外の場合は、代わりにエラーが表示されます。

アクティベーションの解除

マシンの再インストールが必要な場合や、同僚が使用できるようにライセンスを失効させたい場合など、ライセンスの失効が必要な場合は、Brokerのメインメニューからライセンス許諾 -> 非アクティブ化...進み、WindowsやC++など、ライセンスを失効させたいプラットフォームと言語を選択します。これにより、アクティベーション・サーバー上のライセンスが無効化されます。

無料トライアル

まだライセンスを持っておらず、30日間の無料トライアルを試したい場合は、Live++ホット・リロードを起動すると、次のダイアログがポップアップします：

このダイアログでトライアル版を使用選択すると、Live++がアクティベーション・サーバーからトライアル・ライセンスを取得します。

コマンドライン ツール

Live++ インストールのCLIディレクトリにあるコマンド ライン ツールを使用して、ライセンスのアクティベーションとアクティベーション解除を自動化することもできます。例えば、"LPP_License_x64_CPP.exe"はWindows、C++ のライセンス管理を行います。

各ツールは、それぞれ"--activate "と"--deactivate "オプションでライセンスの有効化と無効化を行うことができます。詳細については、統合された"-h"ヘルプオプションを参照してください。

ターゲット

ターゲットビューには、接続されているローカルおよびリモートのすべてのマシン、そのプラットフォーム、IPアドレス、および登録されているプロセス数が表示されます。

処理

処理ビューには、登録されているすべてのプロセス、そのターゲット、プロセスID、実行ファイルへのフルパス、プロセスが起動したコマンドラインが表示されます。

さらに、処理ビューでは、右クリック時に以下のオプションを含むコンテキストメニューが表示されます：

• "選択したローカルプロセスのログファイルを表示":
  選択したプロセスに関連するログファイルを Windows エクスプローラーに表示します。
• "選択したローカルプロセスのログファイルを開く":
  対応するデフォルトのアプリケーションを使用して、選択したプロセスに関連するログファイルを開きます。
• "選択したプロセスをホットリスタート":
  選択したプロセスにホット再起動要求を送信します。

モジュール

モジュールビューには、ロードされたすべてのモジュール、ロードされたプロセスのID、サイズ、ロードされたアドレス範囲が表示されます。

コンパイル単位

コンパイル単位ビューには、すべてのモジュールとそのコンパイランドが、それぞれのコンパイランドのソースパスとともに階層ツリーで表示されます。

ツリービューでコンパイランドをダブルクリックすると、Visual Studio または Rider の実行中のインスタンスで対応するソースファイルが開きます。

さらに、コンパイル単位、右クリック時に以下のオプションを持つコンテキスト・メニューも提供されます：

• "詳細を表示...":
  コンパランドの詳細を別のダイアログで表示します。
• "外部アプリケーションでコンパイル単位を開く...":
  対応するデフォルトのアプリケーションを使用して、選択したコンパイランドのソースファイルを開きます。
• "選択したコンパイル単位の最適化を切り替える":
  選択したコンパランドの最適化状態を切り替えます。
• "選択したコンパイル単位を最適化戻しのために待ち行列に入れる":
  選択したコンパイランドを後で最適化解除するためにキューに入れます。

コンパイル単位の詳細ダイアログでは、PDB パス、コンパイラーパス、再コンパイルに使用したコマンドラインなど、各コンパイルランドの詳細情報が表示されます。

UI

• "言語:"
  言語を選択します。
• "初期ウィンドウの状態:"
  Broker を通常のサイズで起動するか、最大化するか、システムトレイに表示するかを選択できます。
• "スタイル:"
  明るいスタイルと暗いスタイルを選択できます。
• "バージョン不一致のエラーを表示:"
  これを有効にすると、Agent と Broker の API バージョンが一致しない場合、Broker はモーダルダイアログでエラーを表示します。
• "通知領域にアニメーションアイコンを表示:"
  これを有効にすると、操作の進行中に通知領域のアイコンがアニメーション表示されます。
• "通知領域に色付きアイコンを表示:"
  これを有効にすると、最後の操作が成功したかエラーになったかによって、通知領域のアイコンが色分けされます。
• "タスクバーに進捗を表示:"
  これを有効にすると、操作の進行中にタスクバーがアニメーション表示されます。

ロギング

• "UI ログの冗長性:"
  デフォルトのログ出力か詳細なログ出力かをカスタマイズします。
• "UI ログにタイムスタンプをプリント:"
  UIログにタイムスタンプを出力するかどうかをカスタマイズします。
• "UI ログでテキストの折り返しを有効にする:"
  UI ログにワードラッピングを使用するかどうかをカスタマイズします。

ネットワーク

• "接続先の Broker (ホスト名または IP アドレス):"
  ローカルマシン上で実行されるプロセスは、常に127.0.0.1またはlocalhost のいずれかを使用する必要があります。リモート・マシン上で動作するプロセスは、Broker IPを適宜設定する必要があります。
• "通信ポート:"
  Bridge と Broker 間の TCP/IP 接続に使用するポート。
• "Bridge を Broker に接続する際のタイムアウト (ミリ秒):"
  BridgeがBrokerに接続するときに考慮するタイムアウト。

通知

ファイルへのパスは、絶対パス、またはBrokerからの相対パスのいずれかを指定できます。

• "通知を有効にする:"
  これを有効にすると、Live++は完了した操作のトースト通知を表示します。
• "以下の場合、Broker ウィンドウにフォーカス:"
  ブローカー・ウィンドウがフォーカスされるタイミングを選択できます： never、hot-reload または hot-restart 操作時、error 時、successful 操作時、または always。
• "成功時にサウンドを再生:","成功時の通知音:"
  コンパイルが成功したときに再生する .WAV ファイルを指定します。
• "エラー発生時にサウンドを再生:","エラー時の通知音:"
  コンパイルが失敗したときに再生する .WAV ファイルを指定します。

ホットリロード

• "タイムアウト (ミリ秒):"
  ホットリロード操作をスケジューリングするときに使用するミリ秒単位のタイムアウトです。タイムアウトよりも応答が長いエージェントは、ホットリロード操作を放棄します。
• "不完全なモジュールをロード:"
  これを有効にすると、不完全なモジュールがロードされ、コンパイル単位ビューに表示されます。
• "不完全なコンパイル単位をロード:"
  これを有効にすると、未完成のコンパイランドがロードされ、コンパイル単位ビューに表示され、コンパイラ・オプションの欠落などの欠陥を検査できるようになります。
• "プロセスの終了時にパッチファイルを削除:"
  これを有効にすると、Live++パッチに属するファイルは、対応するプロセスが終了するとすぐに削除されます。
• "ホットリロード時にログをクリア:"
  これを有効にすると、ホット・リロード時に UI ログがクリアされます。
• "ホットリロードを呼び出すショートカット:"
  ホットリロードを起動するためのショートカットを設定できます。

ホットリスタート

• "タイムアウト (ミリ秒):"
  ホット再起動操作をスケジュールするときに使用するミリ秒単位のタイムアウトです。応答がタイムアウトより長いエージェントは、ホット再起動操作を放棄します。
• "ホットリスタートを呼び出すショートカット:"
  ホット再起動を起動するためのショートカットを設定できます。

IDE

• "Visual Studio でモーダルダイアログを表示:"
  これを有効にすると、ホット再起動の操作中に Visual Studio でモーダルダイアログが表示されます。これにより、Live++操作の実行中は、Visual Studioデバッガとのインタラクションが禁止されます。

  

• "ホットリロード中はブレークポイントを有効のままにする:"
  これを有効にすると、ホット・ロード操作中もブレークポイントが有効になります。通常、Visual Studio および Rider のブレークポイントは、プロセスが誤って停止しないように、ホット・リロード操作中は一時的に無効になります。
• "IDE で現在開いているファイルの最適化を切り替えるショートカット:"
  Visual Studio または Rider で現在開いているファイルの最適化を切り替えるショートカットを設定できます。

ライセンス

• "ライセンスの有効期限が近づいたら警告を表示:"
  これを有効にすると、Broker は現在のライセンスが期限切れになるたびに警告を表示します。
• "残り日数が次の値に達したら警告:"
  ライセンスが期限切れになりそうなときに何日分の警告を表示するかを設定できます。

一般

プロジェクト環境設定を使用する場合、2つのオプションがあります：

• 次の例に示すように、エージェントを作成するときに、プロジェクト固有の .json ファイルを引数として渡します：

  // create a synchronized Live++ agent, loading the required project preferences.
  // the path to load the preferences from can be absolute, or relative to this application.
  lpp::LppSynchronizedAgent lppAgent = lpp::LppCreateSynchronizedAgentWithPreferencesFromFile(nullptr, L"ThirdParty/LivePP", L"Preferences/continuous_compilation.json");

• デフォルトのlpp::LppProjectPreferencesインスタンスを作成し、エージェントを作成する際の引数として渡す：

  // disable unity splitting in the preferences
  lpp::LppProjectPreferences prefs = lpp::LppCreateDefaultProjectPreferences();
  prefs.unitySplitting.isEnabled = false;
  
  // create a default Live++ agent with the project preferences
  lpp::LppDefaultAgent lppAgent = lpp::LppCreateDefaultAgentWithPreferences(nullptr, L"ThirdParty/LivePP", &prefs);

エージェントを作成するときに、.jsonファイルへのパスも環境設定インスタンスも渡さない場合、Live++は、すべてのプロジェクト環境設定のデフォルト値を想定します。

• "ローカルな接続用に Broker を自動的に起動:"
  これを有効にすると、Agent がターゲットアプリケーションにロードされるとすぐに、Agent はローカル接続用の Broker を自動的に起動します。
• "Bridge から Broker への接続に失敗した場合、エラーを表示:"
  これを有効にすると、Bridge は Broker に接続できない場合にエラーを報告します。
• "Broker へのディレクトリ:"
  Agent によって生成される Broker へのディレクトリを指定します。ディレクトリは、絶対ディレクトリまたは Agent からの相対ディレクトリのいずれかを指定します。

ホットリロード

• "ツールチェーン環境をキャプチャする際のタイムアウト (ミリ秒):"
  Visual Studioのコンパイラとリンカの環境をキャプチャするときに使用するミリ秒単位のタイムアウトです。タイムアウト時間を超えて実行されたバッチファイルは、自動的に中止されます。
• "オブジェクトファイルとして考慮されるファイル拡張子:"
  オブジェクト・ファイルで考慮されるファイル拡張子のリスト。その他のファイル拡張子は無視されます。
• "ライブラリファイルとして考慮されるファイル拡張子:"
  ライブラリ ファイル用に考慮されるファイル拡張子のリスト。その他のファイル拡張子は無視されます。
• "ソースファイルとして考慮されるフィルター:"
  ソース・ファイルのフィルタリングに使用されるセミコロンで区切られた文字列のリスト。フィルタのいずれかを含むソース・ファイルは完全に無視されます。フィルター・チェックは、小文字のソース・パスを使用して実行されます。
• "プレビルドの手順を有効にする:"
  Live++ がホット・リロード操作ごとにプリビルド・ステップを実行するかどうかを指定します。
• "プレビルドの手順実行可能ファイル:"
  プリビルドステップを実行するときに呼び出される実行ファイルを選択できます。
• "プレビルドの手順作業ディレクトリ:"
  プリビルドステップを実行するときに使用する作業ディレクトリーを選択できます。
• "プレビルドの手順コマンドラインのオプション:"
  プリビルド・ステップを実行するときに呼び出される実行ファイルに渡されるコマン ド・ライン・オプションを指定します。
• "停止したプロセスのコンパイルフックを呼び出す:"
  Live++ が停止したプロセスのコンパイル・フックを呼び出すかどうかを指定します。
• "停止したプロセスのリンクフックを呼び出す:"
  Live++ が停止したプロセスのリンク フックを呼び出すかどうかを指定します。
• "停止したプロセスのホットリロードフックを呼び出す:"
  停止したプロセスに対して Live++ がホット リロード フックを呼び出すかどうかを指定します。

コンパイラ

ファイルへのパスには、絶対パスとBrokerからの相対パスがあります。

• "コンパイラーツールチェーン環境をキャプチャ:"
  Live++がvcvars*.batコンパイラー・ツールチェーン環境を検索して使用するかどうかを設定します。この設定を無効にすると、カスタム ビルド システムに便利です。
• "コンパイラーパスをオーバーライド:"
  PDB で見つかったコンパイラ・パスを上書きして、Live++ がファイルを再コンパイルするときに、代わりにこのコンパイラを使用するようにします。カスタム ビルド システムを使用する場合にのみ必要です。
• "オーバーライドされたコンパイラーパスをフォールバックのみとして使用:"
  これを有効にすると、PDB で検出されたコンパイラが使用できない場合にのみ、オーバーライドされたコンパイラ・パスが使用されます。
• "追加のコマンドラインオプション:"
  パッチを作成するときにコンパイラに追加のオプションを渡すことができます。
• "プリコンパイル済みヘッダー PDB を強制的に使用:"
  これを有効にすると、再コンパイル時に各翻訳ユニットが対応するプリコンパイルされたヘッダーと同じPDBを使用するようにLive++を強制します。これは、Incredibuildをリモートエージェントとプリコンパイルされたヘッダーファイルで使用した場合に発生するコンパイラーエラーC2858の回避策として意図されています。
• ""-showIncludes" コンパイラーオプションを削除:"
  これを有効にすると、一部のビルドシステムで使用されている-showIncludesコンパイラーオプションが、コードの再コンパイル時に削除されます。
• ""-sourceDependencies" コンパイラーオプションを削除:"
  これを有効にすると、一部のビルド・システムで使用されている-sourceDependenciesコンパイラー・オプションが、コードの再コンパイル時に削除されます。

リンカ

ファイルへのパスには、絶対パスと Broker からの相対パスを指定できます。

• "リンカーツールチェーン環境をキャプチャ:"
  Live++ が vcvars*.bat リンカー・ツールチェーン環境を検索して使用するかどうかを設定します。この設定を無効にすると、カスタム ビルド システムに便利です。
• "リンカーパスをオーバーライド:","オーバーライドされたリンカーパス:"
  ファイルを再コンパイルするときに、Live++が代わりにこのリンカーを使用するように、PDBで見つかったリンカー パスを上書きします。カスタム ビルド システムを使用する場合にのみ必要です。
• "オーバーライドされたリンカーパスをフォールバックのみとして使用:"
  これを有効にすると、PDB で検出されたリンカが使用できない場合にのみ、オーバーライドされたリンカ・パスが使用されます。
• "追加のコマンドラインオプション:"
  パッチを作成するときにリンカに追加のオプションを渡すことができます。
• "インポートライブラリの作成を抑制 (/NOIMPLIB):"
  パッチDLLを作成するとき、リンカによっては、シンボルをエクスポートしないDLLであっても、インポート・ライブラリの作成を要求するものがあります。Live++はこれらのインポート・ライブラリを必要としませんが、一部の古いリンカは/NOIMPLIBオプションを理解しません。

例外

• "例外ハンドラーを有効にする:"
  これを有効にすると、Live++はHot-Fix機能用の例外ハンドラをインストールします。
• "例外ハンドラーを以下としてインストール:"
  例外ハンドラを最初のハンドラとしてインストールするか、最後のハンドラとしてインストールするかを選択できます。

連続コンパイル

ディレクトリは、絶対ディレクトリ、または Broker からの相対ディレクトリのいずれかを指定できます。

• "連続コンパイルを有効にする:"
  連続コンパイルを有効にすると、Live++は指定されたディレクトリ（およびそのサブディレクトリ）の変更通知を待機し、タイムアウトが経過すると、変更があれば自動的にコンパイルします。
• "監視するディレクトリ:"
  連続コンパイル使用時に変更を監視するディレクトリを設定します。
• "変更をリッスンする際のタイムアウト (ミリ秒):"
  変更通知を待機しているとき、Live++はタイムアウトに達するまで後続の変更を待機します。

仮想ドライブ

一部のビルド・システムでは、ビルド中に使用するすべてのツールが同じパスを参照できるように、コードのビルド時に一時的に仮想ドライブを設定します。しかし、コンパイルされたモジュールのPDBファイルには、この仮想ドライブ上のパスが含まれることになり、アプリケーションを起動してLive++を使用するときに、このパスが使用できなくなることがあります。以下のオプションで仮想ドライブを設定できます：

• "ドライブ (例:Z:):"
  指定したディレクトリにマッピングされる仮想ドライブの文字を指定します。文字列の後には、"Z:"（引用符なし）のようにコロンを付ける必要があります。
• "ディレクトリ:"
  上記で指定されたドライブ文字にマップされるディレクトリを設定できま す (例: C:\MyPath)。

ユニティ分割

• "統合/Jumbo/BLOB/Amalgamated ファイルの分割を有効にする:"
  これを有効にすると、Live++はunityファイルの分割を行います。
• "ソースファイルの数が次の値になったら分割:"
  Live++ が分割を試みる前に、unity ファイルに含まれていなければならない .cpp ファイルの最小数を指定します。例えば、このしきい値を 3 に設定すると、3 つ以上の .cpp ファイルを含む unity ファイルだけが分割されます。
• "分割として考慮される C/C++ ファイル拡張子:"
  unity ファイルを分割するときに C/C++ ファイルとして扱われるファイル拡張子のリスト。

命名規則

一般的に、全ての API シンボルは共通の接頭辞を持ちます。すべてのマクロはLPP_ で始まり、関数はLpp で始まります。C++では、名前の衝突を減らすために、すべての関数はlpp名前空間の一部です。

フレーバー

ディレクトリやパスを必要とするすべてのAPIは、2つのフレーバーがあります：引数としてconst char*取るANSIバージョンと、引数としてconst wchar_t*取るワイド・キャラクタ・バージョンです。

バージョン管理

Live++では、ヘッダーファイルとDLLが同期しないことがないように、簡単なバージョン管理スキームを使用しています。これを実現するために、ヘッダーファイルは、DLLによってエクスポートされることを期待するAPIのバージョンを定義します：

#define LPP_VERSION "2.0.0"

内部的には、DLLはビルドされたAPIのバージョンを返す関数を公開しています：

LPP_API const char* LppGetVersion(void);

さらに、DLL は内部的にバージョンチェックを行い、API と DLL のバージョンが一致するかどうかを返す関数を提供します：

LPP_API bool LppCheckVersion(const char* const expectedVersion);

エージェントを作成する場合、API と DLL のバージョンが常に一致するように、これらのチェックが自動的に実行されます。

エージェントの検証

エージェントの作成が成功したかどうかを確認したい場合、以下のAPIを使用できます：

接続コールバック

コードベースやエンジンとのより深い統合のために、Agent、Bridge、Broker の接続が成功したかどうかをチェックするために、以下のオプション API を使用したい場合があります：

この API はノンブロッキングでスレッドセーフであることに注意してください。Live++は、内部的に接続試行が行われる前または後にAPIが呼び出されたかに関係なく、常に最終接続ステータスでコールバックを1回呼び出します。

フック

フックを使用すると、コンパイルの進行中にプログレス・バーやメッセージ・ボックスなどを表示することで、Live++をエンジン/フレームワーク/アプリケーションに深く統合することができます。また、フックを使用して、コンパイルやリンクに関する情報やエラーを出力したり、構造的な変更をサポートすることもできます。

コンパイル・フック

コンパイル・フックを使用すると、ホット・リロード・コンパイル・プロセスにフックして、コンパイル・プロセスのさまざまな段階について通知を受けることができます。以下のコンパイルフックがサポートされています：

ほとんどのフックは、同様の関数シグネチャを期待するので、最初の引数として期待される異なるlpp::Lpp*HookId値は、追加の型安全性と保護を提供するためだけに役立ちます。

const wchar_t* const recompiledModulePathとconst wchar_t* const recompiledSourcePath引数は、それぞれリコンパイルされたモジュールとソースファイルへの絶対パスを提供します。

リンクフック

リンク・フックを使用すると、ホット・リロード・リンク・プロセスにフックし、リンク・プロセスのさまざまな段階について通知を受けることができます。以下のリンクフックがサポートされています：

ほとんどのフックは、同様の関数シグネチャを期待するので、最初の引数として期待される異なるlpp::Lpp*HookId値は、追加の型安全性と保護を提供するためだけに役立ちます。

const wchar_t* const recompiledModulePath引数は、リコンパイルされたモジュールへの絶対パスを提供します。

ホット・リロード・フック

ホット-リロードフックを使用すると、ホット-リロードプロセスにフックして、パッチ操作のさまざまな段階について通知を受けることができます。以下のホットリロードフックがサポートされています：

両方のフックは同じ関数シグネチャを期待するので、最初の引数として期待される異なるlpp::Lpp*HookId値は、追加の型安全性と保護を提供するためだけに役立ちます。

const wchar_t* const recompiledModulePath引数は、リコンパイルされたモジュールへの絶対パスを提供します。

const wchar_t* const* const modifiedFiles, unsigned int modifiedFilesCount引数は、変更されたファイルの絶対パスの配列を提供する。

グローバル・ホット・リロード・フック

グローバル・ホット・リロード・フックを使用すると、ホット・リロード・プロセスにフックし、ホット・リロード操作の開始と終了について通知を受けることができます。以下のグローバルホットリロードフックがサポートされています：

両方のフックは同じ関数シグネチャを期待するので、最初の引数として期待される異なるlpp::Lpp*HookId値は、追加の型安全性と保護を提供するためだけに役立ちます。

構造的変更

以下の操作は「構造的変更」とみなされます：

• クラス宣言のメモリ・レイアウトの変更：
• 基底クラスの追加や削除
• 非静的データ・メンバの追加と削除
• 非静的データ・メンバの順序を変更する。
• 仮想関数テーブルのレイアウトや内容の変更：
• 多相基底クラスの追加と削除
• 仮想関数の追加と削除
• 仮想関数の順序の変更
• 仮想関数のシグネチャの変更

既存のコードとデータに構造的な変更を加える場合、Live++は、新しいコードが古いメモリ・レイアウトに割り当てられ格納されている既存のデータと正しく連動できるようにする必要があります。そのためには、既存のオブジェクトのデータを古いメモリ・レイアウトから新しいメモリ・レイアウトに移行させる必要がありますが、これはパッチ前およびパッチ後のホット・リロード・フックを使用することで実現できます。

フック・ステートメントはグローバル・スコープのどこにでも置くことができ、自動的に呼び出されます。フック文はグローバルスコープ内のどこにでも書くことができ、自動的に呼び出されます。フックは翻訳単位であればいくつでも追加することができます。

以下は、パッチ間のデータ移行を行う方法を簡略化した例です：

void MyOwnPrePatchHook(lpp::LppHotReloadPrepatchHookId, const wchar_t* const, const wchar_t* const* const, unsigned int, const wchar_t* const* const, unsigned int)
{
  serialization::SerializeAndDeleteObjects(g_allObjects, g_buffer);
}

void MyOwnPostPatchHook(lpp::LppHotReloadPostpatchHookId, const wchar_t* const, const wchar_t* const* const, unsigned int, const wchar_t* const* const, unsigned int)
{
  serialization::CreateAndSerializeObjects(g_allObjects, g_buffer);
}

LPP_HOTRELOAD_PREPATCH_HOOK(MyOwnPrePatchHook);
LPP_HOTRELOAD_POSTPATCH_HOOK(MyOwnPostPatchHook);

基本的な考え方はいつも同じです：

1. 既存のオブジェクトのデータ・メンバーをメモリにシリアライズする。
2. オブジェクトを削除する。
3. 新しいクラス・レイアウトを使用してオブジェクトを再作成する。
4. データ・メンバーをメモリから新しいオブジェクトにシリアライズする。

これが難しいか簡単かは、使用するセットアップやエンジンによって異なります。また、パッチ後のフックで現在のレベルを再起動またはリロードするなど、他の選択肢を検討することもできます。このような特殊なユースケースを可能にするために、フックをどのように使用するかは自由です。

環境設定の適用

必要であれば、以下のAPIを使用して、Live++のグローバル環境設定をプログラムで適用することができます：

LppBoolPreferences,LppIntPreferences,LppStringPreferences,LppShortcutPreferences列挙型の各値は、グローバル環境設定のちょうど1つのオプションに対応します。列挙型はLPP_API_Preferences.h に含まれており、列挙型の値には説明不要な名前が付けられています。

UI へのログ記録

Live++ では、以下の API を使用して Broker UI にメッセージをログ記録できます：

オーバーヘッド

Live++コード・パッチがビルドおよびインストールされていない限り、Live++による実行時オーバーヘッドは、各関数の前に数バイトの未使用バイトを挿入する/FUNCTIONPADMINリンカ・オプションによるものだけです。しかし、これによるパフォーマンスへの影響は、測定可能であるとしても、ごくわずかです。

インクリメンタルリンクでビルドされたモジュールの場合、Live++は自動的にインクリメンタルリンクサンクを使用し、関数アドレスを直接パッチします。この場合、Live++を使用してパッチを当てた関数は、追加のオーバーヘッドをまったく発生させません。

それ以外のすべての場合、関数はホットパッチ技法を使用してパッチされます。ホットパッチ技法では、2バイトの短いジャンプが1回と、新しい関数への相対ジャンプが1回行われます。

Visual Studio におけるブレークポイント

Live++によってホット・ロードされたソース・ファイルに新しいブレークポイントを設定すると、Visual Studioデバッガは、対応するソース・ファイルを含むすべてのパッチにこのブレークポイントを適用しようとします。これは、特に既存のソース ファイルに新しいコード行を追加した後、すぐに混乱する可能性があります：

上の画像でわかるように、Cube.cpp の 20 行目に新しいブレークポイントを設定すると、デバッガは21 行目と 22 行目にも追加のブレークポイントを設定します。古いコードが実際にヒットされることはないため、ブレークポイントは期待通りに機能しますが、インジケータ・マージンの赤い点は誤解を招く可能性があります。

これを軽減するには、Visual Studio のTools -> Options... -> Debugging -> GeneralでRequire source files to exactly match the original versionを有効にすることをお勧めします。

デバッガーでのグローバル変数

ホット・ロードされたソース・ファイルでデバッガーに侵入すると、デバッガーは通常、グローバル変数と静的変数の値を表示できません。これは、パッチコードがダイナミックライブラリから注入されるのに対して、これらの変数がオリジナルの実行ファイルに Live されていることが原因です。

これを回避するために、Visual Studio と Rider の両方は、モジュールのコンテキストをデバッガに伝えることができるContext Operatorをサポートしています。

例を挙げると、MyApplication.exeという名前のアプリケーションのglobalNamespaceという名前空間に含まれるg_globalIntegerという名前のグローバル変数は、{,,MyApplication.exe}globalNamespace::g_globalInteger としてウォッチ・ウィンドウに追加できます。

スタック上の関数

Live++ではコード・パッチがどのように動作するかによって、現在スタック上にある関数は、そのコード変更を観察する前に再入力する必要があります。実際には、これが問題になることはほとんどなく、Live++でインライン関数を正しく処理したり、関数に新しいスタック変数を導入したりすることができます。

スレッドローカル記憶域

スレッドローカル記憶域変数を使用することは問題ありませんが、スレッドローカル記憶域に新しいグローバル変数や静的変数を導入することは現在サポートされていません。

Clang++での動的初期化子

Clang++ でコンパイルする場合、動的イニシャライザを必要とする新しいグローバル変数やスタティック変数を導入することはサポートされていません。Live++ で再コンパイルしたパッチでは、動的イニシャライザは呼び出されません。

Clang++ での FASTBuild

FASTBuild を Clang で使用する場合、FASTBuild はソース・ファイルの前処理中にすべての-Iコマンドライン引数を削除します。

これは、Clang 使用時のFASTBuild のチェックが古いことが原因のようです。回避策としては、.bff スクリプトで.CompilerFamily = 'clang'を指定しないか、廃止されたチェックを行わずにソースから FASTBuild をビルドします。

'/external:I' には '/external:W' が必要です。

Visual Studio の特定のバージョンでは、Microsoft が認めているように、ツールチェーンが外部インクルード環境を PDB ファイルに正しく格納しません。

この場合、/external:Iはコンパイラによって無視されるため、再コンパイル時にインクルードが見つからない可能性が高くなります。回避策としては、プロジェクトの環境設定で/external:W0を追加のコンパイラー・オプションとして指定してください。

PDBでINCLUDEが見つからない

上記のバグと同様に、Visual Studioの特定のバージョンでもINCLUDE環境がPDBファイルに取り込まれず保存されないことがあります。

この場合も、再コンパイル時にインクルードが欠落することになります。回避策としては、プロジェクトの環境設定で、必要なインクルード・パスを追加のコンパイラー・オプションとして指定します。

停止中のプロセスでのホット・リロード

Visual Studio 2022（バージョン 17.11）で導入されたデバッガーは、CONTEXT構造体を内部的にキャッシュするようになり、Microsoftが認めているように、GetThreadContext() Win32 APIが命令ポインターの偽の値を返すようになりました。

残念ながら、Live++は、ホットロードされたプロセスがデバッグされている間、そのプロセスの命令ポインタに関する知識に依存しています。Live++ 2.8.0では回避策が実装されていますが、無関係なWin32 APIを壊すことは、かなり影響が大きいと思われるため、マイクロソフト社にこの動作を修正するよう強く求めます。

欠落しているコンパイランド

Live++を初めてアプリケーションに統合するとき、すべてのコンパイラとリンカ・オプションが正しく設定されていなかったり、いくつかの翻訳ユニットやダイナミック・ライブラリがLive++によってロードされず、有効になっていなかったりする状況に遭遇するかもしれません。デフォルトでは、不完全な翻訳ユニットやモジュールはコンパイル単位ビューに表示されないため、どのコンパイランドがロードに失敗したかを追跡するのは難しいかもしれません。

この問題を解決するには、編集 -> グローバル設定... -> ホットリロード、不完全なモジュールをロードと不完全なコンパイル単位をロード2つのオプションを有効にしてください。これらの設定が有効な場合、Live++は、読み込みに失敗したかどうかにかかわらず、すべての翻訳ユニットとモジュールをコンパイル単位ビューに一覧表示します。

さらに、任意の翻訳ユニットまたはモジュールを右クリックして、詳細を表示...選択すると、この特定の翻訳ユニットまたはモジュールに保存されているすべての情報と、識別されたすべての不具合を表示するダイアログが表示されます：

詳細コンパイル

状況によっては、Live++による変更の再コンパイルに失敗することがあります。これは、プロジェクト環境設定の欠落、異常なビルド設定、またはLive++のバグが原因である可能性があります。デバッグ -> 冗長性のあるコンパイルを切り替えるを有効にすると、このような問題の診断に役立ちます。

冗長コンパイルを有効にすると、Live++は、任意のファイルを再コンパイルする際に、以下の情報を出力します：

• コンパイラ・パス
• コンパイラ作業ディレクトリ
• コンパイラのコマンドライン・オプション
• インクルードされたファイル

冗長リンク

冗長コンパイルと同様に、デバッグ -> 冗長性のあるリンクを切り替えるある冗長リンクは、Live++がパッチのリンクに失敗する可能性のある問題を診断するのに役立ちます。

冗長リンクを有効にすると、Live++はパッチをリンクするときに以下の情報を出力します：

• リンカ・パス
• リンカの作業ディレクトリ
• リンカ・コマンド行オプション

json.h

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to http://unlicense.org/
            

Intel® X86 Encoder Decoder (Intel® XED)

Copyright (c) 2023 Intel Corporation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
            

xxHash Library
Copyright (c) 2012-2020 Yann Collet
All rights reserved.

BSD 2-Clause License (https://www.opensource.org/licenses/bsd-license.php)

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this
  list of conditions and the following disclaimer in the documentation and/or
  other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.