13

数日前、C++ ファイルを Java プロジェクトに導入しなければならなかったときに、問題に遭遇しました。Java プロセスの CPU 使用率を測定する必要性から始まり、JNI を使用して C で記述されたネイティブ ライブラリ (Unix マシン上の共有ライブラリ) を呼び出すことが決定されました。問題はJava ファイルのみで構成されるソース リポジトリ (ついでに Clearcase) に C ファイルを配置する適切な場所を見つけます。

私はいくつかの選択肢を考えました：

(a) 次のように、C ファイル (具体的には、1 つの .h ファイルと 1 つの .c ファイル) をソース ベースの先頭に配置するための別のディレクトリを作成します。

/vobs/myproduct/javasrc /vobs/myproduct/cppsrc

Cファイルが2つしかなく、このようにソースベースを言語レベルで分割するのは非常に奇妙に思えたので、私はこれが好きではありませんでした. プロジェクトの大部分がほぼ同等に C++ と Java で書かれていれば、これで問題ありません。

(b) C ファイルを、それを使用する Java パッケージに入れます。

/vobs/myproduct/com/mycompany/myproduct/util/ に呼び出し元の Java クラスがあり、C ファイルもそこに入ります。

CファイルはJavaパッケージに属していないと思うので、これも好きではありませんでした。

このような問題を以前に解決した人はいますか？一般的に、2 つ以上の言語が混在するコードベースを編成する際に従うべき適切な戦略は何ですか?

更新: プロジェクトで C または C++ を使用する計画はありません。おそらく Jython を使用する予定ですが、C を使用することによってのみ解決できる機能や、C を使用することで解決するのが最適な機能がいつ顧客に必要になるかはわかりません。

4

7 に答える 7

8

「Cファイルが2つしかないため、これが気に入らなかった。このように言語レベルでソースベースを分割するのは非常に奇妙に思えた」

なぜそれは奇妙に見えるのですか？このプロジェクトを検討してください。

  project1 \ src \ java
  project1 \ src \ cpp
  project1 \ src \ python

または、物事をモジュールに分割することにした場合：

  project1 \ module1 \ src \ java
  project1 \ module1 \ src \ cpp
  project1 \ module2 \ src \ java
  project1 \ module2 \ src \ python

個人的な好みの問題だと思いますが、上記の構造はかなり一般的で、慣れればかなりうまくいくと思います。

于 2008-09-24T13:00:52.517 に答える
4

Maven が生成する Web アプリのデフォルトのレイアウトは、、、、src/main/javaおよびです。私は、デフォルトで追加することも想定しています。これは私にとって十分にまともな慣習のようです。src/test/javasrc/main/resourcessrc/test/resourcessrc/main/cppsrc/test/cpp

于 2008-09-24T13:09:36.410 に答える
1

それらを別々のフォルダーに保管することをお勧めします。これにより、Java パッケージで C ファイルを検索するよりも簡単に見つけることができます。また、後で C ファイルを移動することなく、将来さらに C コードを追加することもできます。

于 2008-09-24T13:14:37.053 に答える
0

個人的には、分割言語ソリューションの場合、それらを別々のプロジェクトまたはフォルダーに保管します。

この問題を調べる 1 つの方法は、C クラスを他のサードパーティ API と同じように扱うことです。密結合を回避し、Java とは別のプロジェクト/フォルダーに C ソースを保持するために、Java コード内の依存関係をインターフェイスで切り離します (つまり、直接呼び出しを回避します)。

于 2008-09-24T13:08:35.947 に答える
0

異なる用語を使用しましょう。プロジェクトではない製品が 1 つあります。製品は Java ワークスペースと C/C++ ワークスペースで構成され、それぞれが異なる IDE からロード可能です。最終的に、同じ IDE を 1 つ使用すると、ワークスペースは 1 つだけになります。各ワークスペースは、複数のプロジェクトで構成されています。各プロジェクトには独自のフォルダー構造 (src、bin、res など) があります。そのため、ワークスペースが 1 つだけの場合は、少なくとも 1 つの Java プロジェクトと 1 つの C/C++ プロジェクトをそれぞれ異なるコンパイル/実行/デバッグ/出力/... 設定で内部に配置することをお勧めします。

だから、私は使用します：

Product/Workspace(1)/JavaProject1/src 
Product/Workspace(1)/JavaProject2/src 
Product/Workspace(1 or 2)/CPPproject1/src 
Product/Workspace(1 or 2)/CPPproject2/src ...

こうすることで、最終的に各プロジェクトに 1 つの同じフォルダー構造を使用できるようになり、より一貫性が保たれます。基本的に、これは抽象化のもう 1 つのレベルにすぎません。つまり、製品をさまざまな関連プロジェクトに分割します。

于 2008-09-24T13:09:01.700 に答える
0

個人的には、2 つを別々のプロジェクトに分けたいと思いますが、それは、2 つの異なる概念を同じクラスに入れないように、両方とも別々のものである場合です。両方が同じ概念領域に触れると、かなり曖昧になります。もちろん、コードのビルドに関しては常に問題があります。たとえば、コンパイルするためにあらゆる種類のトリックを実行する必要なく、構造 b) に配置することは可能ですか? プロジェクトでより多くの C を使用する予定はありますか? その場合、同じパターンに従うと、C ファイルがプロジェクト全体に広がってしまいます...

于 2008-09-24T12:49:28.770 に答える
0

この場合、問題のファイルは言語が異なるだけでなく、定義されたインターフェイスを介して対話する別のプログラムとして実行されます。これは、ソース ファイルを別のプロジェクトとして扱うことができるため、別の場所に保持できることを意味します。

1 つのコードベース内に C# と ASP.NET (たとえば) が混在する .NET プロジェクトの場合は異なります。そのような場合、人々はどのようにコードを編成しますか?

于 2008-09-24T13:30:44.473 に答える