アカウント名:
パスワード:
同じ言語でありながらコンパイラ間ですら互換性なかったり、数年後にはまたもどうなってるか分からない言語機能をプロジェクトで使うこと自体に良識を疑う。まともな会社なら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++=過去の言語 (スコア: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]