システム時間が悩ましいので質問しました

Question

システム時間が悩ましいので質問しました。
年月日は
システム時間とは日本時間のことでしょうか、それともグリニッジ標準時の
ことでしょうか。パソコン内で起動しているのはどちらでしょうか。

プログラムで使用している設定の日付関数は下記です。ＭＳＤＯＳで使用して
いた関数では対応できないと思い作成しました。

当初は　//の部分を使っていましたが、具合が悪いので下行に修正したと思います。
数年前なのでどうしてそうしたのかは覚えていません。ただ、この関数は日付変更を
頻繁に使うプログラムで使っており、以後問題を起こしておりませんので、
これで良いのだという認識を持っています。

/*************  Winodows専用  *************/
int set_date(int year,int month,int day)
{
 int sw2;
 BOOL sw;

 SYSTEMTIME systime;  // SYSTEMTIME構造体

// GetSystemTime( &systime );  // 読み出し
 GetLocalTime( &systime );  // 読み出し
 systime.wYear  = year;  // セット
 systime.wMonth = month;
 systime.wDay   = day;

// sw = SetSystemTime( &systime);  // 書き込み
 sw = SetLocalTime( &systime); 
 sw2 = (int)sw;
 return(sw2);
}

　さて問題提起の発端は
前日までのファイルを削除する必要が生まれ、
ファイル作成日時か更新日を取り出す関数を作成したことにあります。
その時点での日とファイル作成日あるいは更新日との比較になります。

その時点での日は_strtime( tmpbuf );から取得しました。
もちろん年は西暦の下２桁であるので
そこは修正しています。この関数を使って現在の日を取得しています。

ファイル作成日時か更新日を取り出す関数
　　　　前略
 hd = OpenFile(filename,&info,OF_READ);
 sw = GetFileTime((HANDLE)hd,&ftcr,NULL,&ftlt);
 sw = CloseHandle((HANDLE)hd);
 if(type_sw == 0){ sw = FileTimeToSystemTime(&ftcr,&stm); } // 作成日
 else{ sw = FileTimeToSystemTime(&ftlt,&stm); } // 更新日
 後略
これを使って、テストではＯＫだったのですが、実際に使って見ると
日によって日付が１日ずれることがあることに気づきました。
９時間連れていることに。
そこで修正のため、
 // グリニッジ標準時間で取得されているので日本時間に調整必要
 year = stm.wYear; month = stm.wMonth; day = stm.wDay;
 hour  = stm.wHour; hour += 9; // 時差９時間
 if(hour > 23){ day++; }
 last_day = month_lastday(year,month);　// 月末日算出関数
 if(day > last_day ){ day = 1; month++; }
 if(month > 12){ month = 1; year++; }
を追加しました。ファイルの日時は全てグリニッジ標準時間のようです。
関連してですが、システム時間とは_strtime( tmpbuf );で取得した時間でしょうか。
それともグリニッジ標準時間なのだが、修正して取得しているのでしょうか。
この辺がややこしいので質問しました。

Answer 1

9 時間無理矢理自分で補正すると、タイムゾーンが違う環境で動きません。
その国・地域のタイムゾーンで取得したいのであれば、FileTimeToLocalTime などを利用するべきでしょう。
http://msdn.microsoft.com/en-us/library/ms724277(v=vs.85).aspx

System Time
http://msdn.microsoft.com/en-us/library/ms724961(v=VS.85).aspx
Local Time
http://msdn.microsoft.com/en-us/library/ms724493(v=VS.85).aspx
File Times
http://msdn.microsoft.com/en-us/library/ms724290(v=VS.85).aspx

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 2

>システム時間とは_strtime( tmpbuf );で取得した時間でしょうか。
いいえ。Local Timeです。
CRTのSource Codeを読むと分かりますが、GetLocalTime APIを呼び出しています。

>それともグリニッジ標準時間なのだが、修正して取得しているのでしょうか。
そうです。APIがそうしています。

[_strtime, _wstrtime]
  http://msdn.microsoft.com/en-us/library/k2besbye(v=VS.80)
  The _strtime function copies the current local time

別件ですが、set_date関数のGetLocalTime > SetLocalTimeの処理は何か意味があるのでしょうか？
処理速度にもよりますが、set_date関数を呼ぶたびに数Millisecondずれて行きませんか？

Answer 3

ところで、時間管理にあるCRT関数を使えば、MS-DOSと共通もしくは類似の処理ができますが。

Windows APIのGetLocalTimeとCRTのtime + localtimeの違い（なぜわざわざAPIが２系統存在するのか）は理解されていますか？

別スレッドで、MS-DOSとWindowsのソースコードの共通化と言われていましたが、どうも肝心なところが空回りしているように思います。ついでに言うとハードディスクの寿命を延ばす考慮も、実際には寿命を縮めることばかりしてそうですし。

Answer 4

そう言えばそんな心配はありますね。
でも意味はあります。
SYSTEMTIME systime　では日付以外に時間も含まれています。
直前に時間の方を読み込んで置かないと、この構造体の時間部分はどう言う取り扱いになるのでしょう。
ひょっとしたらとんでもない時間を設定してしまうかも知れません。
その予防のためです。

Answer 5

ありがとうございます。
どこでも使えるようにするには、その地域の時間を取得する方が良いでしょうね。
ご指摘の個所を勉強して見ます。
ただ、夏時間の制度が日本にはないので　もう一つしっくり来ないものですから
(実感がないので）
取りあえず時間もないので、現在作成中のプログラムは　このスタイルで続けたいと思います。
次のソフトでは利用を考えてみます。

　何故システム時間の質問をしたかを掘り下げて説明しておきます。
Biosを開いて、日時の所を見てみると現在の日時を表示しています。
数値が合値することから、これてLocalTimeですよね。Biosでは表示以外に
設定もできることと、国別を入れる個所がないことから、機器的に保持されているのは
LocalTimeそのものだと考えています。厳密に言えば日本時間と言う（現在地は
日本なので）のがこれに当たるのでしょうか。又ファイルの更新日時等が
グリニッジ時間になっているのは、そうしないと別々の場所で作成された
ファイルの日時と比較する時に困るからだと考えます。同じ理由で
インターネットでそれぞれの日時が異なると困るのでその標準時刻として
グリニッジ時を用いているのだと思います。
私はこう考えます。SystemTimeとは概念的に考えられた時間で、実質的に
グリニッジ時と同じになります。
そうした上で　SystemTimeを中心に考えると日本時間がLocalTimeとなります。
これで正しいでしょうか。

Answer 6

そこまで調べたことはないので判りません。
MS-DOSとWindowsのソースコードの共通化は考えていません。誤解です。
これまでＭＳＤＯＳで開発した作業用関数をなるべく生かしたいと考えているからです。
そうした方がプログラミングする際に頭の中でイメージ化しやすいからです。
もちろん、その関数より良いものが見つかれば、その時点でそれを採用します。
その結果、両方が入り混じった環境になっているのです。
　もちろん、両方の混用はずれを生じる等リスクはあることを常に留意しております。

例えば、ファイルをオープンするとき、
最初に_open　_closeを使い次にOpenFileを使うとファイルハンドルが違います。
_open　_closeと使い、次に_openを使った時、必ず同じハンドル番号になります。（hd = ４）
一旦使ったハンドル番号が解放されるため、二回目にも同じハンドル番号が割り当てられるからです。
混用した時は異なるハンドル番号が割り当てられるようです。それも二桁の数字に
なっています。（hd = 11）
　この理由は知りませんが、混用で困るケースがあるからだ推測しています。

Answer 7

MS-DOSとWindowsのソースコードの共通化は考えていません。誤解です。

そうでしたか。グローバル変数を使ってまで類似コードで実現しようとされていたので、誤解していました。

これまでＭＳＤＯＳで開発した作業用関数をなるべく生かしたいと考えているからです。
そうした方がプログラミングする際に頭の中でイメージ化しやすいからです。

それをもって共通化を考えているのかと思いました。先の返信でも少し触れましたが、Windows APIではなくCRT関数ならMS-DOSと共通なのでイメージ化しやすいと思います。システム時間についてもわざわざ未知の関数を使わなくても今までと同じものが使えます。

例えば、ファイルをオープンするとき、
最初に_open　_closeを使い次にOpenFileを使うとファイルハンドルが違います。
_open　_closeと使い、次に_openを使った時、必ず同じハンドル番号になります。（hd = ４）
一旦使ったハンドル番号が解放されるため、二回目にも同じハンドル番号が割り当てられるからです。
混用した時は異なるハンドル番号が割り当てられるようです。それも二桁の数字に
なっています。（hd = 11）
この理由は知りませんが、混用で困るケースがあるからだ推測しています。

11にはなりません。_open()は元になっているUNIX仕様のopen()関数に

The file descriptor returned by the open() function is the lowest numbered file descriptor not currently open for that process.

というものがあり、必ず最小値が返されることになっています。_open()もこの仕様に準じています。11が返されるのは0～10がすべてオープン中の場合に限り、Windows APIのOpenFile()には依存していません。単に_close()し忘れです。

# ちなみにfile descriptorの略なので一般的に fd と呼び、hdと呼ぶ人はいません。

…と確かめもせず書いたけどどうなんだろう。"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\osfinfo.c"の_alloc_osfhnd()にそれらしいことが書いてある型たぶんそういう動きをすると思うけど。

Answer 8

>直前に時間の方を読み込んで置かないと
set_dateに渡す引数はどこから取得しているのでしょうか。
Y/M/Dは設定されていますが、H/M/Sはすでに正しくどこかで設定されているのでしょうか。

GetLocalTimeで時間を取得していたので、
H/M/S(/MS)はすでに正しい値になっているという前提が必要になりますね。

その前提が分からなかったので、もしかしてH/M/Sの設定はしていないかもしれないという可能性、
及び、H/M/Sをどこかで設定しているのなら、
纏めてY/M/D/H/M/Sを設定したほうが誤差が少なくなるのではないか、と考えていました。

Answer 9

この関数は日付変更を頻繁に使うプログラムで使っており、以後問題を起こしておりませんので、これで良いのだという認識を持っています。

　「期待通りに動いているように見える」と、「これこれの根拠によって、期待通りの動作を行う」は、違うと思います。

　実際に、「期待通りに動いているように見える」だと思います。あるいは、「たまたま、期待とそぐわない動作をするタイミングでは使用していない」か。…そうでもないか。Windows Time サービスを止めれば、あるいは NTP サービス サーバー（ドメイン環境ならドメイン サーバー）と繋がらない環境なら、期待にそぐわない動作をするタイミングは、なくなりますね。

　ところで、何のためにシステム時間を変更するのでしょうか。これを変更すると、イベント ログ等に記録される時間も変わります。ログに残る時間が変わるということは、ログの時間軸の信頼性が無くなるということです。これは、問題にならないのでしょうか。

訂正：Network Time Service じゃなくて、Network Time Protocol service だったorz

---

Jitta＠わんくま同盟

Answer 10

kozzさんも指摘されていますが、日付を入れ替えるたびに時刻が数ミリ秒ずつ遅れていくように思います。ちなみにWindowsでは100ナノ秒刻みで時刻管理しているため、ずれは相当大きなものになります。JittaさんはいきなりWindows Timeサービスの話を持ち出しましたが、NTPを使って日本標準時に合わせるとかSetSystemTimeAdjustment()を使ってゆっくりとシステム時刻を進めるとかそういうこともきっとご存じないかな。

システム時刻を変更する理由は私も気になりますが、まさか生成されるファイルのタイムスタンプを制御したいとかそういう理由だったらどうしましょうね…。

ともかく、システム時刻はプログラムの都合で変更するものではありません。

Answer 11

JittaさんはいきなりWindows Timeサービスの話を持ち出しましたが、NTPを使って日本標準時に合わせるとかSetSystemTimeAdjustment()を使ってゆっくりとシステム時刻を進めるとかそういうこともきっとご存じないかな。

　set_date 関数で日付を調整したとたん、Windows Time サービスが実際の日付に直す、つまり日付は変わらないというケースを想定していますが、間違っていますか？XP では、次の時刻合わせは7日後のようですね。もっと頻繁に問い合わせをやっているイメージがありましたが、アレはサーバに繋がらないとき、ですね。毎日シャットダウンしていたら、サービスによる調整はない、ですね。

---

Jitta＠わんくま同盟

Answer 12

誤解を招いたようですみません。Jittaさんへの返信の形をとりましたが、内容は全て質問者の方への返信でして。Jittaさんに対して「ご存じないかな」と言ったわけではありません。

Answer 13

時間料金計算機（タイムレジスタでは）では月に２分～３分誤差が生じます。

そこで、営業前もしくは営業後に時刻修正を行うように、ユーザーにはお願いしています。

日付の変更は通常ではあり得ませんが、パソコンを交換する時に使う可能性があります。

もっとも修理もしくは新品のパソコンは点検で日付が正しいか事前に判りますので、

これまでは実際に使ったことはありません。ありませんが、古い機械を臨時に使用する場合

日付が止まっていたり、バッテリアウトで初期値が入っていたりするのは良くあることなので

アプリケーションに日付変更項目を設けています。まあ、時間修正があるのに日付がないと

ユーザーに不安があると困りますから。それと、アプリケーションはオートスタートで

終了後に自動でシャットダウンする設定になっていますから。（ユーザー側からはデスクトップが

見えない状態ですので、アプリケーションで設けて置くと安心感が与えらえるでしょう）

 

Answer 14

>時間料金計算機（タイムレジスタでは）では月に２分～３分誤差が生じます。

ROMしてましたが、なるほどですね。以下は雑感でアドバイスではありません。あしからず。
以前、山間部などの遠隔地の工事現場などで使う出退勤(入出)を含む時刻管理を作った
ことがありますが、たしかにタイマーの誤差解決は必要でした。最初はPC内部タイマーを
使ってましたが、当時のPCの精度ではだめで、結局GPSデータで、PCの時刻あわせを
行ったことを思い出しました。当時は高価なものでしたが、いまや1万円前後でUSB GPS
が買えますからねぇ。
ディスクへの懸念の件も、似たような心配をしましたが、当時はHDDしか選択の余地が
無かったので、バックアップを運用してもらいました。週一にモデム経由でログを都会に
転送してましたです。15年ほど前の話ですね。

Answer 15

少し詳しく書くべきだったのかなと反省しています。

まず、hd1 = _open(... を続ける

　　　　hd2 = _open(...と連続すると、例えばhd1が4だとすると、hd2は5となります。

hd2の前に　_close(hd1)を実行すると、hd2は4となります。常に最小の数値がハンドル番号として与えらることは理解しています。

ところで

hd1 = _open(...

hd2 = _open(...

sw  = _read(hd1...

sw   = _write(hd2...    ファイルをコピーする

_close(hd2)

_close(hd1)

この時点では、ｈｄ２のファイルの日付や時刻は　_close(hd2)を実行した時になっています。

そこで　ｈｄ１の日付や時刻をコピーし、それをｈｄ２のものにしたい。

この時点でファイルの日付や時刻の書き込みにWinAPIしか思い付かなかったので

hd1 = OpenFile(... を使った訳です。そうしてファイルの日付や時刻読み込み　　この時点で１１であることに気がつきました。

GetFileTime(hd1...

CloseHandle(hd1)

hd2 = OpenFile(...

SetFileTime(hd2...

CloseHandle(hd2)で、ファイル１の日付、時刻をファイル２の日付、時刻に

コピーしました。

それとｆｄと書かないでｈｄと書いたのは（文字の事などどうでも良いのですが）、最初にCを勉強した本には

ｆｐとありましたが、これはｆｏｐｅｎに使用されており、ｆｄでは、間違いやすいことから_openにはhdを使用しました。

ｆｏｐｅｎと_openの違いをより意識させるためだったと思います。

途中から_openのみを使用して来たので、その経緯からｈｄを使う習慣になりました。

　追伸、かつて、open closeを対に使用しなかったために、どんどんと数値が増えて行き、機械が固まった経験をしています。

以来、openと closeは必ず対で用い、同一関数内でopenしたものは必ず同じ関数内でcloseを行うように意識付しています。

グローバル変数とて同じです。

 

 

Answer 16

おっしゃることの何もかもが１０～１５年は時代遅れで…。

OpenFile()は非推奨でCreateFile()を使うことになっています。（Windows 95からだから１６年前の話…。）

_open()の戻り値ファイルディスクリプタは int 型です。OpenFile()は HFILE 型で、CreatFile()は HANDLE 型です。データ型が違うので値を比較しても意味がありません。つまり、_open()が4を返しオープン中のままであってもOpenFile()やCreateFile()が4を返すことがあります。

そこで　ｈｄ１の日付や時刻をコピーし、それをｈｄ２のものにしたい。

本当に予想通りの目的でシステム時刻を操作していたんですね。

既にURLを紹介していますが、CRTの時間管理には、開いているファイルの時刻を変更する_futime()と指定されたファイルの時刻を変更数する_utime()があります。これらはそれぞれfutime() / utime()の名前でMS-DOSにも存在します。
CRTでなくWindows APIならSetFileTime()で、既に利用されているGetFileTime()のドキュメントページからもリンクされています。というか名前から想像がつくはずです。

MS-DOSの知識もろくでもないようですので、あまり「ＭＳＤＯＳで開発した作業用関数をなるべく生かしたい」ということは考えない方がいいです。

Answer 17

ファイルのタイムスタンプに気を配っているようですが、一般に
　1.ファイルのタイムスタンプは簡単に変更されてしまう。
ため、
　2.中身のデータの属性として、それを含むファイルのタイムスタンプは使用しない。
のが、普通です。
データ内にはそれの属性としての時刻データを入れておいたほうが良いでしょう。
そうすれば面倒なファイルのタイムスタンプ管理をしなくて済みます。
別の方法としては、ファイル名に、その中身の属性としての日付時刻を含ませてしまう
方法も考えられますね。この場合も本来のタイムスタンプを管理する必要はなくなり、
シンプルな仕組みにできます。

Answer 18

知識の少ないのは事実ですから、普通に勉強された方からはそう見えるでしょうね。

ただ「ＭＳＤＯＳで開発した作業関数は...の下りには、ちょっと賛成致しかねます。皆さんがそれぞれ作って来た関数には、色々な経験から

試行錯誤して、へたくそでもそれなりに納得して　作成されて来たはず。これは大変大事な点です。

私はＢＡＳＩＣの経験を積んでＣ言語に入りました。Ｃ言語はメーカーの機械がＣ言語しか動かないので仕方なく、Ｃ言語を勉強することに

なった訳です。ＢＡＳＩＣを知っていたことがあざとなって、普通に扱えるようになるまで、１年以上掛かったと思います。

一番困ったことはＢＡＳＩＣでは当たり前だったlocateや数字中のカンマ等がなく、全て自前でそれに相当する関数を自作しなければ

ならないことでした。何十冊かの本を読みあさり、あっちの個所からひとつ、こっちの個所からひとつと参考になる部分を見て

全て自作するしか方法はなかったのです。今のようにインターネットがある訳でなく、図書館や本屋をはしごして読みあさりました。

　本来は営業の仕事が本職です。勉強は客先から客先への移動の間の時間や、帰宅後に行いました。

実際にプログラムを作るきっかけも、納期が間に合わないので手伝ったことからです。

　時間が少ないので、仕事で使わざるを得ない部分は深く勉強し、それ以外は触れませんでした。目的は勉強ではなく、客先にプログラムを提供

することにあるからです。ご指摘のutilmeは実際に使用したことはありませんでした。この頃はこの関数はもっぱら、プログラム

ファイルのバージョンを表す設定に利用されていたと思います。（時間部分を流用）　変更に使うイメージはありませんでした。

　さてＭＳＤＯＳ用からＷｉｎｄｏｗｓ用にプログラム作成を変えるのに、５年掛かりました。Ｗｉｎｄｏｗｓのプログラミング本はどの本を読んでも、全て

ＭＦＣを使った方法でした。確かに、記載したように行えばその通りに作れるのですが、そこから発展しないのです。ずっとそのままでしたので

一時は諦めて、Linuxに転向したこともあります。ある時図書館で古いWindowsのプログラミングの本を見つけました。

　この本の著者は現役のプログラマーであったためでしょうか、Ｗｉｎ３２ＡＰＩを使った具体的なプログラミング方法を提案していました。

この本を読んで、わずか３ヶ月でWindows板のプログラムを作成できました。

　この経験から、これまでの失敗の原因がどこにあったのかを悟りました。イメージングがプログラムそのものだと悟りました。

プログラムを作成するときにその作業や手続を思い浮かべると自作の関数が次々と頭の中で出てきて、その関数を順番に書き加えて行く

だけで、プログラミング作業は進んで行きます。他の人がどうしているかは知りませんが、私の場合はそのようにしています。

　こうした方法では自作関数を出来るだけ多く作成しておくことがポイントになります。私の経験から言えば

１本のプログラムのソースが大体１５万行あるとすれば、１５万行を要するプログラムのプロトタイプを一人でわずか３ヶ月で作成することは

可能です。　作業ファイルはその時点で別の良い方法が見つかれば、それに変更して行きます。それで良いと思います。

イメージングを損なわないこと。これが私にとって一番大事な事なのです。異形のプログラマーで済みませんでした。

 

 

 

 

Answer 19

外池と申します。私は本職のプログラマーではないので、的外れなことを申し上げているかもしれませんが、気付いたことを一点だけ。「作業関数」というものが、「設計」に属するものか、「実装」に属するものか、と無理やりに分けたら、「実装」の部類に含まれるという前提で申し上げます。（違ってたら、ゴメンなさい。以下、スルーしちゃってください。）

「設計」が同じでも、あるいはほとんど変更なくても、「実装」の類は、プラットフォーム（ＯＳやネットワーク構成など）が異なれば、完全に書き直しだと私は思っています。

で、「設計」は、「実装」に依存しないようにすべきなのですが、どうも質疑応答を拝見していると、「実装」にすごく依存した「設計」をなさっていて、苦労されているのでは・・・、と感じました。

「イメージング」って聞くと「設計」のことのように感じたのですが、お独りでどんどん作っちゃっているご様子で、それだと「実装」のことかな、とも思うし。「設計」と「実装」がうまく区別できていないことが問題？

---

（ホームページを再開しました）

Answer 20

自分もN88BASIC、同(86)、他メーカー製の雑多なBASIC、DOSは2.1x～4.x位まで、
Windowsは16bitの2.1、3.xあたりから～現行バージョン、OS/2はWarpまで
言語はBASICの他、PASCAL、C、C++、Java位はやってます。
現役のプログラマです。過去に
　1.BASICからC言語に移行するとき、
　2.DOSから16bitWindowsになったとき、
　3.16bitから32bitWindowsになったとき
の3回、それまでのソースコードをお蔵入りにしました(笑)。
いかに優秀な設計であっても「その時点での既知の技術を前提にしている」ため、
過去の設計はどうしてもだめな部分があります。ある程度はあきらめなくてはなりません。
それを踏まえて問題点を整理して解決方法を検討しましょう。
自分に答えられることがあれば協力しますよ。
ただし、最新の情報には疎いですけどね、年だし(vv;)。

Answer 21

状況的に対応せざるえない状態で本来なら担当する部分ではない所まで作業を行ったのだという部分に関しては
わからなくはないのですが、書かれている内容を読んでいるとかなり無理をされたのではないかと感じました。

Win32APIを使ったプログラミングを行なう事でWindowsの仕組みを知る事ができます。
但し、そのためには言語レベルの知識やWindowsの仕組みに関する知識も無いと
きちんと腑に落ちる状態にはならないのではと思っています。
必要な部分のみ深く、それ以外は触れなかったという部分の内容にも寄りますが、
一見、関係無いように見えて必要な知識と言うのは確かにあります。
それを理解していない為に誤解したまま進んでしまうという事も。
確かにご自身としては営業職でありながらプログラムの手伝いをされたわけで
自分の本職は営業職であるという気持ちはおありなのかもしれません。

ただ職種がどうであれ、お客様から見たらプログラムを作成した人には変わりないわけで
そうなると営業職が本職であるという部分は関係無い話になります。
きちんとしたプログラムが収められる事が大切と言う話ですね。
最初の段階で手伝った時であれば、必要な部分のみでと言うのもありだと思うのですが、
実際にプログラム作成の仕事も続けておられるようですからそうなるとご本人が必要だと
思った部分だけを勉強した状態で果たして大丈夫なのかと言うことにならないでしょうか。
自分の必要だという判断が何処まで当たっているかと言う話になると思います。

ご自身で異形とおっしゃられていますが、果たして異形のままで居続ける事が正解なのかという部分も
考えてみられた方が良いのではないかと感じました。

あと、プログラムをソースの行数やステップ数で判断するのは、C言語やC++言語ではあまり薦めません。
なぜかと言うと実装によっては少ないステップ数で実現できる可能性があるからです。
行数があまりに多い状態は決して良い状況とはいえません。
必要最小限のソースで大きくなってしまうような仕方がないケースもありますが、
この場合はサブシステム単位に分割する等でそれぞれの固まりはなるべくコンパクトにする等を考えます。

どなたかが書かれていましたが、イメージングと言うのが設計と言う話なのであれば、
その設計は正しいのかと言う部分もまた大事だと思います。
慣れた方法でどんどん作成できる事が正しいのかと言うと違うと思いますし。
異なる設計であっても同じ動作をさせることは可能ですが、その設計がより良い設計になっているかという観点は必要だと思います。
今までの資産を利用することも確かに必要ですが、その資産を再利用する事が最善の策なのかと言う判断もまた必要だと思います。

なんか、質問の内容からずれてしまった感は有りますので要求されない限りはこれ以上は書かない事にします。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。

Answer 22

厳しい意見が多いですが、私は自分が売っているもののことを知ろうともしない（製品名さえ覚えていない）営業に泣かされたことがあるので、これからもがんばって欲しいです。

---

Jitta＠わんくま同盟