アカウント名:
パスワード:
ここのサブジェクトを見た時、何ぞおかしな構文をネタにした書き込みかと一瞬思いました。
それはさておき、過去の言語だとか互換性がどうだとか色々言われてるけどそんな言われるほどダメかなぁ？仕様自体は互換性を極力損ねないようにしているし、とはいえ、どこ製のコンパイラによって実装の方法が云々って話はあるけどそれってC++だけの問題なんでしょうか。
一応ここにぶら下げますが、別に誰に対する反論でもないのであくまで私個人の周囲の考え方として参考にしていただければ良い程度の発言です。
私自身はC#に惹かれちゃいましたので、Win系開発はC++終わったかと思っていたんですがMFCが復活の兆しを見せていたり、事実、非常にカスタマイズされた独自UIを持つアプリや速度やメモリ的にクリティカルな(富豪的でない)案件では依然としてVC++の優位性がダントツといった印象です。
一方でAndoroid/iPhoneなど流行りの界隈でも、主流言語こそそれぞれ異なりますがC++はそのどちらでも開発可能だったりしますので非常に重宝します。
Linux系開発も、商用フリーなGUIライブラリとしてのQtがどこまで伸びるか、によってC++の重要性が大きく変わってくるでしょうね。
まあ世の中、Webアプリとクラウドがあれば全てOK的な意味でそれ以外の言語/プラットフォーム全てを「終わった」と表現する方もいますが個人的には、C++はドラゴンボールで言うところの「あともうちょっとだけ続くんじゃ」という頃合いかと思っています。# つまりこれからがむしろ長いってこと
＞Macのメイン開発言語も、Pascal→C→C++(Symantec/CodeWarior)→Objective-Cです。MPWも入れてやってください・・・
別ACですが、
>C++=過去の言語こういうのを見るたびに思うのが、お前がそう思うんならそうなんだろう お前ん中ではな
富豪的プログラミングができる環境しか見ていない人の発言ですね。
おそらく元コメは他の選択肢が無かった時代でしかC++を使用する機会が無かった人という意味で言ったのではないかと思います。
それを自覚したうえで"過去の言語"とするなら、まったく問題ないのですが。
すみません。その段落は蛇足でした。他人様の意見を補足しようなど100年早かったです。
その"Windowsプログラミングしか知らない人"云々の2行を抜いて読んでいただけるとありがたいです。
同じ言語でありながらコンパイラ間ですら互換性なかったり、数年後にはまたもどうなってるか分からない言語機能をプロジェクトで使うこと自体に良識を疑う。まともな会社ならC++を採用してもtemplateだけは使うなとお達しする。
> まともな会社ならC++を採用してもtemplateだけは使うなとお達しする。
実際にC++使ったことある？templateダメだったら、標準ライブラリほとんど使えないじゃん。
まともなプログラマーは、こういうのを「まともな」とかほざくような奴や会社と関わり合いになるなってこと。アメリカ: templateを使うという条件に合わせてメンバーを集めて生産性を向上する。日本: いちばんレベルが低いメンバーに合わせて使用を禁止して、奴隷を安く買い叩く。
> templateダメだったら、標準ライブラリほとんど使えないじゃん。
実際にC++使ったことある？標準ライブラリなんて元からほとんど使えないじゃん。
# まじめに会社のプロジェクトで使ったことなんてないんだろ？せいぜいスクリプトもどき作るぐらいで。# 一番使用率が高いと思われるゲーム業界でも標準ライブラリなんて使ってないって。
まあ、たしかに入出力周りとか全然使う気になれないですし、ほかにもろくなライブラリもなかったですが、string（文字列）、vector（動的配列）、list/forward_list（リンクリスト）、map/unordered_map（連想配列）あたりのクラス（テンプレート）はプロジェクトの性質によらず使えるのではないでしょうか（もちろん、コンパイラ付属の実装が実用に耐えると判断するか否かは別問題として）。
＃ C++の標準ライブラリでテンプレートを使っていないものと言ったら、new/delete（が使うメモリ確保・解放処理をユーザ側で差し替える際に定義する関数）や例外クラスしか残らない気がする。＃ cout/cinも疑似乱数も正規表現もテンプレート、thread/mutexクラスはテンプレートではないけど、ロックやfeatureがやっぱりテンプレート。
C++0xでstring (basic_string)はvector同様に各要素が連続することと決まりました。そのため、Cのライブラリとの相性も少しは良くなったと言えます。
ただし、'\0'終端するわけではないので、basic_stringの要素へのポインタを渡して'\0'終端文字列を受け取るときは、大きめのバッファ（basic_string）で受け取った後、長さ丁度にresizeするなどと、若干の手間が必要になるはずです。それでも、一旦vectorを介すよりは（メモリ面でもコード上でも）手間が減るので良いと思います。
c_str()じゃダメなんですかね。strtokなど、文字列を変更してしまう一部の関数では使えないですけど、それでもvector介すよりはchar型の配列に(C文字列として)コピーして操作したほうが楽な気がします。
一般的にはtemplateを使うでしょう。なぜなら、templateを使うことが一般的(標準)だから。
# プログラムに限らず、手順や手続きの標準化は必要だよ。
ゲーム業界に居た事が無いから実体は知らんが、標準ライブラリは置いておいても、templateは使うんじゃないの？http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]
最近template使っておきながら実装は特殊化されたもののみとかキチ○イじみたコードを見たから禁止したい気持ちはわからなくもないけど、まともに使うならば他の言語には無い強力な機能ですよ。
前にいたゲームメーカーでは禁止はされてませんでした。メモリに優しくねーなーって空気はありましたけれども。それ聞いた時はさすがメモリに厳しい世界だと思いましたが、その反面、よく分からない社外製のミドルウェアを買ってメモリに四苦八苦してるので何が良くて何が悪いかは古株の人の好みでしょう。手段が何であれ最後にフリーズせずに動くマスターを用意できればいいので。
あと、STLに限った話で言えば、自社用のSTLもどきはありました。STLの品質がどうこうじゃなくて、STLが使えない環境用に置いてあったようです。上手に実装できるなら何でもありの世界ですからね。
自分はゲーム業界で開発をしているけど、TemplateなりSTLなりはバリバリ使っている。うまく使えば、コンパイル時にコードを解決できるから効率も良い。Templateが少なくとも読めないとウチのプロジェクトづらい。
# STLはアロケータをカスタマイズして使っていることが多い。
特に海外ではTemplateがよく使われる。物理エンジン系のミドルウェアであるHavokは全面的にTemplateを採用しているし、海外大手であるエレクトロニック・アーツはゲーム用に最適化したSTLもどき、EASTLなるものを公開していたりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]
そんなテンプレート通りのお達しが通用するとでも？＃AC
そこらへんをなんとかするのがコンセプト [wikipedia.org]だったはずですがお亡くなりになりましたね……
長くて読み難いので一行にまとめてみた。
dodongaです。
結論：読む価値はない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
C++=過去の言語 (スコア:-1, 荒らし)
今回はその予告ですね。
Re:C++=過去の言語 (スコア:2, すばらしい洞察)
ここのサブジェクトを見た時、
何ぞおかしな構文をネタにした書き込みかと一瞬思いました。
それはさておき、過去の言語だとか互換性がどうだとか色々言われてるけど
そんな言われるほどダメかなぁ？
仕様自体は互換性を極力損ねないようにしているし、
とはいえ、どこ製のコンパイラによって実装の方法が云々って話はあるけど
それってC++だけの問題なんでしょうか。
Re: (スコア:0)
あともうちょっとだけ続くんじゃ (Re:C++=過去の言語) (スコア:2)
一応ここにぶら下げますが、別に誰に対する反論でもないので
あくまで私個人の周囲の考え方として参考にしていただければ良い程度の発言です。
私自身はC#に惹かれちゃいましたので、Win系開発はC++終わったかと思っていたんですが
MFCが復活の兆しを見せていたり、事実、非常にカスタマイズされた独自UIを持つアプリや
速度やメモリ的にクリティカルな(富豪的でない)案件では依然としてVC++の優位性がダントツといった印象です。
一方でAndoroid/iPhoneなど流行りの界隈でも、主流言語こそそれぞれ異なりますが
C++はそのどちらでも開発可能だったりしますので非常に重宝します。
Linux系開発も、商用フリーなGUIライブラリとしてのQtがどこまで伸びるか、によって
C++の重要性が大きく変わってくるでしょうね。
まあ世の中、Webアプリとクラウドがあれば全てOK的な意味で
それ以外の言語/プラットフォーム全てを「終わった」と表現する方もいますが
個人的には、C++はドラゴンボールで言うところの「あともうちょっとだけ続くんじゃ」という
頃合いかと思っています。
# つまりこれからがむしろ長いってこと
Re: (スコア:0)
C++ならば、SUN cfrontから使っていますよ。
Windowsのメイン開発言語は、C→C++→C#と変わってきましたが、
Macのメイン開発言語も、Pascal→C→C++(Symantec/CodeWarior)→Objective-Cです。
一時は、どのプラットフォームもC++で、少しずつ違うコンパイラ/言語仕様に
ひっかからないようにプログラミングしてましたよ。
いまどきは、Java, C#, Objective-Cがメイン開発言語。C++はメンテ用。
C++が新しくなったところで、使う機会はもうほとんどない(はず)。
Re: (スコア:0)
＞Macのメイン開発言語も、Pascal→C→C++(Symantec/CodeWarior)→Objective-Cです。
MPWも入れてやってください・・・
Re: (スコア:0)
コンソールプログラムの作成は、Symantec/CodeWariorも使いにくい。
MPWはシステムが使いにくいので、MacMiNT+emacsを使っていました。古いgccでした。
NetBSDとかBeOSとかMkLinuxとかOS入れ替えることもできたけど、常用することはありませんでした。
MacOS上で、OberonとかSMLとか、いろいろな言語/システムが動作したもんです。
MacOS X上ではSqueakしか使っていません。
MachTenはまともに使ったことありません。
Re: (スコア:0)
別ACですが、
>C++=過去の言語
こういうのを見るたびに思うのが、
お前がそう思うんならそうなんだろう お前ん中ではな
富豪的プログラミングができる環境しか見ていない人の発言ですね。
おそらく元コメは他の選択肢が無かった時代でしかC++を使用する機会が
無かった人という意味で言ったのではないかと思います。
それを自覚したうえで"過去の言語"とするなら、まったく問題ないのですが。
Re: (スコア:0)
＞無かった人という意味で言ったのではないかと思います。
「VC++でのWindowsプログラミングしか知らない人」
＝「他の選択肢が無かった時代でしかC++を使用する機会が無かった人」？
意味不明。
「他の選択肢が無かった時代」って、いつ？
もっと具体的に、誰でも分かるように書いてくれないかな？
「VC++でのWindowsプログラミングしか知らない人」じゃないぞ！
と示しただけなんだが。
Re: (スコア:0)
すみません。その段落は蛇足でした。
他人様の意見を補足しようなど100年早かったです。
その"Windowsプログラミングしか知らない人"云々の
2行を抜いて読んでいただけるとありがたいです。
Re: (スコア:0)
あと、iPhoneもC++だったり(Objective-Cで書いちゃうと、他で使いにくいし)。
まぁ、プラットフォームのAPI使う部分はC#とかObjective-Cつかわなしゃーないとしても、コア部分はC++が使いやすいんじゃないですかねぇ。
Re: (スコア:0)
Re: (スコア:0)
同じ言語でありながらコンパイラ間ですら互換性なかったり、数年後にはまたもどうなってるか分からない言語機能をプロジェクトで使うこと自体に良識を疑う。
まともな会社ならC++を採用してもtemplateだけは使うなとお達しする。
Re:C++=過去の言語 (スコア:1, 参考になる)
> まともな会社ならC++を採用してもtemplateだけは使うなとお達しする。
実際にC++使ったことある？
templateダメだったら、標準ライブラリほとんど使えないじゃん。
Re:C++=過去の言語 (スコア:2, すばらしい洞察)
まともなプログラマーは、こういうのを「まともな」とかほざくような奴や会社と関わり合いになるなってこと。
アメリカ: templateを使うという条件に合わせてメンバーを集めて生産性を向上する。
日本: いちばんレベルが低いメンバーに合わせて使用を禁止して、奴隷を安く買い叩く。
Re: (スコア:0)
> templateダメだったら、標準ライブラリほとんど使えないじゃん。
実際にC++使ったことある？
標準ライブラリなんて元からほとんど使えないじゃん。
# まじめに会社のプロジェクトで使ったことなんてないんだろ？せいぜいスクリプトもどき作るぐらいで。
# 一番使用率が高いと思われるゲーム業界でも標準ライブラリなんて使ってないって。
Re:C++=過去の言語 (スコア:1, 参考になる)
まあ、たしかに入出力周りとか全然使う気になれないですし、ほかにもろくなライブラリもなかったですが、string（文字列）、vector（動的配列）、list/forward_list（リンクリスト）、map/unordered_map（連想配列）あたりのクラス（テンプレート）はプロジェクトの性質によらず使えるのではないでしょうか（もちろん、コンパイラ付属の実装が実用に耐えると判断するか否かは別問題として）。
＃ C++の標準ライブラリでテンプレートを使っていないものと言ったら、new/delete（が使うメモリ確保・解放処理をユーザ側で差し替える際に定義する関数）や例外クラスしか残らない気がする。
＃ cout/cinも疑似乱数も正規表現もテンプレート、thread/mutexクラスはテンプレートではないけど、ロックやfeatureがやっぱりテンプレート。
Re: (スコア:0)
あと、STLのstringはリードオンリーにちかいので、
Cのライブラリと相性が悪くつかいにくいと思うな。
Re: (スコア:0)
C++0xでstring (basic_string)はvector同様に各要素が連続することと決まりました。そのため、Cのライブラリとの相性も少しは良くなったと言えます。
ただし、'\0'終端するわけではないので、basic_stringの要素へのポインタを渡して'\0'終端文字列を受け取るときは、大きめのバッファ（basic_string）で受け取った後、長さ丁度にresizeするなどと、若干の手間が必要になるはずです。それでも、一旦vectorを介すよりは（メモリ面でもコード上でも）手間が減るので良いと思います。
Re: (スコア:0)
c_str()じゃダメなんですかね。
strtokなど、文字列を変更してしまう一部の関数では使えないですけど、それでもvector介すよりはchar型の配列に(C文字列として)コピーして操作したほうが楽な気がします。
Re: (スコア:0)
一般的にはtemplateを使うでしょう。
なぜなら、templateを使うことが一般的(標準)だから。
# プログラムに限らず、手順や手続きの標準化は必要だよ。
Re: (スコア:0)
ゲーム業界に居た事が無いから実体は知らんが、標準ライブラリは置いておいても、templateは使うんじゃないの？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]
最近template使っておきながら実装は特殊化されたもののみとかキチ○イじみたコードを見たから
禁止したい気持ちはわからなくもないけど、まともに使うならば他の言語には無い強力な機能ですよ。
Re: (スコア:0)
前にいたゲームメーカーでは禁止はされてませんでした。
メモリに優しくねーなーって空気はありましたけれども。
それ聞いた時はさすがメモリに厳しい世界だと思いましたが、その反面、
よく分からない社外製のミドルウェアを買ってメモリに四苦八苦してるので
何が良くて何が悪いかは古株の人の好みでしょう。
手段が何であれ最後にフリーズせずに動くマスターを用意できればいいので。
あと、STLに限った話で言えば、自社用のSTLもどきはありました。
STLの品質がどうこうじゃなくて、STLが使えない環境用に置いてあったようです。
上手に実装できるなら何でもありの世界ですからね。
Re: (スコア:0)
自分はゲーム業界で開発をしているけど、TemplateなりSTLなりはバリバリ使っている。うまく使えば、コンパイル時にコードを解決できるから効率も良い。
Templateが少なくとも読めないとウチのプロジェクトづらい。
# STLはアロケータをカスタマイズして使っていることが多い。
特に海外ではTemplateがよく使われる。
物理エンジン系のミドルウェアであるHavokは全面的にTemplateを採用しているし、海外大手であるエレクトロニック・アーツはゲーム用に最適化したSTLもどき、EASTLなるものを公開していたりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]
Re: (スコア:0)
そんなテンプレート通りのお達しが通用するとでも？
＃AC
Re: (スコア:0)
templateが嫌われるのは、やっぱあのエラーメッセージでしょうね。
人間にはほとんど読めません。
まあでも不思議と使い込んでると、パターンマッチで
あの辺が怪しいな、とか推測できるようにはなるんですけどね。
Re:C++=過去の言語 (スコア:1)
そこらへんをなんとかするのがコンセプト [wikipedia.org]だったはずですがお亡くなりになりましたね……
Re: (スコア:0, すばらしい洞察)
長くて読み難いので一行にまとめてみた。
結論：読む価値はない。
Re: (スコア:0)
つ静的言語 [wikipedia.org]