トップページ

本棚


両手で1000まで数えられますか?:2進法の話
数値 - 危険物取り扱い注意
100 × 200 =32?:変数のオーバーフローの話
パリティビット
小数の扱いについて
ぽいんた
ぽいんた2
ぽいんた3
ジ・オリジン
ジ・オリジン:補足
かっこつける話
かっこつける話2
文字列のこと
タイミングの話
拡張性の話
取り込む話
staticな話

コンパイルの話1
コンパイルの話2:止まらぬビルド
コンパイルの話3:マシン語に落ちるということ1:メモリの話
コンパイルの話4:マシン語に落ちるということ2:最適化
コンパイルの話5:マシン語に落ちるということ3:変数とスタック
コンパイルの話6:コンパイラはそもそも何をやってくれるのか??
リンクの話
プリプロセッサの話

OS、というもの

オブジェクト指向1
オブジェクト指向:2
オブジェクト指向:3

オブジェクト指向:番外 C言語のソースファイルの話
オブジェクト指向:番外 C言語での「再利用性」と「カプセル化」データ構造とアルゴリズム


抽象的な話

寝込んで布団の中で考えたこと
こんなの、常識??
お仕事プログラミング
ソフトでハードなプログラム
プログラムするということ
お勉強
プログラムを学ぶということの補足
C言語:「学問」と「実務」
統合開発環境
C言語ってポータブルですか?
C言語ってポータブルですか?:2
あなたは、どう読みますか?
ああ勘違い
試してガッテン
低級品
質問をするということ
ポカ
「何もしない」 != 「無駄」
エディタの話
もっと手を抜こう

いまどきの、アセンブラ

VisualStudio2005
VisualStudio2005:2

戦争の防ぎ方、に対する私の考え
身近な差別
改革
地球に優しいなんて大嘘
統計で嘘をつく方法

言葉について
言葉について:2

神が死んだということ
善悪の彼岸から、力への意思を目覚めさせるということ

本を読むということ
本を読むということ:2

絵を描く話
地図
地球儀

オカルトのお話
がんだむさん
RPGソフトウェア
記紀神話の不思議



メニュー

※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

作業対象のソースコードの解析を行っていたわけですが。

とりあえず、一通りの処理の流れは把握できたように思います。

doxygenのおかげでクラスの継承関係は把握できたので、流れは追いやすかったです。あとは、制御対象機器周りの細かい機器依存部のみ。

週明け月曜日にはなんとか、実務レベルの把握ができると思います。
・・・正直、かなりほっとしているわけですが(笑)


C++についてもだいぶ慣れてきました。

長らくC言語しかやってなかったから、それが一番しんどかったかも(笑)
ソースの書き方もそうだけど、ソースの解析手法もC言語とC++では、効率のいいやり方はだいぶ違うと思います。


C言語の場合は関数単位で見ていけばいいので、特に気をつけるべきことはあまりないように思います。関数名もプロジェクト内でユニークなものなので、grepかけたら終わりです(笑)

ですがC++にはクラスの継承、関数のオーバーライド・オーバーロードがあります。したがって、単純にgrepかけてみても求めるものが求める場所(ソースファイル)になかったり、逆にいっぱい同じ名前で検索に引っかかったりするわけです。


なので方法としては、次のようになると思います。

(グローバル関数でないかぎり)スコープが限定されているのでどのクラスのメンバかはすぐにわかるので、それをもとにヘッダファイルを見てみると、そこで宣言されているか、されていないにしてもそのクラスがどのクラスから派生しているのかがわかるわけで。

あとはそれを順にたどっていくことで目的の関数にたどり着くはずです。

・・・ただし、そんな馬鹿正直なことをやっていると継承が深い場合や多重継承(javaとちがって、C++はこれができてしまうから)の場合などは時間も手間もかかってしまいますが(笑)

特に、インターフェースを統一するためにあるクラスを基底においてある場合などは結構よくあるパターンな上に継承の階層が激しく深かったりします。


こういうときは、前述のdoxygenのようなツールに頼るのが一番だと思います(ドキュメントがすでにしっかりしているのなら、それに越したことはありませんが・・・)。

オブジェクト指向言語のソース解析は、UMLなり何なり、とにかくクラス図。話はそれからだと思います。まだ解析初めて二日目だから、あんまり偉そうに言ってしまうと怒られちゃうかもしれませんが(笑)


「ツールに頼ると実力がつかないから、自力でやったほうがいい」という方もいらっしゃるかもしれません。

ですが「実力を付ける」だのというのは、仕事でそれができるのならそれがベストですけれど、その過程で作業的に無駄が入るのであればそれは間違っています。
それならば、作業としては効率優先で行い、自分の時間(週末や帰宅後など)を利用してやるべきです。


私はC++についてだいぶ忘れかけていた状態から、3日ほどで18MBのソースを把握することができるところまで来ているわけです。まじめに自力だけでやったとしたら、(ドキュメントもほとんどないため)おそらくは1週間ほどはかかってしまったことでしょう。

かつ、その過程においてツールを使ったからといってC++を使えないわけでもありませんし。ソースをまったく見ていないわけではないし、ツールに頼っているのは階層関係の把握と定数定義を探すのに時間がかかるのを避けたかったわけで。

それ以上の解析については結局人間が(というより自分が)やるしかないんだし、そもそもソースを解析するというのはソースを把握、理解するためにあるわけです。


ソースを理解していくということは、そのソースがC++で書かれている以上、C++を身に付けざるを得ません(でないと、いかにツールを使ったとしても「理解」はできないはずです)。


私の持論として「結果が同じとなるなら、それにかける手間はできるだけなくす」のがいいことだと思っています。
それは単にらくだから、ではなく時間的な意味でも、作業的な意味でも余裕を作ることができるということです。

もちろん、手間をかけたときよりも結果の品質が下がるなどということがあってはいけません。それは大前提ですが。



結果の品質には注意が必要ですが、極力手を抜くこと。

「高品質かつ低コスト」これがベストだと思います。




| 新しいページ | 編集 | 差分 | 編集履歴 | ページ名変更 | アップロード | 検索 | ページ一覧 | タグ | RSS | ご利用ガイド | 管理者に問合せ |
@wiki - 無料レンタルウィキサービス | プライバシーポリシー