- - PR -
C++は過去の言語？
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-09-13 09:20
C++ で CGI 作ったら、多分 Perl よりは早いモンが作れるやろ、と。
んで、 Java で苦し紛れの多重継承「もどき」 Interface で急場を凌いどるけど、 C++ には最初から多重継承が許可されとる。 Java が元々ブラウザに特化したもんやのぅて、たまたま流行ってその汎用性を見せ付けたくて Java Plug-in を取り込んだと。これが、別に C++ Plug-in になったらなったで同じ事 できるでしょうな。 OS も作れるし、COBOL の Replace 候補にもなる。。。Java には荷が重いかと。 後、効率の悪さで言うと、プラットフォーム(OS)の差異を埋める為に、絶対 Virtual Machine ていう効率の悪い概念に依存する。 Java 仮想マシンの「最初の立ち上げ」時にはとてつもないコストがかかる。メモリ容量、スループット共。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 11:37
まいるどきゃっと様
> そのライターさんがそういう言い回しが好きなだけなので、あまり深刻にとらえないほうがいいと思います。 ありがとうございます。そうかもしれません。 ただ、私自身少し自信がなかったこともあり、皆さんに確認してみたかったのです。 言い訳にしかなりませんが、ここ５,６年の間私は開発業務のほうが忙しく、 あまり新しい勉強をしてきていなかったため、最近のこの業界の動向についていけてないなぁと感じています。 なんだか、浦島太郎状態といいますか、もう最新技術についていけていない古臭いおじさん技術者な気分です。 ＃自分の専門外だとはいえ、自分の知らない新しい技術がどんどん出てくると、正直焦ります。 > まずは自分が何をしたいのか、何を作りたいのかを探してみてはいかがでしょう？ そうですね。やっぱり今まで通りパッケージソフトや組み込みシステムの分野で設計／開発していきたいです。 囚人様 > 「C++！」「好きだからw」 私も元々はC++（とオブジェクト指向）に惚れ込んで今までやってきた人間でした。自分でも忘れかけてましたが・・ 世の中、Javaや.NETの話題ばかりの中、C++の仲間がいると思うと心強いです。 じゃんぬねっと様 > たとえ、C++ が消えてしまったとしても、そこで培ったものは消えません。 そうですね。新しい技術というのはたいてい既存の技術の延長にあるものですからね。 勇気がでます。ありがとうございます。 > # ところで、C++/CLI はダメですか...? (w う〜ん、勉強不足でよく分からないのですが、C++の.NET拡張版といった感じを受けました。 これから動向を注目しておきたいと思います。でも、組み込み分野にまでは普及しないだろうなぁ・・ コブラ様 > OS も作れるし、COBOL の Replace 候補にもなる。。。Java には荷が重いかと。 そうですね。C/C++にはそういう強力さがありますね。（その分使いにくい部分もありますが） Javaの言語仕様やクラスライブラリは気に入っているのですが・・ あとはJavaアプリがもっとサクサク動いてくれればいいのですけれども。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 12:33
C++/CLIは期待できそうですよ！
OOPLSA Keynote: Concrete Languages on Virtual Platforms (C++/CLI) http://msdn.microsoft.com/visualc/using/multimedia/oopsla/default.aspx _________________ IEEE-CSDP 2004-2007 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 12:46
これがある以上、プログラマ人口全体に占める割合が減ることはあっても、C/C++ 自体が無くなったりすることは当分ないでしょうね。
C++/CLI も、プラットフォームに特化したクライアントアプリケーションの開発のためには、かなり現実的な解を提供しそうで興味深いです。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 12:56
新規開発でC++というのは、無くなるだろうなあ、と思っています。
C++の難易度は、少々嫌がらせじみています。 「書けなくはないが、間違える」という感じでしょうか……プログラマが満足しても、 まとめ役の人がキレます。 速度が必要な部分のみC++にするなら、Cの方が移植性高いんじゃないの、という話になります。 でも新しい言語に挑戦する度に、C++の勉強が役に立っています。過剰と思えるほど、役に立ちました。C++の屍の上を越えていけという感じです。C++代わりにする言語は、何でもよいと思います。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 13:45
どもです。がると申します。
んっと。C++は別に過去でもなんでもないですっていうかまた最近新しく動きなどもあり、十二分に現役です。
ですねぇ。もちろん新しい言語ってのは「C++を含む既存言語の問題点を解消する」意味合いもあって作成されていると思うのですが。 いくつかの点において未だにC++のほうが優位なポイントがあります。 もっともその前に「CのほうがC++よりも優位なポイント」が依然存在するのですが :-P
できるです。自分が普段ちゃんと実証してますから :-P あと、Perl等と違い、メモリ管理などが厳密に出来るので、特に「シビアなパフォーマンスが要求される」環境での性能は段違いですね。 その点ではJavaもNG。もっとも「本気の本気でメモリがかつかつ」だとC++よりもCのほうがさらに楽なケースもあるのですが :-P
んっと…それは管理手法とか開発手法があまりよくないような…。 Tipsレベルの発言をするときりがないのですが。言語としての難易度が…いやまぁ低いとはいいませんが。ただ「職業としてきちんとプログラマをやる」のであれば、C＆C++でメモリ管理くらい真っ当にできなくてどうする？ と思います。個人的には。 で、間違いとその発見については単純に設計手法＆テスト手法の問題なので。C++にあった手法をちゃんと使えば、問題はないと思います。 [quote] 速度が必要な部分のみC++にするなら、Cの方が移植性高いんじゃないの、という話になります。 [quote] 移植性の定義にもよるのですが。 継承するクラスが「容易に使える」点において、C++に一日の長があるとする方は大勢いらっしゃいます(面倒でもいいんならCでもオブジェクト指向でクラス継承とか出来ますが :-P )。 なので、CとC++との判断は、やはり状況によるのではないか、と。 無論、状況判断の結果「Cのほうがよい」可能性も十分にありますが(そういう選択をしたこともありますし)。 以上、雑感をつらつらと。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 14:03
他の Web サービスプロセス組み込み型の手法に比べて CGI が遅いのは、呼び出しのオーバーヘッドがあるからでは？ 一般的な利用用途なら C++ CGI も Perl CGI も速度差はないと思う。もし本当に速度を気にするなら CGI にはしないだろうし。「速い」ではなく「早い」ということであれば、Perl に分がありそうだし。
確かに昔は、多重継承できないことが C++ と比べたときの Java の欠点と言われていたけど。今の評価はだいぶ違います。多重継承を使えないことでシンプルさを保てている、保守性が高いとされています。実際、JComponent をクラスではなくインターフェイスにするべきだった、という声を今でも多く聞きますし。決して、インターフェイスは多重継承の代替や急場凌ぎではありませんよ。Java 開発者は言語仕様が広く機能が豊富であればあるほど良いと考える人ばかりではなく、Java の拡張についても複雑になるから余計な機能は付けるな、と慎重な人が多いのです。ないことが欠点ではなく利点だということですね。
ソースコードを Web 経由で自動ダウンロードして、クライアント側でバイナリしてからコンパイル実行ですか？ それとも BREW のようなプラットフォームをかませる？
COBOL のことは、まったく知らないんですけど、COBOL が業務系で強いのは、任意精度演算ができるからじゃないでしょうか。C++ の float/double では COBOL には到底太刀打ちできません。もちろん、C++ にも任意精度ライブラリ(外部)がいくつかあるわけですが、標準ライブラリでサポートされている Java のほうが分があると思います。というか Java が 第2の COBOL と言われているの聞いたことありませんか？ (揶揄されていることが多いけど。)
Java や .NET のような中間仮想コードを使うプログラムが、コンパイル済みバイナリより遅い・実行効率が悪い、とは必ずしも言えない状況が来ますよ。たとえば、今後 32bit/64bit CPU混在環境になるわけですが、32bit向けコンパイル済みバイナリは 64bit CPU で実行しても 64bit の恩恵を受けられない。中間コードの場合は JVM や .NET フレームワークが 64bit 対応していれば、その場で 64bit ネイティブのコードを生成することができるので、32bit バイナリよりも実行効率が高まることもある。SSE などの拡張命令についても同じ。今後、CPU が多様化していたったときに、それらの機能を十分に使おうと思ったら、特定アーキテクチャ向けに事前コンパイルする方式よりも、中間コード形式の方が有利になります。
私自身は良く分かりませんが…。このあたりが C++ の強みになるようですね。この領域だと C++ のオーバーヘッドを嫌って C で書くという人も多いようですけど。それにしたって、この領域に携わっている人間というのは少数でしょう。 私のような業務系プログラマにとっては、もはや C++ は不要といえます。もちろん、Microsoft の提供する API のインターフェイスが C++ だとか必要があれば使いますけどね。 | ||||||||||||||||||||||||
|
投稿日時: 2005-09-13 14:35
実に面白そうな話題が……（笑
フレームに気をつけつついってみましょう。 私もC++は母国語ですね。いまだに、スクリプト言語的な表現ができるくせにASMレベルのコードがすけて見えるC++独特のtemplateが好きです。 JavaやC#、及びより高級言語のスクリプト言語を学んでる最中にもネイティブなコードを想像できるのはC++で学んだ経験が活きてるからだ、と思っています。 私個人の話をすると、最近、C#やJavaには将来性の点で疑問を感じ始めています。かわりに色々と調べているのはスクリプト言語（Perl/Python/PHP/Ruby/JavaScript）関係ですね。 C#やJavaのようなVM系言語は、性能をある程度犠牲にして生産性を高めていますが、その理屈をより一層推し進めるならば、さらに性能を犠牲にして生産性を高めることを可能にしているスクリプト言語に今後の可能性を感じます。 ただ、いくらマシンの性能が上がっているとはいえ要所要所ではやはり性能が必要でしょう。その時には範囲を限定して、徹底して性能を追及すべきだと思います。そのために適した言語となると、C/C++をおいて他にはないでしょう。 今後どうなるかは分かりませんが、SIベンダーがスクリプト言語をサポートしだしたら、上記のような形でも活躍できるかな、と夢想しております（笑 あと、こんな話題はいかがですか？ http://d.hatena.ne.jp/naoya/20050801/1122886751 GoogleもC++らしいですよ。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。