web-dev-qa-db-ja.com

不透明なC構造体:それらはどのように宣言されるべきですか?

C APIで不透明(OPAQUE)型を宣言する次の2つのスタイルの両方を見てきました。あるスタイルを他のスタイルよりも使用することには明らかな利点がありますか?

オプション1

// foo.h
typedef struct foo * fooRef;
void doStuff(fooRef f);

// foo.c
struct foo {
    int x;
    int y;
};

オプション2

// foo.h
typedef struct _foo foo;
void doStuff(foo *f);

// foo.c
struct _foo {
    int x;
    int y;
};
47
splicer

私の投票はmouvicielが投稿してから削除した3番目のオプションです。

私は第三の方法を見てきました:

// foo.h
struct foo;
void doStuff(struct foo *f);

// foo.c
struct foo {
    int x;
    int y;
};

structキーワードを入力することに本当に耐えられない場合は、typedef struct foo foo;(注:役に立たない問題のあるアンダースコアを取り除く)は許容されます。しかし、何をしてもneverはポインタ型の名前を定義するためにtypedefを使用します。これは、このタイプの変数が関数に渡すたびに変更される可能性があるオブジェクトを参照するという非常に重要な情報を隠し、異なる修飾(たとえば、const修飾)バージョンの処理を行いますポインターは大きな痛みです。

69
R..

bar(const fooRef)は、不変アドレスを引数として宣言します。 bar(const foo *)は、不変のfooのアドレスを引数として宣言します。

このため、私はオプション2を好む傾向があります。つまり、提示されたインターフェースタイプは、間接参照の各レベルでcv-nessを指定できるタイプです。もちろん、1つcanオプション1のライブラリライターを回避し、fooを使用するだけで、ライブラリライターが実装を変更したときにあらゆる種類の恐怖を味わうことができます。 (つまり、オプション1のライブラリライターは、fooRefがインバリアントインターフェースの一部であり、fooは変更、変更、変更が可能であることのみを認識します。オプション2のライブラリライターは、fooがインバリアントインターフェースの一部であると認識します。)

Typedef/struct構造の組み合わせを提案する人がいないことに私はもっと驚いています。
typedef struct { ... } foo;

1
Eric Towers

オプション1.5

私はOption 1を使用することに慣れていますが、参照に_hを付けて、C-への「ハンドル」であることを示しています。この指定されたC「クラス」のスタイル「オブジェクト」。次に、このオブジェクトの「ハンドル」のコンテンツが入力のみであり、変更できない場合は、関数プロトタイプがconstを使用し、コンテンツはどこでもconstを使用しないようにしますcan変更されます。

ここに完全な例があります:

//======================================================================================================================
// my_module.h
//======================================================================================================================

// An opaque pointer (handle) to a C-style "object" of "class" type "my_module" (struct my_module_s *, or my_module_h):
typedef struct my_module_s *my_module_h;

// Create a new "object" of "class" "my_module":
// A function that takes a *pointer to* an "object" handle, `malloc`s memory for a new copy of the opaque 
// `struct my_module_s`, then points the user's input handle (via its passed-in pointer) to this newly-created 
// "object" of "class" "my_module".
void my_module_open(my_module_h * my_module_h_p);

// A function that takes this "object" (via its handle) as an input only and cannot modify it
void my_module_do_stuff1(const my_module_h my_module);

// A function that can modify the private content of this "object" (via its handle) (but still cannot modify the 
// handle itself)
void my_module_do_stuff2(my_module_h my_module);

// Destroy the passed-in "object" of "class" type "my_module":
// A function that can close this object by stopping all operations, as required, and `free`ing its memory.
// `struct my_module_s`, then points the user's input handle (via its passed-in pointer) to this newly-created "object".
void my_module_close(my_module_h my_module);

//======================================================================================================================
// my_module.c
//======================================================================================================================

// Definition of the opaque struct "object" of C-style "class" "my_module".
// - NB: Since this is an opaque struct (declared in the header but not defined until the source file), it has the 
// following 2 important properties:
// 1) It permits data hiding, wherein you end up with the equivalent of a C++ "class" with only *private* member 
// variables.
// 2) Objects of this "class" can only be dynamically allocated. No static allocation is possible since any module
// including the header file does not know the contents of *nor the size of* (this is the critical part) this "class"
// (ie: C struct).
struct my_module_s
{
    int my_private_int1;
    int my_private_int2;
    float my_private_float;
    // etc. etc--add more "private" member variables as you see fit
}

void my_module_open(my_module_h * my_module_h_p)
{
    // Ensure the passed-in pointer is not NULL (since it is a core dump/segmentation fault to try to dereference 
    // a NULL pointer)
    if (!my_module_h_p)
    {
        // Print some error or store some error code here, and return it at the end of the function instead of 
        // returning void.
        goto done;
    }

    // Now allocate the actual memory for a new my_module C object from the heap, thereby dynamically creating this
    // C-style "object".
    my_module_h my_module; // Create a local object handle (pointer to a struct)
    my_module = malloc(sizeof(*my_module)); // Dynamically allocate memory for the full contents of the struct "object"
    if (!my_module) 
    {
        // Malloc failed due to out-of-memory. Print some error or store some error code here, and return it
        // at the end of the function instead of returning void.
        goto done;
    }

    // Initialize all memory to zero (OR just use `calloc()` instead of `malloc()` above!)
    memset(my_module, 0, sizeof(*my_module));

    // Now pass out this object to the user, and exit.
    *my_module_h_p = my_module;

done:
}

void my_module_do_stuff1(const my_module_h my_module)
{
    // Ensure my_module is not a NULL pointer.
    if (!my_module)
    {
        goto done;
    }

    // Do stuff where you use my_module private "member" variables.
    // Ex: use `my_module->my_private_int1` here, or `my_module->my_private_float`, etc. 

done:
}

void my_module_do_stuff2(my_module_h my_module)
{
    // Ensure my_module is not a NULL pointer.
    if (!my_module)
    {
        goto done;
    }

    // Do stuff where you use AND UPDATE my_module private "member" variables.
    // Ex:
    my_module->my_private_int1 = 7;
    my_module->my_private_float = 3.14159;
    // Etc.

done:
}

void my_module_close(my_module_h my_module)
{
    // Ensure my_module is not a NULL pointer.
    if (!my_module)
    {
        goto done;
    }

    free(my_module);

done:
}

これ以外の改善点は次のとおりです。

  1. 完全なエラー処理を実装し、voidの代わりにエラーを返します。
  2. my_module_config_tという構成構造体を.hファイルに追加し、それをopen関数に渡して、新しいオブジェクトを作成するときに内部変数を更新します。例:

    //--------------------
    // my_module.h
    //--------------------
    
    // my_module configuration struct
    typedef struct my_module_config_s
    {
        int my_config_param_int;
        int my_config_param_float;
    } my_module_config_t;
    
    void my_module_open(my_module_h * my_module_h_p, const my_module_config_t *config);
    
    //--------------------
    // my_module.c
    //--------------------
    
    void my_module_open(my_module_h * my_module_h_p, const my_module_config_t *config)
    {
        // Ensure the passed-in pointer is not NULL (since it is a core dump/segmentation fault to try to dereference 
        // a NULL pointer)
        if (!my_module_h_p)
        {
            // Print some error or store some error code here, and return it at the end of the function instead of 
            // returning void.
            goto done;
        }
    
        // Now allocate the actual memory for a new my_module C object from the heap, thereby dynamically creating this
        // C-style "object".
        my_module_h my_module; // Create a local object handle (pointer to a struct)
        my_module = malloc(sizeof(*my_module)); // Dynamically allocate memory for the full contents of the struct "object"
        if (!my_module) 
        {
            // Malloc failed due to out-of-memory. Print some error or store some error code here, and return it
            // at the end of the function instead of returning void.
            goto done;
        }
    
        // Initialize all memory to zero (OR just use `calloc()` instead of `malloc()` above!)
        memset(my_module, 0, sizeof(*my_module));
    
        // Now initialize the object with values per the config struct passed in.
        my_module->my_private_int1 = config->my_config_param_int;
        my_module->my_private_int2 = config->my_config_param_int*3/2;
        my_module->my_private_float = config->my_config_param_float;        
        // etc etc
    
        // Now pass out this object to the user, and exit.
        *my_module_h_p = my_module;
    
    done:
    }
    

オブジェクトベースのCアーキテクチャに関する補足資料:

0
Gabriel Staples