7

C プログラミング言語で複数のミドルウェア (オペレーティング システム、プロトコル スタック) ベンダーからのプラットフォームの独立性のために使用される冗長な typedef を管理する最良の方法は何ですか。

例:
target.h

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

OS_types.h

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

ある時点で、コンパイラは 2 つの冗長な typedef シンボルがあることを認識し、エラーで救済します。これは、C の定義では許可されていないためです。

4

5 に答える 5

6

ベンダーのヘッダーを変更せずにこれを行う方法の 1 つは、プリプロセッサをいくつかのヘッダー ラッパーと共に使用することです。

mytypes.h

#define BYTE VENDOR1_BYTE
#include <vendor1/types.h>
#undef BYTE

#define BYTE VENDOR2_BYTE
#include <vendor2/types.h>
#undef BYTE

typedef unsigned char BYTE;

これにより、ベンダーのコードが異なる typedef を生成することになりますが、うまくいけば同じ実際の型 (例では unsigned char) にマップされます。ベンダーが同じ型名に対して異なる基になる型を使用している場合、メソッドは機能しない可能性があります。

于 2009-12-10T20:43:01.057 に答える
2

それはタフです。何かをしなければならない場合は、おそらく鼻をつまんでサードパーティのヘッダーファイルを変更します。おそらくマクロを使用して、問題のあるtypedefの条件付きコンパイルを取得します。

幸運を。

于 2009-12-10T19:41:45.457 に答える
0

大変な作業になるかもしれませんが、1 つのアプローチは、各ミドルウェア ベンダーから必要な機能のみを提供する独自の「ラッパー」レイヤーを構築することです。各ラッパーを独自のコンパイル ユニット (.c ファイル) に保持する場合、ベンダーのヘッダー ファイルを参照する必要があるのはその場所だけです。これにより、独自の typedef を使用してラッパー内のベンダー固有の型に変換できるため、競合する型がアプリケーションに「漏れる」のを防ぐ方法が得られます。

Steve が示唆したように、ベンダーが新バージョンを出荷する頻度にもよりますが、ヘッダー ファイルを変更することが最善の解決策かもしれません。オーバーヘッドがかなり高くなる可能性があります。

于 2009-12-10T19:46:18.997 に答える
0

独自のコードに C++ コンパイルを使用するオプションがある場合 (それが本質的に C コードであっても)、次のように名前空間ラッパーを作成できます。

vendorA_target.h

namespace vendorA
{
    extern "C"
    {
        #include <target.h>
    }
}

vendorB_OS_types.h

namespace vendorB
{
    extern "C"
    {
        #include <target.h>
    }
}

次に、独自のコードで。元のヘッダーの代わりにこれらのヘッダーを含め、スコープ解決を使用するか、同じ名前の型が同一または互換性のある定義を持っていることが確実な場合は、単に using ディレクティブを使用します。

using vendorB::WORD
WORD timeout = 100 ;

vendorA::WORD x = 0xffff ;

extern "C"ヘッダーがマクロ条件で既に内部的にラッパーを持っている場合、ラッパーは必要ないことに注意してください__cplusplus- しかし、害はありません。

C++ を使用して C コードをコンパイルしてもオーバーヘッドは発生しませんが、より厳密な型の適合性チェックが行われます。これは、コードの品質には適していますが、別の問題を引き起こす可能性があります。特に、サードパーティのヘッダーに C++ として無効なコードが含まれている場合。ヘッダーに既にマクロ条件でextern "C"宣言がある場合__cplusplus、それらは既に「C++ 対応」であることを意図しており、そのような問題は発生しない可能性があります。

残念ながら、この方法では、同じ名前のプリプロセッサ マクロの問題は解決されません。その問題がある場合は、一方のヘッダーのマクロを #undef してから他方を含めるか、ヘッダーを変更する必要があります。

于 2009-12-10T21:36:37.333 に答える