読みやすいソース
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
NGNGその課題を早く終えた場合今度はif文やselect文を使わずにやってみろと
言われるんですがそれって頭の体操にはなっても実際はただ読みずらい
ソースになるだけでとても無駄なような気がするんですけどどうなんでしょうか？
実務ではやはり読みやすいコードが問われるでしょうから。
0002こう３
NGNG0003名無しさん＠お腹いっぱい。
NGNGでも誰もスタイルなんて気にしないか。
0004名無しさん＠お腹いっぱい。
NGNG0005名無しさん＠お腹いっぱい。
NGNG0006名無しさん＠お腹いっぱい。
NGNG恥ずかしいので言えません(w
たいした事やってないですよ。専門の方がいいのでは。
0007名無しさん＠お腹いっぱい。
NGNG0008名無しさん＠お腹いっぱい。
NGNG0009俺が高校の頃は
NGNGＦＭ−ＴＯＷＮＳ使って、ＢＡＳＩＣを教えられたな。
ちなみに神奈川県です。
0010名無しさんi486
NGNGFortran77
C
BASIC
VB
をしましたが。
0011名無しさん＠お腹いっぱい。
NGNGVBじゃなくてCだけどな。
ライブラリ化しても良いのだが、その場合汎用化の
ための無だなコードや広範囲のエラーチェックを入
れにゃならんので、コピぺしてその処理に合うよう
にちょこっと修正するってパターンだ。
俺のモットーが「（組むのが）早い、小さい」なん
で、このようなスタイルになった。
コピぺの塊なんでコメントなんて無くても何やって
るか一目瞭然（笑）。
0012>1
NGNG読みずらいコードを読まされる羽目になることもあります。
あなたの大学でやっていることは無駄ではありませんが、
読みずらいコードに染まらないように気をつけてください。
0013＞１１
NGNG私には似たようでちょっと違うコードが氾濫するほうが恐ろしい
0014名無しさん＠お腹いっぱい。
NGNGそして神奈川工科大へ
0015名無しさん＠お腹いっぱい。
NGNGおお！すごい！
0016名無しさん＠お腹いっぱい。
NGNG区別をつけられないということだ。
その区別の仕方を誰かが教えてやる必要がある。
もちろん真紀俊男以外の誰かがだ。
0017名無しさん＠お腹いっぱい。
NGNGいろいろ試してみるのは必要です.
だめだこりゃ＠｀ってのがわかれば2度としなけりゃいい話で.
ようは綺麗なコードを書こうという姿勢が大事.
0018名無しさん＠お腹いっぱい。
NGNGそうそう.
うぉ!ばぐじゃん!って時はいっこいっこ修正して回るはめに.
っで＠｀たいてい漏れがあったり実はそのちょこっと変えたところだったり.
お願いだからぜったいに自分しか見ない!というプログラムだけにしてください. >>11
# いやぁあのときは泣いたな.
# ごくごく基本的なライブラリがちょこっとと main が1個の CGI を
# 10個修正しているときは.
0019名無しさん＠お腹いっぱい。
NGNGmainが１個のじゃないCGIってのはどーゆーの？
0020名無しさん＠お腹いっぱい。
NGNG0021名無しさん＠お腹いっぱい。
NGNG制御系ならともかく業務系では没です。
破棄です。
0022名無しさん＠お腹いっぱい。
NGNGじゃあ、藤原に訊けばいいのか？（藁
0023名無しさん＠お腹いっぱい。
NGNG後で読むのが面倒だし
といって、切り分けないで関数が長いと
それはそれで読む気失せるし、
適度な切り分けというのは難しい、、、
0024名無しさん＠お腹いっぱい。
NGNGカンベンしてくれ。
早いコーディングしたけりゃ、タイピング速度上げろや。
そもそも、関数化（ライブラリ化）すれば済むことじゃん。
馬鹿なんDeath化？（藁
>>23
難しいですね。
個人的には、自分が３ヶ月前に組み上げたソース読んで、
読みやすいと思えれば、一応ＯＫにしてます。
個人差があるんで、一概にどうこう言えない部分もあると思いますが。
0025>24
NGNG煽るのもいいが、貴方が煽られたいんかい？
手をシコシコする前に、頭で考えてコーディングしなされ。
オナニーでも想像力は大事だおｚ
まあ11のバカさ加減には確かにあきれるが。
>俺は読みやすさよりコピぺしやすさを重視している。
>ライブラリ化しても良いのだが、その場合汎用化の
>ための無だなコードや広範囲のエラーチェックを入
>れにゃならんので、コピぺしてその処理に合うよう
>にちょこっと修正するってパターンだ。
>コピぺの塊なんでコメントなんて無くても何やって
>るか一目瞭然（笑）。
そのうち何をやっているのか何もわからなくなるよ。（ｗ
0026名無しさん＠お腹いっぱい。
NGNGおれのオナニーを馬鹿にしているのか？
0027名無しさん＠お腹いっぱい。
NGNG想像も使いなさい。
君の大好きな2次元キャラが、君にやさしく微笑みかけてくれるのを
ｵｴ~~~
002811
NGNG＞そのうち何をやっているのか何もわからなくなるよ。（ｗ
とりあえず、13年間やってるが、今のところ無いな。
0029名無しさん＠お腹いっぱい。
NGNGバカだから気が付かないだけでしょ。
貴方の後ろに、ほら、貴方を殺したいくらい憎んでいる
人が沢山沢山。
003011
NGNGまぁ、そうかもしれんけど、俺のコピペ集を有難がって
そのまま使ってるヤツらはもっと馬鹿だよな…。
（進歩が無いってのは、確かに言われた事がある）
他部門のプロジェクトの手伝ったら、俺のコピペ使ってたん
で苦笑した事があるよ…。
コピペって書くから変なのかな？定型処理のテンプレート集
って言った方がいいか？
SDKでWindowsのGUIアプリ作る時なんて、似たような事ばか
り書くじゃん？そんなのをコピペで済ます。
（上で書いた失笑したヤツはUNIXのコードだけど）
で、最初に戻るけど、コメントも書いてないコピペ集の内
容しらんヤツまで使ってるんだから可読性は高いのかもな。
って、なんか負け惜しみ書いてるみたいでやっぱ俺が馬鹿
って事で。
003111
NGNG＞コメントも書いてないコピペ集の内容しらんヤツ
＞まで使ってるんだから可読性は高いのかもな。
コメントも書いてないコピペ集を、俺と面識ないヤツ
でも使ってるんだから…
0032名無しさん＠お腹いっぱい。
NGNG11さんが、コメント書きがんばれば、
周りの生産性はもっとあがるよ。
しかし、周りにいるめぼしい奴をちっとは教育してあげなよ。
0033名無しさん＠お腹いっぱい。
NGNGつーか、そこまで活用されうるものならきちんと関数ライブラリ化した方がいいんでないかな？
0034名無しさん＠お腹いっぱい。
NGNGそれだけ使いまわせるようなテンプレートなら
専用の作ってしまったほうが使いまわし楽じゃないかと思う。
仕様が知りたければそこだけ参照すればわかるわけだし。
分身やその類似品が増え過ぎるとなんか落ち着かない気がする。
0035名無しさん＠お腹いっぱい。
NGNGものなら、だれも使えなくなるに３００トラール。
003611
NGNGにするのがアホらしいのと、最初にも書いたが、ライブラリ化
するほと汎用化した場合、エラーチェックがかなり増える。
処理本体の何倍もエラーチェックが存在する。これ自体は当た
り前なんだけど、処理の使われ方によっては絶対発生しない
エラー条件があるだろう。その時の無駄がイヤ。コードサイズ
が大きくなるのは悪夢（これは512バイトのメモリにハンドア
センブルでギチギチ処理積めこんでた過去の後遺症だろう）。
処理本体をコンパクトな形でコピペ集にしといて、利用時に
その場合場合に適応するエラー処理を追加するのが軽くて良
いんだな。プロトタイプ時はエラー処理書かない事も多い。
俺は、エラーの発生し難いデータ構造や処理方式にして、人間
が入力する/したデータのチェックのみ重点的にして、その他は
軽いチェックで済ます。だから、余計にそう思うのだろう。
あと、コメントだけど、コメントが書かれているために読みに
くくなっているソースの何と多い事か（俺の周りだけと思うが）。
それくらいなら、スッキリした処理にコメント無しの方が何倍
も読みやすい。
0037名無しさん＠お腹いっぱい。
NGNGその手があったか。
俺も今まで自分が作ったプログラムを参照して（コピペして）
作ること多いけど、それをまとめて一つのファイルにすること
までは思い付かなかった。
過度に使わなければ便利だと思う。
0038非煽り
NGNGエラーチェックコードを、assertのように #define で無効にできる記述で
書けば良いように思うのですが、それだとなにか問題があるんでしょうか?
0039名無しさん＠お腹いっぱい。
NGNGそのテンプレート集よこせ！
0040名無しさん＠お腹いっぱい。
NGNGそれでいいと思うけど、後でソース見たときパッと見何を
やっているかわからないところが嫌なんじゃない？多分。
ほとんどエラー処理で埋まっちゃうときが多いからねぇ。
004138
NGNGう、うーん、後でソースを見たときにパッと見何をやっているのかを
わかるようにするために、コメントを付ければいいんじゃないかと
思うんですけどねぇ...
ほとんど(assertの)エラー処理で埋まっているコードは、プログラムが
正しく動くための前提条件を綿密に書いてあることと同じなんだから、
望ましいコードだと思います。
コメントで「〜〜でなくてはならない」とかたくさん書いてあったり、
コメントもassertもなくて人知れずバグるより、ぜんぜん生産性の
高いコードだと思うんですが。いかがでしょうか?
004233
NGNG>ライブラリ化しないのは、数行から十数行のモノをライブラリ
>にするのがアホらしいのと、
strcpyやstrlenなんて、２・３行で書けるけどしっかりライブラリになってるよ。
まあ、無駄なエラーチェックを省きたいとか思うならそれはそれでいいと思うけど。
004311
NGNGその辺りの好き嫌いは、もう個人的な問題だよ。
0044133
NGNG＞それくらいなら、スッキリした処理にコメント無しの方が何倍も読みやすい。
もともとコピペしやすさを読みやすさより優先してる話でなかったっけ？
004544
NGNG４４は >43 ね
004611
NGNG何よりも優先してるワケじゃないが、その通り。
って言うか、自然に書いてもコピペしやすいコー
ドになる。
んで、コメントも書いてないようなそのソース
を俺とほとんど面識無いヤツが何の処理に使え
るモノだが理解して使ってるなら、可読性も高
いかもねってのも書いた。ま、一緒に仕事した
事あるヤツが「これコピペして楽しなよ」って
紹介しただけかもしれん。
004738
NGNGたしかに「みやすい」「わかりやすい」は個人的な問題になっちゃいますねぇ。
この手の議論は対象分野や作業環境によって望ましい答えはかわるしね。
いちおう立場を表明しておくと、いままでの自分の経験からすると、
assertなどのエラーチェックが入った分だけ長いプログラム片のほうが、
エラーチェックが入っていない分 短いプログラムより、バグの早期発見につながり、
生産性が高い。
と思ってます。
11さんのようなスタイルで上手くいっている例を周囲で見たことがなかったので、
新鮮でした。ノウハウ提供感謝>11。
0048オレ様ちゃん
NGNGそしたらそのままコピペされた。
変数名変えないでそのまま使おうとして動かなくて永遠悩んでいた。
超ブルーになりました・・・
0049名無しさん＠お腹いっぱい。
NGNGここでいうライブラリをオブジェクト指向で書かないのですか？
クラスにすればコードの長さやエラーチェックの多さは
解決できないけど汎用性は簡単に解決できるのでは？
もちろん場合によりますが。
0050名無しさん＠お腹いっぱい。
NGNGきっと作った人は、とても頭が良いんだなと
思うことにしてます。
頭良くなきゃ、そんなコード、バグが取りきれない。
＃実際はバグってるんだけど。
0051名無しさん＠お腹いっぱい
NGNG出来ません。読み易く長いプログラムが書けるようになるにはどうすれば良いでしょうか？
0052名無しさん＠お腹いっぱい。
NGNGコマギレにする。
0053名無しさん＠お腹いっぱい。
NGNG0054名無しさん＠お腹いっぱい。
NGNG短いプログラムを積み重ねると長いプログラムになります。
行当りいくらの仕事をしているのでなければ、無駄に長くする必要はありません。
英文と同じで読んだり書いたりを繰り返せばそのうちできるようになります。
可読性に関してはコーディングスタイルについて調べましょう。
0055名無しさん＠お腹いっぱい。
NGNGいや、きっと51の人は関数内の行数が長いものでなく規模の
でかいプログラムのことをいっているんだと思います。
>51
基本は54の人が言うとおり短いプログラムの塊が
長いプログラムなのですが、全体を通して、プログラムを見るときは
そのプログラムの設計思想みたいなものを見抜かないと
まず、読めないと思います。これはプログラムの腕というよりは
そのプログラムの内容（概念）を理解しているかどうかが問題
なので、それはそれで勉強しなければなりません。
そんなこんなでみんなが読みやすいようにしようじゃないかと
生まれたのがオブジェクト指向とかだったりします。
たしか・・・。
005651
NGNG>54
やはり沢山のプログラムを読むのがよいのでしょうか。やってみます。
コーディングスタイルについてはK&Rを見習えばいいと、どこかのHPにあった
のですが、それで良いのでしょうか？確かに見易いとは思うのですが・・・
>51
おっしゃる通り、"短いプログラムの塊”は読むことが出来るのですが、
"プログラムの設計思想”を見抜いたり、全体を通してプログラムを見る
といった事が出来ていないと思います。しかし、書店にある言語の本や、学校では
その言語の文法や、データ構造、単純なアルゴリズムしか学ぶことが出来ません。
前に一度、ダイクストラの『構造化プログラミング』を読んでみたのですが、
途中で挫折してしまいました。そこでプログラムの設計方法を学ぶことの出来る
お勧めの良い本があれば教えて下さい。
005754
NGNG設計の話だとは思ったのですが、
そっちは（も）説明できる自信がなかったのでスタイルの話に持ってっちゃいました。。。
>>56
構造化設計についてきちんと書いてある実践的な本ってありますかねー。
オブジェクト指向について学んだ方が良いかもしれません。
オブジェクト指向設計はJavaの雑誌なんかでも特集されてたりするので、
参照できる資料は多いと思います。
まーオブジェクト指向で設計できるようになれば構造化もできるようになるでしょう。
C言語なら、出来の良いライブラリのソースを読むと良いですね。
ある目的を達成するためにどういうインタフェイス・機能を提供していて、
それらは実際にどう実装されているのか、
と全体から細部へとトップダウン的にプログラムを把握できます。
UNIX方面のオープンソースなライブラリを適当に探してみてください。
0058名無しさん＠お腹いっぱい。
NGNG結構いろんなところでお勧めに挙げられている本なので安心です。
私も読みましたがめちゃくちゃいいです。
『憂鬱なプログラマのためのオブジェクト指向開発講座』
Tucker! 著
翔泳社
0059名無しさん＠お腹いっぱい。
NGNG0060名無しさん＠お腹いっぱい。
NGNGGCCの拡張を使うのはどう？
switch ( value )
{
case 0 ... 10 :
case 'a' ... 'z' :
}
など。
http://duff.kuicr.kyoto-u.ac.jp/~okuji/guide.html
0061>59
NGNGあんまりテンコモリ言語だと他人のコードが読めなくなるし
色々実装時に悩むように思うがどうだろか？
0062名無しさん＠お腹いっぱい。
NGNG>生まれたのがオブジェクト指向とかだったりします。
>たしか・・・。
ちがいます。それなら構造化だけで十分。
構造化に比べて
理解しにくいオブジェクト指向が読みやすいわけがない。
階層が10段階も深くなったらどのメソッドが動いているか
把握するだけで大変。
オブジェクト指向はプログラムの再利用性と
多くのメモリを扱う時の高速性のために作られただけです。
0063名無しさん＠お腹いっぱい。
NGNG> 構造化に比べて
> 理解しにくいオブジェクト指向が読みやすいわけがない。
データとアルゴリズムは一緒にした方が解りやすいと思いますが？
あなたはオブジェクト指向の何処が理解しにくいと思ったのでしょうか？
>階層が10段階も深くなったらどのメソッドが動いているか
>把握するだけで大変。
これは構造化でも大きくなったら管理は大変だと思います
>オブジェクト指向はプログラムの再利用性と
これには同意します（他にもいろいろメリットはありますが）
>多くのメモリを扱う時の高速性のために作られただけです。
？？？
ちょっと意味が分かりません
006463
NGNG構造化を理解していない人が無理に構造化したプログラムはわかりにくく、
逆に構造化などせずにだらだら書いてくれたほうがありがたい気がします
例えば
・機能分割でなく行数で分割されている
・１つのモジュールで複数の関係ない機能を行わせている
・グローバル変数を多用している
オブジェクト指向を正しく理解し、正しく設計を行えば
構造化と同じくらい読みやすいか
構造化よりも読みやすいプログラムになると主張します。
# 全てをオブジェクトで表現できると信じるのもイヤだが
006562
NGNG>データとアルゴリズムは一緒にした方が解りやすいと思いますが？
そーだった。
データがメソッドを持つのはオブジェクト指向のメリット。
忘れてました。
でも、それは理解しているからメリットだってわかるのであって
実際、オブジェクト指向がなんだか難しいってイメージが
定着してません？
自分で言っててなんだが
構造化だって世の中できてない人多いから、どっちもどっちか。
>オブジェクト指向を正しく理解し、正しく設計を行えば
>構造化と同じくらい読みやすいか
>構造化よりも読みやすいプログラムになると主張します。
賛成だけど、
結局、鶏が先卵先の問題だったな....
読みやすさのために成立したわけじゃないが
成立しちゃって読みやすい書き方は当然出来るって事。
オブジェ指向でも読みにくくは書けるし。
>>多くのメモリを扱う時の高速性のために作られただけです。
>？？？
ん？結局ポインタ参照でしょ。
オブジェクトをわざわざ作成するじゃない。
変数と同じように宣言しただけで
実態が存在してしまったら、超低速になるから
作られたようなもんですよ。＞オブジェ指向
#また突っ込まれるだろうな。ウケケ
0066名無しさん＠お腹いっぱい。
NGNG> データがメソッドを持つのはオブジェクト指向のメリット。
それだけならオブジェクト指向以前の
「データ抽象/抽象データ型」のレベル。
> ん？結局ポインタ参照でしょ。
> オブジェクトをわざわざ作成するじゃない。
> 変数と同じように宣言しただけで
> 実態が存在してしまったら、超低速になるから
> 作られたようなもんですよ。＞オブジェ指向
これは参照カウントやコピー・オン・ライトのような技法を
使って、可能な限り実体を共有することによりメモリをけちる
というような話か？
どうしても「そういうことにしたい」のならソースを示せ。
006763
NGNG> 実際、オブジェクト指向がなんだか難しいってイメージが
> 定着してません？
> 自分で言っててなんだが
> 構造化だって世の中できてない人多いから、どっちもどっちか。
ええ、なんかそういう風潮があるのは認めます。
構造化のメリットを理解できない人はオブジェクト指向のメリットを
理解できるはずがありません。
また、構造化のメリットを理解できていても、オブジェクト指向的な
考え方を理解していないとおかしな設計になってしまいがちです。
が、大きなプログラムを解りやすく作ろうとしたら
オブジェクト指向的な考え方になると思います。
例えばCのファイル操作ライブラリなどは
データを抽象化して、そのデータを操るメソッドを実装していたりして
けっこうオブジェクト指向的だと思っています。
> ん？結局ポインタ参照でしょ。
> オブジェクトをわざわざ作成するじゃない。
> 変数と同じように宣言しただけで
> 実態が存在してしまったら、超低速になるから
> 作られたようなもんですよ。＞オブジェ指向
うーん、それはオブジェクトの実装方法の話ですよね？
多くの場合はそうかもしれませんが、もっと効率のよい方法が
発見されたら別の方法になるかもしれませんし、
あまり、オブジェクト指向の本質でないような気がします。
0068名無しさん＠お腹いっぱい。
NGNGってあったから、それは違うよって事が言いたかったの。
俺の[構造化で十分]っていうのも言い過ぎか。
でも、高速性を追求しなければたぶん世の中構造化だけでも
うまくいっていたと思われる。
ま、本質か実装かって話になるけど、どっちも切り離せないよ。
実際、すばらしい性能を発揮する
ニューロコンピュとか出来てしまったら
プログラミングの手法がまったく異なってしまうかもしれない(Lispとか？)
そして、それに適合した理論体系でコーディングしやすい
○○指向が生み出されるって事になるんだろう。
違う？
そういえば、オブジェクト指向のその次の理論とかは
成立してるのかな。
大学でオブジェ指向を研究している人もいるわけだし、
006951
NGNG有難うございます。『憂鬱な〜』さっそく読んでみます。ところで58さんはいつ頃
この本を読んだのですか？自分はまだ、Ｃ++の文法を一通りやってみただけで、
この手の「文法」の本ではなく「オブジェクト指向」の本を読むのは初めてです。
もう少しＣ++のプログラミング(MFC等を使ってみる）をやる方が良いでしょうか。
>>オブジェクト指向で設計できるようになれば構造化もできるようになるでしょう
という事は、構造化プログラミングを経ずに、いきなりOOPに入っても差し支えないと
いう事でしょうか？
>>67
>>構造化のメリットを理解できない人はオブジェクト指向のメリットを
理解できるはずがありません。
これは上の意見とは違うみたいですね。やはり構造化プログラミング→OOPと
進むのが良いのでしょうか。67さんの意見をお願い致します。
007067
NGNG>> 構造化のメリットを理解できない人はオブジェクト指向のメリットを
>> 理解できるはずがありません。
> 構造化プログラミング→OOPと進むのが良いのでしょうか。
まず、「構造化」と略してしまいましだが私が「構造化」と言っていたのは
「構造化設計」いわゆる「モジュール化」と呼ばれているものです。
「構造化プログラミング」と「構造化設計」は別物です。
例えるとするとOOP＠｀構造化設計は「戦略」で、
構造化プログラミングは「戦術」です
私は、OOPのサブセットが構造化設計の考え方と思っているので
OOPの考え方がわかれば、構造化設計の意味することも
理解できると思うので、構造化設計は学ぶ必要はないと思います。
最後に引用が前後してしまいますが
> もう少しＣ++のプログラミング(MFC等を使ってみる）
> をやる方が良いでしょうか。
> 自分はまだ、Ｃ++の文法を一通りやってみただけ
> 「オブジェクト指向」の本を読むのは初めてです。
この段階だと「OOPのメリット」を感じることは難しいと感じます
OOPは大きいプログラムで威力を発揮します
まずは、C++を自由に使いこなせるようになるようになった方が
良いように思います
0071名無しさん＠お腹いっぱい。
NGNG場合がほとんどなんだからgotoの代わりにこれ使いましょう、ってものだと
思ったが。
あとグローバル変数使うなとか、関数の出口はひとつにしよう（これはまったく
守られてないが）とか。
0072名無しさん＠お腹いっぱい。
NGNG＞ところで58さんはいつ頃 この本を読んだのですか？
C++の文法も知らないときです。この業界は後からくる人の方が圧倒的に
有利になっているようです。構造化プログラムは知らなくてもさほど問題はないでしょう。
いつ頃かというとC言語を覚えてから設計について悩むようになってからです。
C++はこの本から少し学んで、次に入門書を読みました。
私が思ったのはC++ははじめに入門書を触ってはいけません。
はじめにオブジェクト指向を覚えてから、C++を覚えないと駄目です。
それはC++がプログラムでオブジェクト指向を表現するための
手段として作られたからだと思います。たぶん・・・（またかい）
0073名無しさん＠お腹いっぱい。
NGNG＞この段階だと「OOPのメリット」を感じることは難しいと感じます
＞OOPは大きいプログラムで威力を発揮します
Javaでクラスライブラリ便利ー、OO万歳ってのは？
特にAWT/Swing使っているとOOの恩恵を感じる。
C++でオブジェクト指向を学ぶのは大変なので、
Javaで覚えた方が吉だと思ふ。経験的に。
0074名無しさん＠お腹いっぱい。
NGNG0075名無しさん＠お腹いっぱい。
NGNGRubyとかSmalltalkとかかな。。。
でもSmalltalkはなじめなかった。
そんなわけでObjective-Cをおすすめするよ。
0076名無しさん＠お腹いっぱい。
NGNGSmalltalkは制御文までオブジェクトという画期的さに負けたなあ。
最近「じゅん」がSmalltalk製と知って驚いたよ。
0077名無しさん＠お腹いっぱい。
NGNG0078名無しさん＠お腹いっぱい。
NGNG感じじゃないんだよね。
if文のかわりに True、False クラスに ifTrue:aBlock とかが定義してあって、
TrueクラスのifTrue:aBlock は、単に ↑aBlock value. としか書いてないし、
FalseクラスのifTrue:aBlockは、なんにもなしとかね。
0079>76
NGNG出ていましたよ。
008051
NGNG73さんは文章からC++→Javaという順番にプログラムを経験されて
オブジェクト指向を学ぶ時に、"Javaの方が吉"と考えておられる様ですが、
JavaがC++よりどの様な点でOOを学ぶのに優れているか73さんの意見を
聞いてみたいのですが如何でしょうか？自分のわずかな知識では、Javaの
C++よりも良い点は、ポインタや多重継承が無いのでオブジェクト指向に専念
できる、といった事しか思い浮かびません。
0081名無しさん＠お腹いっぱい。
NGNG個人的な見方だけど、
初心者にとって敷居が低く、参考になる資料が多いという点かな。
まず、初心者が比較的楽に試せる。
処理系がSunのJDKくらいしかなくて迷わずに済むこととフリーであること。
BCCなどのフリーのC++処理系でGUIプログラムを作るのは大変だが、
Javaならメモ帳一つでSwing使ったGUIプログラムもすぐ作れる。
＞ポインタや多重継承が無いのでオブジェクト指向に専念できる
加えて
・GC
・一ファイル一クラスでファイル名=クラス名
・整理された標準API群
・一応MVCアーキテクチャなGUIツールキット
とまあリファレンスからAPI探して並べるだけでごく簡単なアプリなら事足りる
というのは敷居が低くてよろしいと思うわけです。
で、C++でオブジェクト指向という話題よりも、
Javaでオブジェクト指向という話題の方が、
本にせよウェブページにせよ参考になる資料が多い（と思ふ）。
■ このスレッドは過去ログ倉庫に格納されています