構造体の転送の2 – 固定ページ 3 – プログラミング – Home

通知
すべてクリア

[解決済] 構造体の転送の2

固定ページ 3 / 3

PATIO
(@patio)
Famed Member
結合: 3年前
投稿: 2659
 

maruさんも書かれていますが、通常はそうならないようにモジュール設計をします。
その構造体を扱う為の処理はそのDllに集中させるのが普通です。
Dll_Aの機能をDll_Bで使いたい場合は、Dll_Aの関連ヘッダーファイルを
Dll_Bでインクルードし、Dll_Aをリンクするのが普通でしょう。
ヘッダーファイルだけリンクするような話ならDll分けの段階で
綺麗に分けられていないと言う話になると思います。


返信引用
gg
 gg
(@gg)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

ITOさん、maru さん、PATIOさん
ご返事ありがとう。

>でも、普通はそんな別のDLLに依存するようなDLLの設計にはしないと思う。
>そんな構造にしなければならないののならば、設計から見直した方がよい。

>maruさんも書かれていますが、通常はそうならないようにモジュール設計をします。
>その構造体を扱う為の処理はそのDllに集中させるのが普通です。

自分はそう考えています。
DataのI/O部分と表示は一つのDLLに入れます。
Dataの編集などは別のDLLにすること。
編集などは頻繁に行います、その編集のコマンドを一つのDLLに集中して
行います(管理しやすいため)、編集できたDataは表示用のDLLを移します。
(実は、Dataの量が多いですが、図枠で分けています、
一つの図枠のデータ処理はほぼ同じです。)

もうし、以上のことを一つのDLLを処理すると、このDLLでかくなります。

どうしたら、迷っています。

アドバイスよろしくお願いします。


返信引用
たいちう
 たいちう
(@たいちう)
ゲスト
結合: 22年前
投稿: 662
 

直接の回答ではないですが、私のアドバイスを。
辛口ですが責めるつもりも馬鹿にするつもりもないので、
癇癪を起こさないことを願う。

あなたの文章は非常に出来が悪いです。
あなたにとって日本語が外国語ならば話は別ですが、
日本語を母国語とする中卒以上の人だとすると、
恥ずかしいレベルです。手を抜いているだけで
時間をかけて推敲すれば、もっと良くなるならば推敲してほしいし、
せめて投稿前に読み直してほしい。

あなたが本当に文章を書くのが苦手だとしても、
大抵の仕事で必要なことですので、努力して上達してください。
少なくともリンクエラーの解決よりは重要なことです。
何もナントカ文学賞を取りたいわけではないので、
必ず到達できるはずです。
(そうでないなら日本で日常生活を送るのも困難なレベルでしょう)

文章がうまく書けない(書かない)事の問題点は2つあります。
まず、あなたの問題が回答者に伝わりにくいこと。
掲示板で質問する上で、大きなディメリットになることは
理解してもらえると思います。

もう1つはさらに深刻で、問題を人に伝えられないのは、
自分が問題を正しく認識できていない、ということです。
「分からないから質問しているんだ」という甘えがないでしょうか?
第三者に理解できるように問題を論理的にまとめることは、
自分の理解にもつながります。
質問をまとめようとしているうちに、自力で解決できる場合もあるでしょう。

質問者が正しく状況を説明しないと、回答者には状況が判りません。
よほど小さい場合を除き、回答者はソースコード全体を読むことも出来ないし、
ましてや直すことも出来ません。
自分の問題を理解して、回答者に分かるように説明し、
回答者のアドバイスを理解して、自分の問題に当てはめて解決する、
全て質問者の行うことです。

自分の問題と回答者のアドバイスを理解することなく、
お願いしますとだけ連呼されても、回答しようがないのですよ。


返信引用
maru
 maru
(@maru)
ゲスト
結合: 17年前
投稿: 358
 

よく分からないのですが、
> もうし、以上のことを一つのDLLを処理すると、このDLLでかくなります。
DLLが大きくなるとどんな問題が発生するのですか?
それ(DLLを小さくすること)は
>その構造体を扱う為の処理はそのDllに集中させるのが普通です。
という事より重要ですか?


返信引用
PATIO
(@patio)
Famed Member
結合: 3年前
投稿: 2659
 

なんかmaruさんの後に書くのがパターンになってますけど。(^^

Dllが大きくなると言うことの問題点がきちんと提示できないと
議論にならないです。例え複数に分けて提供したとしても
全部揃わないと動かないライブラリなら分ける事に意味が有りません。
それならば一つのライブラリをして提供した方が使いやすいし、
混乱も起きません。
特に昨今の開発環境は一昔前よりもずっと高性能ですから
分割しないとビルドに時間が掛かって効率が悪いと言うことは
殆ど無いです。逆にそういう状況になるならそもそもモジュール分け
の段階に問題があると考えても良いと思います。

通常、Dllを分けると言うのは分けた一部のライブラリだけで
再利用が可能であるとか、インターフェイスをあわせたほかのライブラリに
挿げ替える事で機能を変更できるとかそういう設計上のメリットが
あるから分けるわけです。
そういう切り口で考えた時にggさんが言っている様な状況になる事は
まず無いと思います。


返信引用
PATIO
(@patio)
Famed Member
結合: 3年前
投稿: 2659
 

ちなみにですが、あるデータを扱う為の処理は一つのDllに集中させるのが
普通です。頻繁に利用するデータ加工処理も同じDllに入れて良いと思います。
但し、表示ロジックその物は通常はアプリケーション側に置くと思います。
これは表示処理その物はアプリケーション毎に異なる可能性があると
考えるからです。

なので、通常はアプリケーションが表示用の処理を用意して
データの管理や編集はDllに任せると言うのが一般的な構成だと思います。


返信引用
gg
 gg
(@gg)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

たいちうさん、maruさん、PATIO さん
ご返事ありがとう。

>特に昨今の開発環境は一昔前よりもずっと高性能ですから
>分割しないとビルドに時間が掛かって効率が悪いと言うことは
>殆ど無いです。
わかりました(ずっと前そういう印象があります。)。

>なので、通常はアプリケーションが表示用の処理を用意して
>データの管理や編集はDllに任せると言うのが一般的な構成だと思います。
なるほど、表示用=>アプリ
     I/O、編集など=>DLL
その中に、
     文字のData=>文字処理DLL
     線分のData=>線分処理DLL
別々のDLLにすること。

ちなみに、日本語を頑張ります。

ほんとにありがとうございました。


返信引用
固定ページ 3 / 3

返信する

投稿者名

投稿者メールアドレス

タイトル *

プレビュー 0リビジョン 保存しました
共有:
タイトルとURLをコピーしました