アカウント名:
パスワード:
オブジェクト指向というか, 言語を含めたソフトウェア開発技術が役に立たないのは, 現実のボリュームゾーンのプログラマの能力を過剰に高く設定しているからじゃないかと思います. おそらくは
というのを, 現実のプログラマのレベルとして想定しておかなければならないのでしょう. FizzBuzz問題並みに低レベルだとは私も思うのですが, 最長不倒関数が作成される, ポインタの様なちょっとばかりイマジナリなデータにつまづく人が多い, クラスのメンバを全てpublicにしようとしたり, または個々のメンバ毎にアクセスメソッドを設けようとしたりする, ローカル変数を外部からアクセスできない不便な変数とみなす等々の傍証からすると, それほど間違っていないのではないかと.
このレベルを前提にしてオブジェクト指向とかを考えてみると, 役に立たないのも当然のような.
疑問に思われるのも当然ですが, 多くの業務プログラムの開発現場では, このレベルの(いわゆる)プログラマが全体の7~8割を占めていると, 個人的には感じます.
ただ同時に, 業務プログラムではほとんどの場合, 単純な四則演算, 転記, 簡単な条件判断で済むことが多いため, 馬脚を現すことがありません. でも, 実際にソースを読んでみるとコピペの塊だったりするので, どういう思考パターンでコーディングしたのかということが推測出来ます.
1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。1クラス1000行のプログラムは、見たことがある。
上流や、マネージャ/チーフアーキテクトがオブジェクト指向、わかってないんだろうねぇ。私は・・・わかっている範囲で使っています(こういう奴が、一番チーフアーキテクトになってはいけない)。
iPhoneアプリがらみでObjective-C勉強していますが・・・まだまだ修行の身ですね、オブジェクト指向。
5年くらい前、サーフレットクラス一個当たりのソースコードが8000~12000行くらいあるWebアプリケーションの保守に関わっていました。
私が主に担当したのが、全体12000行のうち10000行をdoPostメソッドが占めていて、古いコードはコメント化、ロジック的(全くロジカルでないけど)にはサブルーチンと言う概念すら無い状態でした。
最初からクソな状態で書かれていたアプリケーションの保守を営業が取ってきたものでしたが、オブジェクト指向の理解以前に論理的思考能力が怪しい感じがします。
# メソッドが10000行にもなると、ローカル変数がグローバル変数のようになったり、
それ、どうやっても別クラスにできないんでしょうか…一個30行の30個ぐらいには分割できそう。まあ、それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
>それ、どうやっても別クラスにできないんでしょうか…
動いていたりすると、それが「動いているモノには触るな」「触るにしても最小限」みたいな鉄則が出来ていたりしますね。でもって、そういったソースがおかしいとか、コードレビューとかちゃんとやっていないと、終盤土壇場でみつかったりして、「終盤まで動いていたから」みたいな言い訳が実績として前述の鉄則がでてきちゃったりする。
>それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
再利用するためもあるけど、可読性のためにも、それが可能であれば、そうするべきだと思います。が、前述の鉄則に阻まれることがあります。また、運用系のエンジニアやPMクラスが阻むこともありますね。
>それ、どうやっても別クラスにできないんでしょうか…いいから黙って言われた事だけやるんだ
それ、どうやっても別クラスにできないんでしょうか…
技術的にはできるでしょう。やらない理由の大半は政治的理由ですよ。
Q1.コードが長いからクラス/メソッド分割しようよA1.クラス設計書/関数I/F仕様書が増えるからダメ
Q2.(C開発で)1つのファイルにコード全部書くと見づらいからファイル分割しようよA2.開発規約で「Cソース:ヘッダファイル:実行ファイル=1:1:1」と決まっているからダメ
たしかに大幅に少なかったかもしれません;;数は本当に適当です。エディタで30行を見直してみて、これは小さすぎるなと思いました。要は分割できそうといいたかっただけなので、30行はいらぬ発言でしたね。まあ、コメントや宣言などを除いた実コードで、>#昔1メソッド一画面(24行)は目安というのはすごく参考にすべき目安だと思いました。
まあ、コメントや宣言などを除いた実コードで、 <#昔1メソッド一画面(24行)は目安 というのはすごく参考にすべき目安だと思いました。
Java だとどうかなっていうのはありますが、今だと「実コードで」ではなく「処理本体で」かな、という感じでしょうか。 パラメーターチェックだけでなく、離脱時 (return や例外のスロー) での終了におけるオブジェクトの状態チェックや戻り値のオブジェクトに対する検証処理なども含めると、ちょっと「一メソッド一画面」は無理がありますから。
1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。
後先考えずにコピペしてれば、それくらい逝くのでは。 保守性なんて知らん。最後にclassで括ればグローバル変数じゃないでしょ。 …そんな考えで書き殴られたと仮定しないと、目の前の現実がありえません。夢なら覚めてくれ。
あぁ、それは夢だよ。後先考えるどころか、それ以外の書き方を知らない連中が多いのが現実。
オブジェクト指向以前の話なんだけど、
昔Windows3.1でMSC5だったかな?のころ、職場の先輩に「コンパイルできんのだけど」と言われて見たら、ソースファイルがでかすぎてメモリ不足になっていた。分割コンパイルにすればいいじゃん、と思って関数毎にファイル分けしようと思ったら全てmain関数でした。何千行あったんだったかな?
玉手箱を開けた気分でしたよ。
gccであることをいいことに、Cでも//でコメントアウトしてます。ごめんなさい(懺悔)
C99ならやってもいいのよ。
投稿順に表示するとこっちのほうが早いのに既出かよ…。まぁ同時時間だから区別つかないんだろうけどこんなところに無駄にモデレーションポイント使わなくても。マイナスにするよりプラスに使おうぜプラスに。
コメントのナンバーで見てもこっちが先だよねえ。
ACのウジ虫どもが偉そうに書き込むんじゃねえよという意図のモデレーションなら、せめて「荒らし」とかだろうに。
(* 昔風にコメントアウトすればいいんじゃなイカ? *)
C99で//はコメント開始と規定されていますので問題なし!
# でも真面目な話、2011年現在で//から始まるコメントはCでないと言っちゃうのは勉強不足かと・・・# コンパイラの実装とは別にCもC++も規格は変化(進化とも退化ともいわん)していってますので。
>C99もC89の上位互換だけど
違います。例えば、
printf("%d\n", 10 //* 2 */ 2);
は、C99でもC89でも正しい構文だけど、結果は異なりますよね。
けど、いくらC99なら使えるっていっても、Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
試しに領域を確保して開放するだけの関数と、可変長配列を確保するだけの関数を作って一千万回まわすと
可変長配列: 0.210000(秒)malloc: 76.670000(秒)
速度が要求されるんで最近は可変長配列ばっかり使ってるけどwindowsでは使えないらしい。実際はmalloc一千万回する人なんて居ないか。でもpowを数百万回まわす人は居たな。テーブルに置き換えたら恐ろしく早くなった。
#変数宣言の場所がめちゃくちゃになってきたらもう終わりだとおもう。orz
どちらかというと、可変長配列はallocaの代替ですから、なんでもかんでもmalloc/callocの代わりに可変長配列できるとは限りません。ある程度大きな領域の確保には依然としてmalloc/callocその他が必要です。
あと一応、Windowsで可変長配列が使えないのではなく、MSVCやBCCがC99対応していないだけなので、GCCならWindowsだろうがなんだろうが可変長配列使えます(Intelのはどうだったかな?)。
> MSVCやBCCがC99対応していないBCCの場合、デフォルトオフですけどC99に対応 [embarcadero.com]してますよ。以下、C++ Builder 2009 のコマンドラインヘルプ。
% bcc32 -h -ACodeGear C++ 6.10 for Win32 Copyright (c) 1993-2008 CodeGear使用できるオプション (* はデフォルトの設定。xxx はサブオプションで、-h -X などで表示) : (メモ: -X- または -w-XXX は、通常、-X による設定または設定解除を取り消します)(略) -An C99 準拠のキーワードと拡張を使用します -Ax C++-0x 準拠のキーワードと拡張を使用します
なお、C+ Builder 6(2002) では非対応でした。C++ Builder 2007 は未確認。
デフォルトでオフになってるのは、既存のコード(大半がC89レベル)との互換性の問題からでしょうか。
そういえば、かつてVisualC++のC++も、長らく変数のスコープが非標準(「for(int i = 0; i < n; i++){}」といった変数宣言がループ後も有効なまま)という問題があり [noppi.jp]、MFCなどのライブラリが非準拠な仕様に依存してるからこっちがデフォルトなままだという噂でしたけど、今では(2005=VC8以降)ちゃんと標準準拠 [microsoft.com]になってますね。
>> # でも真面目な話、2011年現在で//から始まるコメントはCでないと言っちゃうのは勉強不足かと・・・
「勉強不足」という意味ではそうかもしれないけど,前提条件無しで「//はCでコメントとして使える」と思っちゃう方が問題あるような気がするけどね.いくら「C99では使える」って言ったって,自分が使ってないコンパイラはどのバージョンからC99対応なのかなんて知らないし.
>> # でも真面目な話、2011年現在で//から始まるコメントはCでないと言っちゃうのは勉強不足かと・・・「勉強不足」という意味ではそうかもしれないけど,前提条件無しで「//はCでコメントとして使える」と思っちゃう方が問題あるような気がするけどね.いくら「C99では使える」って言ったって,自分が使ってないコンパイラはどのバージョンからC99対応なのかなんて知らないし.
例えば、関数プロトタイプは元々C++で導入された宣言方式で、それがC89でC言語に逆輸入されました。それを、それこそ10年ぐらい前の時点でも、K&Rを想定して「関数プロトタイプを使ってるのはCではない」とか言っちゃったらもうダメでしょう。
同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
>> 同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
そうやって「そろそろ~なんて古いものは捨てようぜ」で捨てられるなら,COBOLのコードなんてとっくに絶滅してるはずじゃないの?
UMLよりテキスト表示できるCOBOLのほうが表現しやすいことがある。COBOLで仕様書書いて、C++で実装してますが、何か?
>同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
言語仕様を捨てて良いかどうかは、コンパイラやその他のツール、ライブラリやフレームワークの対応具合で決まる。
cppすげ替えれば、どの言語でも使えますが何か?
私がある現場で見たC++の「オブジェクト指向」1. 既存のCモジュールを全部 class XX { ~ } で囲む2. そうして作った全部のクラスを public で継承するクラスを作る仮想関数は一切なし。何がしたいのか理解するまでにずいぶん時間がかかりました。
class XXX {public: char* p; void setstr(char* str) { strcpy(p, str); }}
こんな自称 C++ マスターのコードなら。その人のコードで private/protected は見た記憶がないですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
どこまでが笑い話・都市伝説なのか… (スコア:1, 興味深い)
究極的には 「// でコメントアウトできる C」みたいな…
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
青い鳥を探すように、「オブジェクト指向」を実現する何かが存在すると信じて、
当所もなく、幻想を求めて旅を続けるのです。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
オブジェクト指向というか, 言語を含めたソフトウェア開発技術が役に立たないのは, 現実のボリュームゾーンのプログラマの能力を過剰に高く設定しているからじゃないかと思います. おそらくは
というのを, 現実のプログラマのレベルとして想定しておかなければならないのでしょう. FizzBuzz問題並みに低レベルだとは私も思うのですが, 最長不倒関数が作成される, ポインタの様なちょっとばかりイマジナリなデータにつまづく人が多い, クラスのメンバを全てpublicにしようとしたり, または個々のメンバ毎にアクセスメソッドを設けようとしたりする, ローカル変数を外部からアクセスできない不便な変数とみなす等々の傍証からすると, それほど間違っていないのではないかと.
このレベルを前提にしてオブジェクト指向とかを考えてみると, 役に立たないのも当然のような.
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
現実には3年もタダ飯食わすわけにはいかず、トレーニングに3ヶ月も割いてくれれば御の字。
そんな訓練不十分な奴らを使っていかに戦い抜くかを考えるとオブジェクト指向の適用はなかなか難しいですね。
# 3年というのはデザインパターン出現前の話なので今だともっと短縮できるでしょうが、結局デザインパターンをマスターするのが前提。
# はたしてデザインパターンをきっちり読破するような勉強熱心なのがどれほどいるやら・・・
あと、業務プログラムの場合、難しい部分はごく一部で大半はIDEが自動生成したClickイベントのテンプレートに処理を書き込んでいくだけで済むことが多くて、そういう簡単な部分ばかり任されてるとメソッド宣言を自分で書いたことのない奴とか普通にいる。
そいつらに「処理を分けろ」と言ってもメソッドを自分で宣言する行為の敷居が高いのでなかなか実践してくれないし、分けたとしても慣れてないやつは処理の切り出し方が下手なので再利用性が低く可読性も低いコード片をソース中にまき散らすことになり
「こんな読みにくくなるだけのことをするんならベタに書いたほうがずっとマシ」
という結論に落ち着いてしまう。
# そこで誰かが根気強くフォローする環境であればいいんだけどね
# 現実にはどこの職場でも有能なやつほど暇ではない
Re: (スコア:0)
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
疑問に思われるのも当然ですが, 多くの業務プログラムの開発現場では, このレベルの(いわゆる)プログラマが全体の7~8割を占めていると, 個人的には感じます.
ただ同時に, 業務プログラムではほとんどの場合, 単純な四則演算, 転記, 簡単な条件判断で済むことが多いため, 馬脚を現すことがありません. でも, 実際にソースを読んでみるとコピペの塊だったりするので, どういう思考パターンでコーディングしたのかということが推測出来ます.
Re: (スコア:0)
言ってもじもじしているうちに、ハード屋(?)が「面倒くせえなぁ、環境
丸ごと再現してやる」と仮想化技術が使えるものになってしまった
のが皮肉です。
つたないソフトの怪しいローカル仕様を個別に継承するより、比較的
動作仕様が明確なので考えてみれば当たり前なんですけどね。
CPUの高速化・メモリの肥大化の恩恵ではありますが。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。
1クラス1000行のプログラムは、見たことがある。
上流や、マネージャ/チーフアーキテクトがオブジェクト指向、わかってないんだろうねぇ。
私は・・・わかっている範囲で使っています(こういう奴が、一番チーフアーキテクトになってはいけない)。
iPhoneアプリがらみでObjective-C勉強していますが・・・まだまだ修行の身ですね、オブジェクト指向。
-- gonta --
"May Macintosh be with you"
Re: (スコア:0)
5年くらい前、サーフレットクラス一個当たりのソースコードが8000~12000行くらいある
Webアプリケーションの保守に関わっていました。
私が主に担当したのが、全体12000行のうち10000行をdoPostメソッドが占めていて、
古いコードはコメント化、ロジック的(全くロジカルでないけど)にはサブルーチンと言う
概念すら無い状態でした。
最初からクソな状態で書かれていたアプリケーションの保守を営業が取ってきたもの
でしたが、オブジェクト指向の理解以前に論理的思考能力が怪しい感じがします。
# メソッドが10000行にもなると、ローカル変数がグローバル変数のようになったり、
Re: (スコア:0)
基底クラス、インターフェース、実装に別けてても。
C++のように多重継承がないから理解しやすいですし、
javaにはjavadocという物もありますしね。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
それ、どうやっても別クラスにできないんでしょうか…
一個30行の30個ぐらいには分割できそう。
まあ、それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, 興味深い)
>それ、どうやっても別クラスにできないんでしょうか…
動いていたりすると、それが「動いているモノには触るな」
「触るにしても最小限」みたいな鉄則が出来ていたりしますね。
でもって、そういったソースがおかしいとか、コードレビューとか
ちゃんとやっていないと、終盤土壇場でみつかったりして、「終盤
まで動いていたから」みたいな言い訳が実績として前述の鉄則がでてきちゃったりする。
>それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
再利用するためもあるけど、可読性のためにも、それが可能であれば、
そうするべきだと思います。が、前述の鉄則に阻まれることがあります。
また、運用系のエンジニアやPMクラスが阻むこともありますね。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, おもしろおかしい)
>それ、どうやっても別クラスにできないんでしょうか…
いいから黙って言われた事だけやるんだ
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, すばらしい洞察)
技術的にはできるでしょう。
やらない理由の大半は政治的理由ですよ。
Q1.コードが長いからクラス/メソッド分割しようよ
A1.クラス設計書/関数I/F仕様書が増えるからダメ
Q2.(C開発で)1つのファイルにコード全部書くと見づらいからファイル分割しようよ
A2.開発規約で「Cソース:ヘッダファイル:実行ファイル=1:1:1」と決まっているからダメ
Re: (スコア:0)
1クラス30行だと単純なメソッド数個くらいしかクラスに入れられそうに無いんですが。
複雑な処理だと一つ入れるのも大変そう。
#昔1メソッド一画面(24行)は目安にしてたけど、1クラス1画面は目安にしたこと無いなぁ。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
たしかに大幅に少なかったかもしれません;;数は本当に適当です。
エディタで30行を見直してみて、これは小さすぎるなと思いました。
要は分割できそうといいたかっただけなので、30行はいらぬ発言でしたね。
まあ、コメントや宣言などを除いた実コードで、
>#昔1メソッド一画面(24行)は目安
というのはすごく参考にすべき目安だと思いました。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
Java だとどうかなっていうのはありますが、今だと「実コードで」ではなく「処理本体で」かな、という感じでしょうか。
パラメーターチェックだけでなく、離脱時 (return や例外のスロー) での終了におけるオブジェクトの状態チェックや戻り値のオブジェクトに対する検証処理なども含めると、ちょっと「一メソッド一画面」は無理がありますから。
Re: (スコア:0)
まぁ3分の1ぐらいはコメントですけど
Re: (スコア:0)
1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。
後先考えずにコピペしてれば、それくらい逝くのでは。
保守性なんて知らん。最後にclassで括ればグローバル変数じゃないでしょ。
…そんな考えで書き殴られたと仮定しないと、目の前の現実がありえません。夢なら覚めてくれ。
Re: (スコア:0)
あぁ、それは夢だよ。
後先考えるどころか、それ以外の書き方を知らない連中が多いのが現実。
Re: (スコア:0)
オブジェクト指向以前の話なんだけど、
昔Windows3.1でMSC5だったかな?のころ、職場の先輩に「コンパイルできんのだけど」と言われて見たら、ソースファイルがでかすぎてメモリ不足になっていた。
分割コンパイルにすればいいじゃん、と思って関数毎にファイル分けしようと思ったら全てmain関数でした。何千行あったんだったかな?
玉手箱を開けた気分でしたよ。
Re: (スコア:0)
Re: (スコア:0)
gccであることをいいことに、Cでも//でコメントアウトしてます。ごめんなさい(懺悔)
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, 参考になる)
C99ならやってもいいのよ。
Re: (スコア:0)
投稿順に表示するとこっちのほうが早いのに既出かよ…。
まぁ同時時間だから区別つかないんだろうけどこんなところに無駄にモデレーションポイント使わなくても。
マイナスにするよりプラスに使おうぜプラスに。
Re: (スコア:0)
コメントのナンバーで見てもこっちが先だよねえ。
ACのウジ虫どもが偉そうに書き込むんじゃねえよという意図のモデレーションなら、せめて「荒らし」とかだろうに。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, おもしろおかしい)
# {} は嫌い。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
(* 昔風にコメントアウトすればいいんじゃなイカ? *)
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, 既出)
Re: (スコア:0, 既出)
C99で//はコメント開始と規定されていますので問題なし!
# でも真面目な話、2011年現在で//から始まるコメントはCでないと言っちゃうのは勉強不足かと・・・
# コンパイラの実装とは別にCもC++も規格は変化(進化とも退化ともいわん)していってますので。
Re:どこまでが笑い話・都市伝説なのか… (スコア:3, 参考になる)
C++はC99の上位互換ではなく成っちゃうからなぁ
C++はほぼC89の上位互換でC99もC89の上位互換だけど
現在のC++とC99の互換性ってかなりなくなってるよね
struct foo {
int x;
int y;
} hoge = { .x = 0, .y = 1, };
なんてC++では不正な文法になるし
extern void foo( struct foo* p );
の関数に大して
foo( &((struct foo){ 0, 1 }) )
もC++的には不正だし
Re: (スコア:0)
>C99もC89の上位互換だけど
違います。例えば、
printf("%d\n", 10 //* 2 */ 2
);
は、C99でもC89でも正しい構文だけど、結果は異なりますよね。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
けど、いくらC99なら使えるっていっても、Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
1を聞いて0を知れ!
Re:どこまでが笑い話・都市伝説なのか… (スコア:3, 興味深い)
Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
試しに領域を確保して開放するだけの関数と、可変長配列を確保するだけの関数を作って一千万回まわすと
可変長配列: 0.210000(秒)
malloc: 76.670000(秒)
速度が要求されるんで最近は可変長配列ばっかり使ってるけどwindowsでは使えないらしい。
実際はmalloc一千万回する人なんて居ないか。
でもpowを数百万回まわす人は居たな。テーブルに置き換えたら恐ろしく早くなった。
#変数宣言の場所がめちゃくちゃになってきたらもう終わりだとおもう。orz
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
どちらかというと、可変長配列はallocaの代替ですから、なんでもかんでもmalloc/callocの代わりに可変長配列できるとは限りません。ある程度大きな領域の確保には依然としてmalloc/callocその他が必要です。
あと一応、Windowsで可変長配列が使えないのではなく、MSVCやBCCがC99対応していないだけなので、GCCならWindowsだろうがなんだろうが可変長配列使えます(Intelのはどうだったかな?)。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
> MSVCやBCCがC99対応していない
BCCの場合、デフォルトオフですけどC99に対応 [embarcadero.com]してますよ。以下、C++ Builder 2009 のコマンドラインヘルプ。
なお、C+ Builder 6(2002) では非対応でした。C++ Builder 2007 は未確認。
デフォルトでオフになってるのは、既存のコード(大半がC89レベル)との互換性の問題からでしょうか。
そういえば、かつてVisualC++のC++も、長らく変数のスコープが非標準(「for(int i = 0; i < n; i++){}」といった変数宣言がループ後も有効なまま)という問題があり [noppi.jp]、MFCなどのライブラリが非準拠な仕様に依存してるからこっちがデフォルトなままだという噂でしたけど、今では(2005=VC8以降)ちゃんと標準準拠 [microsoft.com]になってますね。
Re: (スコア:0)
>> # でも真面目な話、2011年現在で//から始まるコメントはCでないと言っちゃうのは勉強不足かと・・・
「勉強不足」という意味ではそうかもしれないけど,前提条件無しで「//はCでコメントとして使える」と思っちゃう方が問題あるような気がするけどね.いくら「C99では使える」って言ったって,自分が使ってないコンパイラはどのバージョンからC99対応なのかなんて知らないし.
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, すばらしい洞察)
例えば、関数プロトタイプは元々C++で導入された宣言方式で、それがC89でC言語に逆輸入されました。
それを、それこそ10年ぐらい前の時点でも、K&Rを想定して「関数プロトタイプを使ってるのはCではない」とか言っちゃったらもうダメでしょう。
同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, すばらしい洞察)
>> 同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
そうやって「そろそろ~なんて古いものは捨てようぜ」で捨てられるなら,COBOLのコードなんてとっくに絶滅してるはずじゃないの?
Re: (スコア:0)
UMLよりテキスト表示できるCOBOLのほうが表現しやすいことがある。
COBOLで仕様書書いて、C++で実装してますが、何か?
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
>同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
言語仕様を捨てて良いかどうかは、コンパイラやその他のツール、
ライブラリやフレームワークの対応具合で決まる。
Re: (スコア:0)
cppすげ替えれば、どの言語でも使えますが何か?
Re: (スコア:0)
私がある現場で見たC++の「オブジェクト指向」
1. 既存のCモジュールを全部 class XX { ~ } で囲む
2. そうして作った全部のクラスを public で継承するクラスを作る
仮想関数は一切なし。
何がしたいのか理解するまでにずいぶん時間がかかりました。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
こんな自称 C++ マスターのコードなら。その人のコードで private/protected は見た記憶がないですね。