雑記内検索 / 「オブジェクト指向:2」で検索した結果
-
オブジェクト指向:2
グダグダ言っていてもしょうがないので、まじめにオブジェクト指向なお話。 オブジェクト指向の使いどころと学び方について。 オブジェクト指向とは、従来の構造化言語(C言語など)と異なって、「オブジェクト」という単位で考えよう、ということだ。 なんて簡単に済ませてしまうと怒られそう。。 でも、オブジェクト指向の話なんて、本屋に言ったらいっぱいあるから、あえてここで私が述べる必要のあることってあまりない。ほんとに。 ただ、「オブジェクト指向」というパラダイムと「オブジェクト指向言語」と「UML」は、区別したほうがいいと思う。どうも、ごっちゃになっている(あるいは故意にごっちゃにしている)本が多いような。。 前にも書いたけど、C言語でだってアセンブラでだってオブジェクト指向なプログラミングはできる。 JavaやC++は、オブジェクト指向でプロ... -
オブジェクト指向:3
さて(何がさて、なのか)、オブジェクト指向な言語ですが現在有名なところでは C++とJavaあたりがよく使われているのでしょうか。あとC#くらいかな? これらの言語で何が気に入らないかというと、「基本データ型」と「クラス」を 別のものとして扱っていること。 実用的にはともかくとして、思想として美しくないと思うんですよね。 intやbyteとかも、オブジェクトじゃないの?? 特にJavaの場合は、扱いに注意しないといけないような気がする。 だって、クラスのインスタンスって、これ要はポインタじゃないですか。 MyClass hoge; MyClass piyo; hoge = new MyClass(); piyo = hoge; なんてした後、hogeの状態に変更を加えるとpiyoの状態も変化する。これってC++で書くなら MyCl... -
オブジェクト指向1
オブジェクト指向、というプログラミングパラダイムが現れて久しいわけですが、いまだに「オブジェクト指向」って根付いていない気がするんですよね。 JavaやC++/C#が使えたらオブジェクト指向でプログラミング出来ているか、というとそうでもないし。それらの言語はオブジェクト指向な「書き方が出来る」言語であって、それらを使えば自動的にオブジェクト指向のプログラミングが出来るわけではないし、逆にC言語やアセンブラではオブジェクト指向プログラミングが出来ないかといわれると、そうでもないと思うのです。 「オブジェクト指向」とは、あくまで、プログラミングパラダイムの一種だ、ということです。 オブジェクト指向というのがどういう考え方か、なんていうのは世にいろんな本が出ているわけで、いまさらここで私が述べるべきことってないと思います。ただ私がひとつだけいえるのはあくまでそれはプログラ... -
メニュー
...ブジェクト指向1 オブジェクト指向:2 オブジェクト指向:3 オブジェクト指向:番外 C言語のソースファイルの話 オブジェクト指向:番外 C言語での「再利用性」と「カプセル化」データ構造とアルゴリズム 抽象的な話 寝込んで布団の中で考えたこと こんなの、常識?? お仕事プログラミング ソフトでハードなプログラム プログラムするということ お勉強 プログラムを学ぶということの補足 C言語:「学問」と「実務」 統合開発環境 C言語ってポータブルですか? C言語ってポータブルですか?:2 あなたは、どう読みますか? ああ勘違い 試してガッテン 低級品 質問をするということ ポカ 「何もしない」 != 「無駄」 エディタの話 もっと手を抜こう いまどきの、アセンブラ VisualStudio2005 Vi... -
ソースファイルの話
ちいさなプログラムを書いているときには気にもならないし特に問題にもならないけど、だんだんプログラムが大きくなってくるとソースファイルを分割する、ということを行うと思います。 その際に、ただ単純に分ければいい、というものではないことはまあ誰でもわかると思うんです。だいたいは、機能別(C++なんかではクラス単位)に、わけるんじゃないでしょうか? 例えばあるプログラムにファイル処理を行う関数郡と画面の入出力を行う関数郡があったばあい、ソースファイルは 【プログラムのメイン処理を記述したソースファイル】 【ファイル処理用のソースファイル】 【画面の入出力用のソースファイル】 ぐらいに分割すると思います。 その際に、例えばファイルの処理にしてもソースファイル内でサブ関数的な使い方をする関数とメインの処理などからコールされる関数の2種類があるわけです。 ここまで... -
データ構造とアルゴリズム
プログラムとは、「データ構造+アルゴリズム」だという言葉があります。 アルゴリズム(ロジック)だけではなく、目的の機能に最適なデータ構造を選択することも重要です。 がんばってがんばって、ロジックをこねくり回して目的の機能を得たとしても、それは処理時間あるいは処理に要するメモリなどのリソースの面でかならずしも最適な処理とはなっていないでしょう。また、後から保守なり拡張なりで手を入れる際にあまりにロジックがひねくれていると修正しにくいものです。 そこで、「データの持ち方」というのが重要になるわけです。 例えばある要素の集合を「データ」として持ちたいとします。 この「データの集まり」をどう扱うかによって、最適な「データの持ち方」を選択するということです。 要素に並び順があり、かつ要素と要素の間に新たな要素を加えたりする場合には、連結リスト構造がいいでし... -
staticな話
C言語にはstaticという修飾子がある。 これって結構便利な修飾子なんだけど、つかう場面によってすこしずつ意味合いが異なるのがいやらしい気がする。 ①ローカル変数の場合 これはもちろん、静的確保を意味する。関数を抜けても領域がキープされ、次回関数突入時には前回の値が残っている。 int Hoge(void) { static int i; i++; return i; } という関数があったとすると、この関数をコールするたびにiの値はひとつずつインクリメントされることになる。 まあ、常識?? ②グローバル変数の場合 この場合は上とちょっと意味合いが異なってくる。 例えば static int g_iHoge; と宣言したグローバル変数を参照したり変更したりできるのは同一ファイルスコープ内に限られる。 ③関数の場合 例え... -
リンクの話
プログラムの入門書などを見ても、コンパイラについては結構皆さん意識してるんだけど、リンカについてはあんまり記述がない気がします。 実際、ソースファイルを実行ファイルにするには、「コンパイル」+「リンク」というあわせ技は必須なわけですが、どうにもリンカは影が薄い気がしてしまうのです(笑)。 単体のソースファイルのみでプログラムを書いているときはあまり気になりませんが、複数のソースファイルに分割して書いているならば、多少は意識があると思います。 リンカの役割は、(主にソースファイルごとに作られる)オブジェクトファイルの結合です。 ・・・といってしまうと、ソースファイルから機械語のオブジェクトファイルを作るコンパイラの方が主でリンカは従であるようなイメージを受けてしまうかもしれません。 しかし、そうではないのです。 ソースファイル内... -
もっと手を抜こう
作業対象のソースコードの解析を行っていたわけですが。 とりあえず、一通りの処理の流れは把握できたように思います。 doxygenのおかげでクラスの継承関係は把握できたので、流れは追いやすかったです。あとは、制御対象機器周りの細かい機器依存部のみ。 週明け月曜日にはなんとか、実務レベルの把握ができると思います。 ・・・正直、かなりほっとしているわけですが(笑) C++についてもだいぶ慣れてきました。 長らくC言語しかやってなかったから、それが一番しんどかったかも(笑) ソースの書き方もそうだけど、ソースの解析手法もC言語とC++では、効率のいいやり方はだいぶ違うと思います。 C言語の場合は関数単位で見ていけばいいので、特に気をつけるべきことはあまりないように思います。関数名もプロジェクト内でユニークなものなので、grepかけたら終わりで... -
ポカ
12/29の「ビルドがとまらない」関連ネタ。 今日は諸事情により複数のデバッグマシンを 行ったり来たりしながらデバッグ作業をしていたのですが (しかもその合間に例の新人君の面倒見ながら)、 あるとき、ソースファイルを更新してビルドしなおしても 実行ファイルに反映されないという現象が。 ソース上はコメントアウトしているはずのログが出る。 実行ファイルを確認してもちゃんとビルドのたびにタイムスタンプは更新されている。。 しかも変更箇所のソースファイルのあるフォルダの オブジェクトファイルも念のため消してやっても やっぱり反映されない。。 ・・・小一時間ほど悩みました。 結論は、複数台移動したデバッガの途中のPCの時間が、5時間ほど進んでいたため。 そのため、別フォルダにある中間ファイルの タイムスタンプが新しい(とMak... -
コンパイルの話:止まらないビルド
PCの日付には注意しましょう。 あるPCでビルドする際に、別のPCから持ってきたソースファイルをあわせてビルドしようとすると、いつまでたってもビルドが終わらないことがあったりしやがります。 んで、ビルドログを見てみると、どうやらず~~~~~~~~~~~~~~~っと同じところをコンパイル繰り返していたりするのです。 原因は、持ってきたソースファイルを編集したPCの時計が進んでいたから。 種明かしはMakefileにあります。 あるソースファイル、例えば test.c とオブジェクトファイル test.o がMakefileで以下のように依存関係を持っていたとします。 【例】 test.o test.c cc test.c すると、ビルドするときに test.c と test.o(あるなら) の日付をチェックして、 test.o... -
抽象的な話
物事を考えるのには、「抽象化」というのは有効な手段だと思うんですよ。 ソフトウェアの開発においても、それはやはり有効だ。設計の初期の段階から、いちいち具体的なことを考えてはいられないし、自分の担当箇所以外の大まかな動きを把握する際に重宝するわけで。 でも、プログラミングの学習の「入り口」としては、いかがなものか、なあんて思うわけです。 たとえば、Windowsのプログラミング。 描画などの処理をDC(デバイスコンテキスト)として抽象化されているおかげで、細かい部分は別として大まかな捉え方としては画面(ウインドウ)に図形を描画するのとプリンタに出力するのを同じように扱えるメリットは大きいとは思います。 だけど、特にプログラミング自体が初心者だったら、抽象化された概念を把握するまでに時間がかかってしまうと思うのですよ。 たとえば、Javaのオ... -
プログラムを書くということ
プログラミング、というのは難しいイメージがありますが、CPUにできることなんてたかが知れてる。 ①転送 ある領域からデータを読み出す 書き込む コピーする ②演算 四則演算(掛け算割り算ができない奴もいる) ビット演算 ③処理分岐 ジャンプ ループ サブルーチンコール・リターン 極端に言って、これだけ。 皆さんのPCも、PS2も、ケータイも、そのほか中にコンピュータの入ってるもの全て、その制御の中心となるCPUなりが処理できるのはこの3種類。 信じられますか? その意味ではちゃんとプログラムが書ける、という能力は「C言語できます」とか「Javaできます」とか言うことじゃない。言語が何であれ、それを習得しているかどうかはクリティカルな問題じゃない。 ・・・だって、結局どの... -
C言語:「学問」と「実務」
C言語に限ったことではないんですが。 C言語には学問としてのC言語と実用としてのC言語があると思います。 どういうことかというと、 【学問としてのC言語】 ANSI規格への理想的な準拠とみなす アルゴリズムの探求 C言語のみで記述する 【実用としてのC言語】 ANSI規格と合致しているとは限らない まず納期と仕様 場合によってはアセンブラも併用する こんな感じで言いたいことつかんでいただけるでしょうか? 学校なんかで習うC言語は前者だと思います。 入門書なんかのC言語も、そうですね。 しかしながら。 実際、業務においてC言語を使用する場合は後者であることがほとんどです。 実際、現作業で使っているWindRiverのTornado環境では printf( "Hello " "C ... -
「何もしない」 != 「無駄」
たいていのCPUには、「何もしない」ための命令が実装されています。 「No OPeration」ということで通常NOP命令などと言われます。マシン語としてはだいたい0x00h、アセンブラとしてはNOPであらわされることが多いようです。 この命令は、ほんとに何もしないで、実行ファイルのバイナリ領域と実行時のマシンサイクルタイムを消費するだけです。 なぜ、こんな命令が、しかもほとんどのCPUに実装されているのでしょうか? CPUは、通常単体では意味を成しません。基盤にCPUをおいてVccとGNDをつないでも、それはまったく意味が無いただのオブジェにしかなりません。 したがって必然的に、CPUの周りにはさまざまな周辺回路が接続されることになります。 そういったさまざまな周辺回路とCPUの間でデータや制御命令をやり取りすると言うことは、基板上で通信を行っていると言... -
プログラミングする、ということ3:統合開発環境
統合開発環境ってありますよね。VC++とか。 あれって、あんまり好きじゃないんですよね。 ほんのちょっとしたプログラム書くときにも、最初にプロジェクト登録して、設定して。。正直うざい。VC++のコンパイラってやたらオプション多いし、いちいちMakefile書かなくていいからwindows用のプログラム書くなら統合開発環境もいいのかもしれないけど。 でも、テスト用のプログラムなんかはテキストエディタでソース書いて、コマンドラインからさくっとコンパイルしてしまいたい。 それに、ある環境に慣れすぎてしまうと他の環境で作業が行いにくくなってしまう。だいたい、初心者に対してやさしくない。 「C言語の勉強をしよう」と思ってVC++買ってきて、「プロジェクトの新規作成」とか言われてわけのわからない設定をさせられたら、きっと彼は実際にプログラミングに到達する以前に... -
エディタの話
プログラミングする時、エディタは何を使っていますか? 統合開発環境でしょうか?Mifesなど市販のエディタ? それとも、秀丸などのオンラインソフトでしょうか? 「別に何を使ってもいいじゃん」とか、 「とりあえずVC++」とか言う人も多いかと思います。が。 確かに、VC++のエディタは構造体やクラスのメンバを プルダウンから選べたり、関数コールの際に引数を 表示してくれたりと便利な面もありますが。 どうにも、重いです。。 しかも、ちょっとしたお試しプログラムを書きたいだけでも プロジェクト作んないといけないし。 なので、私の場合は主に秀丸エディタを使用しています。 VC++でも外部ツールとして登録して、VC++でのカーソル行と 同じ位置で開けるようにショートカットキーを登録しています。 いくつかエ... -
Cという言語:2
C言語という言語はやっかいである。 コンピュータの発展に伴って言語仕様にさまざまなつぎはぎがされて統一感ないし。 そもそも、C言語の標準規格といわれるANSIに完全に準拠したコンパイラが存在しない!少なくとも新ANSI C言語辞典(技術評論社)がでた時点ではそうだったと書いてある。 実に困った言語なのである。 大体*という演算子だってややこしい。 宣言するときは int *hoge; とポインタであると宣言するために使うくせに、中身にアクセスするときにも i = *hoge; なんて使うし。 変数のアドレスを取得するときは piyo = piyo; だし。 統一感、ないっすよねえ。 returnだって、(今の仕様では)括弧つけてもつけなくてもいいし。 NULLなんていうのもそう。 たい... -
本を読むということ:2
本の読み方(特に技術書)について。 技術書(たとえばプログラミング本)を読むときは、たいてい技術を身につけるために読むわけですが。 漫然と読んでいても、やっぱり頭には入りません。やっぱり、読む「コツ」ってあると思うんです。 それは人それぞれだと思いますが、私の場合の話。 私の場合は、わかるかわからないかにかかわらず、とりあえず一気に最後まで目を通してしまいます。途中でわからないことがあっても、戻って見直したりはあまりしません。 とりあえず最後まで目を通してしまうことで、全体の雰囲気というか、つかみ所をつかんでしまうことができます。その後で理解が不十分だと感じたならば、再びその該当部分だけ読み直します。 こうすることで、最初に読んでわからなかった箇所も、割とすんなり理解できるようになることが多いです。 これは、本を書いている人は「わか... -
アセンブラのこと
最近になってなぜかアセンブラの本が、書店に多くなってきたような気がする。いやアセンブラを学ぼう、っていうのは良いことだとは思うんですけどね、ええ。 でもね、本屋に並んでるアセンブラの本って、本当にアセンブラの勉強の役に立つの??って言うのが正直な感想なんです。 どんな本が並んでいるかというと、まず①アセンブラといいつつPCゲームを改造する本。②80X86およびPentium系CPUのアセンブラの本。③情報処理試験向けCASLの本。④電子工作向けPICやH8アセンブラの本。 番号が若い順に多い。 ①は、論外。 ②は、まあとにかくほとんどのご家庭のPCがWindowsマシンなわけで、プラットフォームは、ある。でもWindowsプログラムをアセンブラで書くっていうのは、少なくともアセンブラ初心者にはオススメできないと思うんですが。 ③は、まあ学習用として... -
神が死んだということ
哲学者ニーチェの『ツアラトゥストラかく語りき』冒頭にて「神は死んだ」と語られる。 神が死んだというのはどういうことか? 「神」という概念は、人間によって生み出されたものである。 それは最初自然現象や民族の成り立ちを説明付けるために考え出され、のちには政治的な権威や道徳の基準として発展していった。 しかし、「科学」の進歩に伴って「神話」ではなく「科学」によって自然が説明付けられ始めることによって、神話によって同時に説明されていた「道徳」もまた、そこで衰退していくことになる。 「神」という、「基準」が我々のなかから死んだのである。 われわれは、「なぜ人を殺しては行けないのか」という問いに客観的な根拠を持って答えなくてはならなくなったのだ。 あるいは「法律で決まっているから」と答える人もいるだろう。「自分がされたら嫌なことは人にもしてはいけないか... - @wiki全体から「オブジェクト指向:2」で調べる