問題タブ [file-organization]

何らかの理由で、当社には次のようなコーディングガイドラインがあります。

Each class shall have it's own header and implementation file.

したがって、というクラスMyStringを作成した場合、関連付けられたMyStringh.hとMyString.cxxが必要になります。

他の誰かがこれをしますか？結果として、コンパイルパフォーマンスへの影響を見た人はいますか？10000ファイルの5000クラスは、2500ファイルの5000クラスと同じくらい速くコンパイルされますか？そうでない場合、違いは顕著ですか？

[私たちはC++をコーディングし、日常のコンパイラとしてGCC3.4.4を使用しています]

私はすべてのコーディングを 1 つの C ファイルで行うことに慣れています。しかし、私は大規模なプロジェクトに取り組んでいるため、そうすることが現実的ではありません。私はそれらを一緒に #include してきましたが、一部のファイルを複数回 #include するなどのケースに遭遇しました。.h ファイルについて聞いたことがありますが、それらの機能が何であるか (または理由2 つのファイルを持つ方が 1 つよりも優れています)。

コードを整理するためにどのような戦略を使用する必要がありますか? 特定のファイルについて、「パブリック」関数を「プライベート」関数から分離することは可能ですか?

この質問は私の問い合わせを引き起こしました。tea.h ファイルは tea.c ファイルを参照しません。コンパイラは、すべての .h ファイルに対応する .c ファイルがあることを「認識」していますか?

現在、InnoDB テーブルに BLOB として保存されている画像 (最大 6MB) があります。データのサイズが大きくなるにつれて、毎晩のバックアップはますます遅くなり、通常のパフォーマンスが妨げられます。

そのため、バイナリ データはファイル システムに移動する必要があります。(ファイルへのポインタは DB に保持されます。)

データにはツリーのような関係があります。

ここで、データをディレクトリ構造全体に均等に分散させたいと考えています。どうすればこれを達成できますか?

MD5('userId, albumId, imageId');結果の文字列をスライスして、ディレクトリ パスを取得できると思います。

これにより、最初の文字をサーバーにマップし、ディレクトリ構造を複数のサーバーに均等に分散できます。

ただし、これでは画像がユーザーごとに整理された状態に保たれず、1 つのアルバムの画像が複数のサーバーに分散される可能性があります。

私の質問は次のとおりです:
ユーザー/アルバム データを一緒に保ちながら、バランスの取れた方法で画像データをファイル システムに格納する最良の方法は何ですか?

私は正しい方向に考えていますか？それとも、これは物事を完全に行う間違った方法ですか?

更新:最高レベルで分割するため
の文字列スライスを行います。md5(user_id)そして、すべてのユーザー データを同じバケットに入れます。これにより、ユーザー データを近くに保存しながら、データを均等に分散できます。

ディレクトリごとのアルバムの数を少なくするために、後ろから分割された albumId を使用すると思います (ただし、ほとんどのユーザーには必要ありません)。

ありがとう！

私は SyncToy 1.4 を使用していますが、次のことを除いて、必要なものには問題ありません。

• システム間で割り当てられたドライブ文字の変更を処理できません (例: USB ドライブの同期)。
• 同期されているフォルダーに独自の (隠し) ファイルを残します (これは OS/FS の制限ですか?)、
• 削除されたフォルダーの空のフォルダーを再作成し、
• 同期から選択されていないフォルダー内の新しいサブフォルダーを同期します
• また、すべてのファイルがまだ変更されているのに、変更が加えられていることが判明することもあります。
• 非常に長いファイル パス/名前を処理できません

SyncToy 2.1 は遅すぎて使用できません。特に、変更を加えていないフォルダーで再度実行すると、すべてのファイルとサブフォルダーの違いを最初からスキャンします。

インターネット ベースのストレージを使用しないソリューションである必要があります。これは常に利用できるとは限らず、そうでなければ遅すぎる可能性があるためです。同期するフォルダーに独自のファイルを追加しないものと、ファイルとフォルダーの同期選択をすばやく簡単に変更できるものが望ましいです。対話性が低いほど良いので、マウスを数回クリックするだけで (SyncToy のように) 複数のフォルダー ペアを安全に同期できます。

rsync とバッチ ファイルを使用する必要がありますか? おばあさんでも無理なく使えるGUIがあればいいのに。これが私の基準です：

1. インターネット接続は必要ありません。

2. ソースまたはターゲットに独自のハウスキーピング ファイル/フォルダーを作成してはなりません (おそらく、NTFS の欠点のためにこれを行う必要がありますか?)

3. テスト: 空でない 2 つのサブフォルダー A と B を持つソース フォルダー。サブフォルダー B をサブフォルダー A に移動します。これはターゲット フォルダーに複製されますか?

4. テスト: サブフォルダー A のファイルの名前を変更します。これはターゲット フォルダーに複製されますか?

5. マウスを 1 回または 2 回クリックするだけで、複数のフォルダー ペアの同期を同時に実行できますか?

6. これから行う変更をプレビューするオプションはありますか?

7. ソースパスやターゲットパスを簡単に変更できますか?

8. 高速である必要があります (特に、何も変更せずに 2 つのフォルダー ツリーを再スキャンする場合)。

9. テスト: PC 1 で USB ドライブを同期し、ファイルとフォルダーを USB ドライブから PC 2 にコピーし、PC 2 でフォルダーとファイルを変更し (PC 1 のフォルダーとファイルは同じまま)、PC 2 で USB ドライブを同期してから、 USBドライブからPC 1のファイルとフォルダー。エラーなしでこれを行うことができますか？

10. インストールを除けば、おばあさんも快適に使える？-->

私はコードを整理するのが大好きなので、理想的にはファイルごとに1つのクラスが必要です。メンバー以外の関数がある場合は、ファイルごとに1つの関数が必要です。

理由は次のとおりです。

1. コードを読むと、特定の関数またはクラスを見つける必要があるファイルが常にわかります。

2. ヘッダーファイルごとに1つのクラスまたは1つの非メンバー関数である場合 include、ヘッダーファイルのときに混乱全体をインクルードすることはありません。

3. 関数に小さな変更を加えると、その関数だけを再コンパイルする必要があります。

ただし、すべてを多くのヘッダーと多くの実装ファイルに分割すると、コンパイルが大幅に遅くなる可能性があります。私のプロジェクトでは、ほとんどの関数が特定の数のテンプレート化された他のライブラリ関数にアクセスします。そのため、コードは実装ファイルごとに1回ずつ、何度もコンパイルされます。プロジェクト全体のコンパイルには、現在1台のマシンで45分ほどかかります。約50個のオブジェクトファイルがあり、それぞれが同じコンパイルコストの高いヘッダーを使用します。

たぶん、ヘッダーファイルごとに1つのクラス（または非メンバー関数）を持つことは許容されますが、次の例のように、これらの関数の多くまたはすべての実装を1つの実装ファイルに入れますか？

繰り返しになりますが、foo関数のみまたはbar関数のみを含めることができ、1つのファイルであるため、foobar.cppプロジェクト全体のコンパイルが高速になるという利点があります。テンプレート化された構造をコンパイルする）をコンパイルする必要があるのは1回だけですが、とを別々にコンパイルした場合は2回コンパイルする必要があります。もちろん、上記の私の理由（3）は、このシナリオには当てはまりません。foo（）{...}を変更した後、大きな可能性のあるファイル全体を再コンパイルする必要があります。std::vector<int>foo.cppbar.cppfoobar.cpp

私はあなたの意見が何であるか興味があります！

プロジェクトを、トランク、ブランチ、タグのサブディレクトリを含む SVN ディレクトリとして定義します。

プロジェクトを 2 つに分割したり、複数のプロジェクトを 1 つに統合したりする時期を決定する際に、どのような基準を使用しますか? - 共通のソースとリソースの共有プロジェクトを使用して、「プロジェクト」ごとに 1 つのアプリを使用しますか? - アプリのすべてのソースとリソースを含む 1 つの大きな「プロジェクト」?

単一プロジェクトまたは複数プロジェクトの両方にプラスとマイナスがあります。私たちは単一のプロジェクトに向かって進んでおり、これが正しいアプローチかどうかを判断しようとしています.

プロジェクトを分割すると、スイートのさまざまな部分に変更を組み込む方法をより細かく制御できます。共通ライブラリはバージョンにすることができ、さまざまなアプリケーションが特定のバージョンを使用することを選択できます (maven dep 管理アプローチ)。

また、プロジェクトを分割すると、複数のクラス階層が作成されるため、コード全体が理解しにくくなり、コードの重複が発生する可能性があります。全体の構造とコンポーネント間の関係を適切に設計することが、このコストを管理するための鍵になると思います。

統一されたプロジェクト アプローチにより、開発者はワークスペースを設定しやすくなり、単一のクラス階層が提供されます。これは諸刃の剣であり、開発者にさらに多くの情報を投げかけます (クラスが多すぎて理解できません)。

では、結合する場所と分割する場所を決定しようとするとき、どの経験則を使用しますか?

#includeヘッダー (*.h) 内で、このファイルで定義された型が使用されている場合、一部のファイルに必要ですか?

たとえば、GLib を使用していて、ヘッダーで定義された構造体で基本型を使用したい場合、既に *.c ファイルに含まれていることを知っていれば、gcharを実行する必要がありますか?#include <glib.h>

はいの場合、との間に配置する必要が#ifndefあり#defineます#defineか？

まず最初に、Subversion のマニュアルを読んだと言いたいです。この質問を読みました。この質問も読みました。これが私のジレンマです。

次のようにレイアウトされた 3 つのリポジトリがあるとします。

• DataAccessObject/
  • 支店/
  • タグ/
  • トランク/
    • DataAccessObject/
    • DataAccessObjectTests/
• PlanObject/
  • 支店/
  • タグ/
  • トランク/
    • PlanObject/
    • PlanObjectTests/
• WinFormsPlanViewer/
  • 支店/
  • タグ/
  • トランク/
    • WinFormsPlanViewer/

PlanObject および DataAccessObject リポジトリには、共有プロジェクトが含まれています。それらは WinFormsPlanViewer によって使用されますが、他のいくつかのリポジトリのいくつかの他のプロジェクトによっても使用されます。

ここで我慢してください。次のように、WinFormsPlanViewer/trunk フォルダーに svn:externals 定義を置きます。

そして、svn update を実行した後に表示されるのは次のとおりです。

• WinFormsPlanViewer/
  • 支店/
  • タグ/
  • トランク/
    • WinFormsPlanViewer/
    • オブジェクト/
      • DataAccessObject/
      • DataAccessObjectTests/

PlanObject のものは、アップデートでもダウンしません! これが関係しているかどうかはわかりませんが、PlanObject/trunk フォルダーにも外部定義があります。

何が起きてる？私は何を間違っていますか？PlanObject が svn:externals を使用して DataAccessObject を参照する場合、svn:externals を使用して WinFormsPlanViewer から PlanObject と DataAccessObject を参照すると、悪い結果が生じますか?

当社には Oracle 10g データベース (巨大なもの) があり、従業員の要求に応じてデータを提供しています。私の問題は、書いたほとんどすべての SQL クエリを保存していて、リストが長くなりすぎていることです。必要なファイルを簡単に見つけられるように、これらの .sql ファイルを整理して名前を変更したいと考えています。現時点では、Sales Dept, Field Team, Planning Dept, Specialなどの名前のフォルダーを使用しています。これらのフォルダーの下には、次のような .sql ファイルがあります。

内容に応じてファイルに名前を付けようとしましたが、ファイル名が長くなり、私のニーズを完全には満たしていません。時々誰かが来て、特別なレポートを要求し、ファイルに彼の名前を付けますが、これもあまり良くありません. 重複ファイルまたは非常に類似したファイルが時間の経過とともに増加していることは知っていますが、それらを制御することはできません。

これらすべてのファイルとフォルダーの名前を変更し、クエリを整理して簡単かつ適切に制御するための正しい方向を教えてもらえますか? ティア。

例外を拡張するいくつかの例外クラスがあるとしましょう。私の質問は、ファイルを適切に整理するために、これらのクラスをどこに配置する必要があるかということです。

すなわち - それらはヘルパー クラスですか。

1つはファイルにありますか？Ok。命名規則の尊重。Ok。

しかし、それらのファイルをグループ化し、どのフォルダーに配置すればよいでしょうか? Helper Classes というフォルダでしょうか。

好きなように名前を付けることができます。これらのクラスを配置できる場所について合理的な理由があるかどうかを理解しようとしているだけです。

前もってありがとう、MEM