C++におけるnullの基礎知識と歴史
C言語から継承されたNULLの論点
C++言語は、その前身であるC言語からNULLの概念を継承しています。C言語では、NULLは通常、単なるマクロとして定義されており、実際には整数の0を表現していました：
#define NULL 0 // 古典的なC言語でのNULLの定義
これにより、以下のような問題が発生していました：
- 型安全性の欠如
void processPointer(int* ptr) { /* ... */ }
void processInteger(int value) { /* ... */ }
// 以下の呼び出しは両方とも有効となってしまう
processPointer(NULL); // OK
processInteger(NULL); // これも意図せずOKとなる
- オーバーロード解決の曖昧さ
void handleValue(int* ptr) { /* ... */ }
void handleValue(long* ptr) { /* ... */ }
// NULLが0として解釈されるため、どちらのオーバーロードを呼ぶべきか曖昧
handleValue(NULL); // コンパイルエラー
C++11で導入されたnullptrの重要性
C++11では、これらの問題を解決するためにnullptrキーワードが導入されました。nullptrはstd::nullptr_t型の定数で、以下のような特徴を持ちます：
- 型安全性の向上
void processPointer(int* ptr) { /* ... */ }
void processInteger(int value) { /* ... */ }
processPointer(nullptr); // OK
processInteger(nullptr); // コンパイルエラー - 型の不一致
- 明確なオーバーロード解決
void handleValue(int* ptr) { /* ... */ }
void handleValue(long* ptr) { /* ... */ }
handleValue(nullptr); // 両方のオーバーロードに対して有効
- テンプレートでの正しい動作
template<typename T>
void templateFunction(T* ptr) {
// nullptrはポインタ型として正しく推論される
}
templateFunction(nullptr); // T は自動的に推論される
nullptrの導入により、以下のような利点が得られました：
- コードの意図が明確になる: ポインタがnullを示すことが明示的
- 型安全性の向上: ポインタ型以外への暗黙の変換を防止
- テンプレートコードでの正しい動作: 型推論が正確に機能
- 保守性の向上: コードの意図が明確になり、バグの発見が容易に
また、C++17以降では、nullptrを使用することが強く推奨され、従来のNULLマクロの使用は非推奨とされています。これは、モダンC++における型安全性と表現力の向上を重視する方針に沿ったものです。
この歴史的な変遷を理解することは、モダンC++でのnullの適切な扱い方を学ぶ上で重要な基礎となります。次のセクションでは、nullptrを実際にどのように使用すべきかについて、より詳しく見ていきましょう。
nullptrを使用する際の基本的なルール
ポインタの初期化におけるnullptrの使用方法
ポインタを初期化する際は、以下の基本ルールに従うことで、多くの問題を未然に防ぐことができます：
- 明示的な初期化の原則
// 推奨される書き方 int* ptr = nullptr; // 明示的な初期化 // 避けるべき書き方 int* ptr; // 未初期化 - 危険 int* ptr = NULL; // 古い書き方 - 非推奨 int* ptr = 0; // 暗黙的な変換 - 非推奨
- クラスメンバーポインタの初期化
class MyClass {
int* memberPtr; // メンバー変数
public:
// 推奨：初期化子リストでnullptrを使用
MyClass() : memberPtr(nullptr) {}
// 非推奨：コンストラクタ本体での初期化
MyClass() { memberPtr = nullptr; }
};
- スマートポインタとの併用
// 生ポインタの代わりにスマートポインタを使用 std::unique_ptr<int> smartPtr = nullptr; std::shared_ptr<int> sharedPtr = nullptr; // リセット時にもnullptrを使用 smartPtr.reset(nullptr);
条件分岐でのnullptrチェックの書き方
nullptrのチェックは、以下のベストプラクティスに従って実装します：
- 明示的な比較
void processData(int* ptr) {
// 推奨される書き方
if (ptr == nullptr) {
return; // または適切なエラー処理
}
// 非推奨の書き方
if (!ptr) { ... } // 暗黙的な変換
if (ptr == NULL) { ... } // 古い書き方
}
- 早期リターンパターン
bool processValue(int* ptr) {
// nullptrチェックを最初に行う
if (ptr == nullptr) {
return false; // エラー状態を示す
}
// 以降のコードではnullチェック不要
doSomething(*ptr);
return true;
}
- 条件演算子での使用
// 推奨される書き方
int getValue(int* ptr) {
return (ptr == nullptr) ? 0 : *ptr;
}
// より安全な代替案：std::optionalの使用
std::optional<int> getValue(int* ptr) {
return (ptr == nullptr) ? std::nullopt : std::optional<int>(*ptr);
}
実装時の重要なポイント：
- 一貫性の維持
- プロジェクト全体で同じチェックスタイルを使用
- チーム内で統一されたガイドラインを設定
- パフォーマンスへの配慮
// 大きな配列やループでの効率的なチェック
void processArray(int* arr, size_t size) {
if (arr == nullptr) {
return;
}
// 一度のチェックで済む
for (size_t i = 0; i < size; ++i) {
// arr[i]の処理
}
}
- デバッグのしやすさ
// アサーションを活用した開発時のチェック
void criticalOperation(int* ptr) {
assert(ptr != nullptr && "Pointer must not be null");
// 処理の続行
}
これらのルールを適切に適用することで、コードの安全性と保守性が大きく向上します。次のセクションでは、これらの基本ルールを踏まえた上で、より高度なnullの扱い方について見ていきましょう。
モダンC++でnullを安全に扱うベストプラクティス
スマートポインタを活用したnullの回避
モダンC++では、生ポインタの使用を最小限に抑え、代わりにスマートポインタを使用することが推奨されています：
- std::unique_ptrの活用
// 推奨される実装
class ResourceManager {
private:
std::unique_ptr<Resource> resource;
public:
void initializeResource() {
resource = std::make_unique<Resource>();
}
// リソースが存在しない可能性を明示的に示す
Resource* getResource() {
return resource.get(); // nullptrの可能性あり
}
};
- std::shared_ptrによる共有所有権の管理
class SharedResource {
private:
std::shared_ptr<Resource> resource;
public:
void shareResource(const std::shared_ptr<Resource>& other) {
// 参照カウントが自動的に管理される
resource = other;
}
bool hasResource() const {
return resource != nullptr;
}
};
std::optionalによるnullの代替表現
C++17で導入されたstd::optionalは、値が存在しない可能性を型安全に表現する方法を提供します：
- 基本的な使用方法
std::optional<int> findValue(const std::vector<int>& data, int key) {
auto it = std::find(data.begin(), data.end(), key);
if (it != data.end()) {
return *it;
}
return std::nullopt;
}
// 使用例
void processOptionalValue() {
std::vector<int> numbers = {1, 2, 3, 4, 5};
auto result = findValue(numbers, 3);
if (result.has_value()) {
std::cout << "Found: " << *result << "\n";
} else {
std::cout << "Value not found\n";
}
}
- 値の変換と組み合わせ
class User {
public:
std::optional<std::string> nickname;
std::string getDisplayName() const {
return nickname.value_or("Anonymous");
}
};
戻り値でのnullptrを注目するための設計パターン
- Null Objectパターン
// インターフェース
class Logger {
public:
virtual ~Logger() = default;
virtual void log(const std::string& message) = 0;
};
// 実装クラス
class FileLogger : public Logger {
public:
void log(const std::string& message) override {
// ファイルへのログ出力
}
};
// Nullオブジェクト実装
class NullLogger : public Logger {
public:
void log(const std::string& message) override {
// 何もしない
}
};
// 使用例
class Application {
private:
std::shared_ptr<Logger> logger;
public:
Application() : logger(std::make_shared<NullLogger>()) {}
void setLogger(std::shared_ptr<Logger> newLogger) {
logger = newLogger ? newLogger : std::make_shared<NullLogger>();
}
};
- Result型パターン
template<typename T, typename E>
class Result {
private:
std::variant<T, E> data;
public:
explicit Result(const T& value) : data(value) {}
explicit Result(const E& error) : data(error) {}
bool isSuccess() const {
return std::holds_alternative<T>(data);
}
const T& getValue() const {
return std::get<T>(data);
}
const E& getError() const {
return std::get<E>(data);
}
};
// 使用例
Result<int, std::string> divide(int a, int b) {
if (b == 0) {
return Result<int, std::string>("Division by zero");
}
return Result<int, std::string>(a / b);
}
これらのモダンな実装パターンを使用することで、以下のような利点が得られます：
- 型安全性の向上: コンパイル時に多くのエラーを検出可能
- 意図の明確化: APIの契約が型システムで表現される
- メモリリークの防止: リソース管理の自動化
- 保守性の向上: コードの意図が明確になり、バグの混入を防ぐ
次のセクションでは、これらのベストプラクティスを適用する際に注意すべき一般的なバグとその対処法について見ていきましょう。
nullによる一般的なバグとその対処法
メモリ解放後のnullptrチェック漏れ
メモリ解放後のポインタ（ダングリングポインタ）に関連する問題は、最も一般的で危険なバグの一つです。
- 典型的な問題パターン
class ResourceHandler {
Resource* ptr;
public:
void cleanup() {
delete ptr; // メモリを解放
// ptrはまだダングリングポインタ
}
void use() {
if (ptr) { // 危険：deleteされたポインタにアクセス
ptr->doSomething();
}
}
};
- 安全な実装パターン
class ResourceHandler {
Resource* ptr;
public:
void cleanup() {
delete ptr;
ptr = nullptr; // nullptrを設定
}
void use() {
if (ptr != nullptr) {
ptr->doSomething();
}
}
// さらに良い実装：スマートポインタの使用
std::unique_ptr<Resource> safePtr;
};
- RAII原則の適用
class SafeResourceHandler {
std::unique_ptr<Resource> ptr; // RAIIによる自動管理
public:
void use() {
if (ptr) {
ptr->doSomething(); // 安全：無効なポインタにはアクセスできない
}
}
}; // デストラクタで自動的に解放
スレッドマルチ環境でのnullチェックの注意点
マルチスレッド環境では、nullチェックに関連する問題がより複雑になります。
- 典型的な競合状態
// 危険な実装
class SharedResource {
Resource* ptr;
public:
void process() {
if (ptr != nullptr) { // チェック
// この時点で他スレッドがptrを削除する可能性がある
ptr->doSomething(); // 危険な操作
}
}
};
- ミューテックスによる保護
class ThreadSafeResource {
std::mutex mtx;
Resource* ptr;
public:
void process() {
std::lock_guard<std::mutex> lock(mtx);
if (ptr != nullptr) {
ptr->doSomething(); // 安全：ミューテックスで保護
}
}
};
- アトミック操作の活用
class AtomicResource {
std::atomic<Resource*> ptr;
public:
void process() {
Resource* current = ptr.load(std::memory_order_acquire);
if (current != nullptr) {
current->doSomething();
}
}
void update(Resource* newPtr) {
Resource* oldPtr = ptr.exchange(newPtr, std::memory_order_acq_rel);
delete oldPtr; // 古いリソースを安全に解放
}
};
- スレッドセーフなスマートポインタの使用
class ModernThreadSafeResource {
std::shared_ptr<Resource> ptr; // スレッドセーフな参照カウント
mutable std::shared_mutex mtx; // 読み書きロック
public:
void read() const {
std::shared_lock lock(mtx); // 読み取り用ロック
if (auto p = ptr) { // コピーを取得
p->read(); // 安全な読み取り操作
}
}
void write() {
std::unique_lock lock(mtx); // 書き込み用ロック
if (ptr) {
ptr->write();
}
}
};
バグ防止のための重要なポイント：
- デバッグ支援ツールの活用
void debugExample() {
#ifndef NDEBUG
Resource* ptr = nullptr;
assert(ptr == nullptr && "Pointer should be null");
#endif
}
- 静的解析の活用
// 静的解析ツールが検出可能な問題パターン
void problematicCode() {
int* ptr = new int(42);
if (ptr == nullptr) {
delete ptr; // 静的解析: nullptrの削除を検出
}
}
- エラーログの充実化
void loggedOperation(Resource* ptr) {
if (ptr == nullptr) {
logger.error("Null pointer detected in loggedOperation");
return;
}
// 処理の続行
}
これらの対策を適切に実装することで、nullポインタに関連する多くの問題を防ぐことができます。次のセクションでは、既存のコードベースでこれらの対策を段階的に導入する方法について見ていきましょう。
レガシーコードのnull対策とリファクタリング
古いNULLマクロの代替戦略
レガシーコードベースでのNULLマクロの置き換えは、慎重に計画して実施する必要があります。
- 段階的な置き換え戦略
// 既存のコード
#define MY_NULL 0 // レガシーな定義
// 移行期の互換層
#if __cplusplus >= 201103L
#define SAFE_NULL nullptr
#else
#define SAFE_NULL NULL
#endif
// 段階的な置き換えの例
class LegacyClass {
int* oldPtr = MY_NULL; // 古い実装
int* transitionalPtr = SAFE_NULL; // 移行期の実装
int* modernPtr = nullptr; // 最終的な実装
};
- コンパイラ警告の活用
#ifdef __GNUC__
#pragma GCC warning "Deprecated: Use nullptr instead of NULL"
#endif
void legacyFunction(int* ptr = NULL) { // 警告が発生
// ...
}
段階的なnullptr導入のアプローチ
- 既存コードの分析と優先順位付け
// 優先度の高い修正対象
class CriticalSystem {
void* dangerousPtr; // NULL使用箇所を特定
public:
// リファクタリング候補のメソッド
bool initialize() {
if (dangerousPtr == NULL) { // 要修正
dangerousPtr = malloc(sizeof(int));
return dangerousPtr != NULL; // 要修正
}
return false;
}
};
// リファクタリング後
class ModernizedSystem {
std::unique_ptr<void> safePtr;
public:
bool initialize() {
if (!safePtr) {
safePtr = std::make_unique<int>();
return safePtr != nullptr;
}
return false;
}
};
- テストカバレッジの確保
// テスト用のラッパークラス
class TestableWrapper {
OldClass* legacy;
public:
// nullptrを使用する新しいインターフェース
bool isValid() const {
// 古いNULLチェックをラップ
return legacy != nullptr;
}
// テスト用のメソッド
static void runTests() {
TestableWrapper wrapper;
assert(wrapper.isValid() == false);
wrapper.legacy = new OldClass();
assert(wrapper.isValid() == true);
}
};
- 移行支援ツールの作成
// カスタムアサート関数
inline void checkNotNull(const void* ptr, const char* message) {
if (ptr == nullptr) {
throw std::runtime_error(message);
}
}
// 移行期の補助関数
template<typename T>
T* safeCast(void* ptr) {
checkNotNull(ptr, "Null pointer in safeCast");
return static_cast<T*>(ptr);
}
// 使用例
class MigrationHelper {
void* oldStylePtr;
public:
template<typename T>
T* getModernPointer() {
return safeCast<T>(oldStylePtr);
}
};
リファクタリングの主要なステップ：
- コードベースの分析
// 問題のある箇所を特定
class LegacyComponent {
int* ptr1 = 0; // 要修正: 整数リテラル
int* ptr2 = NULL; // 要修正: NULLマクロ
int* ptr3; // 要修正: 未初期化
void riskyMethod() {
if (!ptr1) {} // 要修正: 暗黙的変換
if (ptr2 == 0) {} // 要修正: 整数比較
}
};
- 安全な移行パターンの適用
// 移行用の安全なラッパー
template<typename T>
class SafePointerWrapper {
T* ptr;
public:
SafePointerWrapper() : ptr(nullptr) {}
bool isNull() const {
return ptr == nullptr;
}
T* get() const {
return ptr;
}
void reset(T* newPtr = nullptr) {
delete ptr;
ptr = newPtr;
}
};
// 使用例
class ModernizedComponent {
SafePointerWrapper<int> safePtr;
void safeMethod() {
if (safePtr.isNull()) {
// 安全な処理
}
}
};
- コードレビューとテスト
// リファクタリング前後の動作確認
void verifyRefactoring() {
// 古い実装
LegacyComponent* old = NULL;
assert(old == NULL);
// 新しい実装
ModernizedComponent* modern = nullptr;
assert(modern == nullptr);
// 両者の動作が同じことを確認
bool oldCheck = (old == NULL);
bool modernCheck = (modern == nullptr);
assert(oldCheck == modernCheck);
}
このような段階的なアプローチにより、既存のコードベースを安全に現代的な実装へと移行することができます。次のセクションでは、このような改善を継続的に行うためのガイドラインについて見ていきましょう。
null安全性を高めるためのガイドライン
チーム開発におけるnullptr使用ガイドライン
プロジェクトでのnullptr使用に関する一貫したアプローチを確立するために、以下のようなガイドラインを設定することを推奨します。
- 基本的なコーディング規約
// 必須規則：
// 1. 全てのポインタを nullptr で初期化
class Component {
private:
Resource* resource = nullptr; // 良い
Handler* handler{nullptr}; // これも可
};
// 2. 生ポインタの代わりにスマートポインタを優先
class ModernComponent {
private:
std::unique_ptr<Resource> resource; // 推奨
std::shared_ptr<Handler> handler; // 所有権共有が必要な場合
};
// 3. 関数の引数でのnullptr対応を明示
void processResource(const Resource* resource) {
// nullptr チェックが必要なことを示すコメント
if (resource == nullptr) {
throw std::invalid_argument("Resource cannot be null");
}
// 処理の続行
}
- コードレビューチェックリスト
// レビュー時の確認項目
class ReviewExample {
// ✓ ポインタの初期化
Data* data = nullptr; // OK
// ✓ RAII原則の適用
std::unique_ptr<Cache> cache = std::make_unique<Cache>();
// ✓ null許容性の明示
void process(const Data* nullable_data) { // 命名で示唆
if (nullable_data) {
// 処理
}
}
// ✓ 例外安全性の確保
std::shared_ptr<Resource> createResource() {
return std::make_shared<Resource>(); // 例外安全
}
};
- ドキュメンテーション規約
// 関数のnull許容性を明示的に文書化 /** * @brief リソースを処理する * @param resource 処理対象のリソース（nullptr不可） * @throws std::invalid_argument resourceがnullptrの場合 */ void processResource(Resource* resource); /** * @brief オプショナルな処理を実行 * @param data 処理対象のデータ（nullptrの場合は処理をスキップ） */ void processOptionalData(const Data* data);
静的解析ツールを使用したnullチェック
- 静的解析ツールの設定
// Clang-Tilyの設定例
// .clang-tidy
Checks: 'modernize-*,
performance-*,
bugprone-*,
cppcoreguidelines-*'
// nullポインタ関連の警告を有効化
CheckOptions:
- key: modernize-use-nullptr.NullMacros
value: 'NULL,nullptr'
- 解析ルールの活用例
// 静的解析で検出される問題パターン
class ProblematicCode {
int* ptr; // 警告: 未初期化ポインタ
void method() {
if (ptr == NULL) { // 警告: NULLの使用
ptr = 0; // 警告: 0リテラルの使用
}
if (!ptr) { // 警告: 暗黙的なブール変換
// ...
}
}
};
// 推奨される実装
class ImprovedCode {
int* ptr = nullptr; // OK
void method() {
if (ptr == nullptr) { // OK
ptr = nullptr; // OK
}
if (ptr == nullptr) { // OK: 明示的な比較
// ...
}
}
};
- 継続的インテグレーションでの活用
# .gitlab-ci.yml の例
static_analysis:
script:
- run-clang-tidy -checks='-*,modernize-use-nullptr'
- cppcheck --enable=all --suppress=nullPointerRedundantCheck
# プルリクエストでの自動チェック
pull_request:
script:
- analyze-null-safety
- check-nullptr-usage
- カスタム解析ルールの実装
// カスタムの静的解析チェッカー
class NullSafetyChecker {
public:
// nullptr使用の一貫性をチェック
void checkNullptrUsage(const FunctionDecl* func) {
// 引数のnull許容性をチェック
for (const auto* param : func->parameters()) {
checkParameterNullability(param);
}
// 戻り値のnull許容性をチェック
checkReturnValueNullability(func);
}
// ポインタメンバの初期化をチェック
void checkMemberInitialization(const CXXRecordDecl* record) {
for (const auto* field : record->fields()) {
if (field->getType()->isPointerType()) {
checkFieldInitialization(field);
}
}
}
};
- コードの品質メトリクス
// メトリクス収集用のインターフェース
class NullSafetyMetrics {
public:
// nullptrの使用頻度を追跡
void trackNullptrUsage(const SourceLocation& loc);
// null安全性違反を記録
void recordViolation(const std::string& rule,
const SourceLocation& loc);
// レポート生成
void generateReport() const;
};
これらのガイドラインと工具を適切に活用することで、チーム全体でnull安全性の高いコードを維持することができます。次のセクションでは、これらのガイドラインを実践的なコード例で具体的に見ていきましょう。
実践的なコード例で学ぶnull安全
nullを使わない設計パターンの実装例
- Null Objectパターンの実装
// ユーザー管理システムの例
class IUserRepository {
public:
virtual ~IUserRepository() = default;
virtual User findById(int id) = 0;
virtual void save(const User& user) = 0;
};
// 実際の実装
class UserRepository : public IUserRepository {
std::unordered_map<int, User> users;
public:
User findById(int id) override {
auto it = users.find(id);
return it != users.end() ? it->second : User::createNull();
}
void save(const User& user) override {
users[user.getId()] = user;
}
};
// Nullオブジェクトの実装
class User {
int id;
std::string name;
bool isNull;
public:
User(int id, std::string name)
: id(id), name(std::move(name)), isNull(false) {}
static User createNull() {
static User nullUser(-1, "");
nullUser.isNull = true;
return nullUser;
}
bool isNullObject() const { return isNull; }
int getId() const { return id; }
};
- Monadパターンの実装
// Maybe型の実装
template<typename T>
class Maybe {
std::optional<T> value;
public:
Maybe() : value(std::nullopt) {}
explicit Maybe(const T& v) : value(v) {}
template<typename Func>
auto map(Func f) const -> Maybe<decltype(f(std::declval<T>()))> {
if (value.has_value()) {
return Maybe<decltype(f(*value))>(f(*value));
}
return Maybe<decltype(f(*value))>();
}
T valueOr(const T& defaultValue) const {
return value.value_or(defaultValue);
}
};
// 使用例
class UserService {
Maybe<User> findUser(int id) {
auto user = repository.findById(id);
return user.isNullObject() ? Maybe<User>() : Maybe<User>(user);
}
void processUser(int id) {
findUser(id)
.map([](const User& u) { return u.getName(); })
.map([](const std::string& name) {
std::cout << "Processing user: " << name << "\n";
});
}
};
テスト駆動開発でのnull安全性の確保
- テストファーストアプローチ
class UserServiceTest : public ::testing::Test {
protected:
UserService service;
void SetUp() override {
// テストデータのセットアップ
}
};
// null安全性のテスト
TEST_F(UserServiceTest, HandleNonExistentUser) {
auto result = service.findUser(999); // 存在しないID
EXPECT_FALSE(result.hasValue());
}
TEST_F(UserServiceTest, HandleExistingUser) {
auto result = service.findUser(1); // 存在するID
EXPECT_TRUE(result.hasValue());
auto user = result.valueOr(User::createNull());
EXPECT_FALSE(user.isNullObject());
}
- 境界値テスト
// エッジケースのテスト
class EdgeCaseTest : public ::testing::Test {
protected:
std::unique_ptr<UserRepository> repository;
void SetUp() override {
repository = std::make_unique<UserRepository>();
}
};
TEST_F(EdgeCaseTest, HandleEmptyDatabase) {
auto user = repository->findById(1);
EXPECT_TRUE(user.isNullObject());
}
TEST_F(EdgeCaseTest, HandleDatabaseReset) {
repository->save(User(1, "Test"));
repository.reset(nullptr);
auto newRepo = std::make_unique<UserRepository>();
auto user = newRepo->findById(1);
EXPECT_TRUE(user.isNullObject());
}
- 実践的なユースケース
// ユーザー認証システムの例
class AuthenticationService {
std::unique_ptr<IUserRepository> userRepo;
std::unique_ptr<IPasswordHasher> hasher;
public:
AuthenticationService(
std::unique_ptr<IUserRepository> repo,
std::unique_ptr<IPasswordHasher> pwdHasher)
: userRepo(std::move(repo))
, hasher(std::move(pwdHasher)) {
if (!userRepo || !hasher) {
throw std::invalid_argument("Dependencies cannot be null");
}
}
Maybe<AuthToken> authenticate(const std::string& username,
const std::string& password) {
return findUserByName(username)
.map([&](const User& user) {
return verifyPassword(user, password);
})
.map([](const User& user) {
return generateToken(user);
});
}
private:
Maybe<User> findUserByName(const std::string& username) {
auto user = userRepo->findByUsername(username);
return user.isNullObject() ? Maybe<User>() : Maybe<User>(user);
}
Maybe<User> verifyPassword(const User& user,
const std::string& password) {
return hasher->verify(password, user.getPasswordHash())
? Maybe<User>(user)
: Maybe<User>();
}
static AuthToken generateToken(const User& user) {
// トークン生成ロジック
return AuthToken(user.getId(), std::time(nullptr));
}
};
- パフォーマンステスト
// パフォーマンスとnull安全性の両立
class PerformanceTest : public ::testing::Test {
protected:
static constexpr size_t LARGE_DATASET_SIZE = 1000000;
std::unique_ptr<UserRepository> repository;
void SetUp() override {
repository = std::make_unique<UserRepository>();
populateLargeDataset();
}
void populateLargeDataset() {
for (size_t i = 0; i < LARGE_DATASET_SIZE; ++i) {
repository->save(User(i, "User" + std::to_string(i)));
}
}
};
TEST_F(PerformanceTest, HandleLargeDataset) {
auto start = std::chrono::high_resolution_clock::now();
for (size_t i = 0; i < 1000; ++i) {
auto user = repository->findById(rand() % LARGE_DATASET_SIZE);
EXPECT_FALSE(user.isNullObject());
}
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>
(end - start);
EXPECT_LT(duration.count(), 1000); // 1秒以内に完了すべき
}
これらの実践的な例を通じて、null安全性を確保しながら、保守性が高く、パフォーマンスの良いコードを書く方法を学ぶことができます。テスト駆動開発のアプローチを採用することで、null安全性の確保と品質の向上を同時に達成することが可能です。