C++0x の最終国際規格案が委員会を通過、夏にも発行予定 58
ストーリー by reo
C++ の優位性って今ではどこにあるのだろう 部門より
C++ の優位性って今ではどこにあるのだろう 部門より
3 月 21 〜 25 日にマドリードで開催された ISO C++ 会議において最終国際規格案 (FDIS) が承認され、今年の夏にも発行される予定となった (Herb Sutter 氏のブログ記事より) 。
前回 C++ 標準である C++03 の発行から実に 8 年を経た 2011 年に C++0x が承認・発行されることとなり、発行以降は C++ 2011 となる見込み。
現状で、読みやすい C++0x に関する文書としては Bjarne Stroustrup の FAQ、およびその日本語訳であろうか。
正式名称は、"C++0xB" じゃないんだね。:-P (スコア:2)
(T/O)
普及はいつ頃 (スコア:2, 興味深い)
しばらくは古いコンパイラを考慮してスマートでない複雑な構文を用いたり、
boostを使ったりしないといけないのが歯がゆいです。
大半の人がVC6の腐ったtemplateを考慮しなくなったのは
C++の仕様が固まってから何年後くらいですかねえ。
# もちろん必要な人は未だに考慮していると思いますが
Re:普及はいつ頃 (スコア:1)
Re: (スコア:0)
Win9xのことを考慮しなくてよくなってからではないですかね。
VC8以降で生成したバイナリはWin9xでは動きませんから。
Firefoxの場合は3.5あたりからVC6でのビルドはできなくなって、VC6対策のコードを一掃しました。
Re: (スコア:0)
CObjectクラスなんか継承した事もない
Re:普及はいつ頃 (スコア:3, 興味深い)
マジレスするとそれが許されるのがマルチパラダイム言語かと。
templateがチームの技量に合わないなら使う必要はないし
オブジェクト指向の数step/数byteが実装系のネックになるならベターC/ベターアセンブラとして使えばよいし
下請けでなく社員皆すーぱーはかーという幸運な環境ならlambdaなり何なり変態の道を極めるもよし。
C++の複雑性は、その一部のみを切り取って俺様サブセットを使用する自由を守ろうとしたが為ですから
どうぞ貴方(andチームand実装系)に都合が良い部分のみを使用してください。
おまえらもっと C++0x の話しようぜ (スコア:2, 参考になる)
C++0x基礎文法最速マスター [hatena.ne.jp]あたりを見れば大体の感じが掴めるのじゃないかと。
initializer_list [ocn.ne.jp]や範囲 for 文 [ocn.ne.jp]あたりは地味に便利というか、なぜ C++ 03 に入っていなかったのかレベル
Re: (スコア:0)
前からあったほうの関数宣言なんですけど、レガシーコードの保守以外にメリットあるんですかね？
新しい方を推奨にしちゃえよって気がするんですが。
Re:おまえらもっと C++0x の話しようぜ (スコア:1, 参考になる)
dodongaです。
格上げの問題なので、慎重に；
C言語の場合：
以下の4通りが考えられます。
1,2は問題ないです。
3の場合、関数定義で小さな型を使うと問題が。実際の型で渡されるのに関数では格上げを期待
4の場合、関数定義で小さな型を使うと問題が。格上げされたのを期待してるのにそのままの型で渡される。
C++言語の場合：
K&Rは認めれられて無く、プロトタイプが必須なので問題なし。
CとC++では、格上げにも非互換あるので、なんとも；；
閑話休題
Re:おまえらもっと C++0x の話しようぜ (スコア:1)
後者の記法は、戻り値の型が複雑な場合に簡単に書けるようになるという利点があります。 例えば、関数ポインタを返す関数を定義する場合、従来だと typedef を使って書いていたものが、
のように書けるようになります。 また、引数が戻り値の部分でも使えるようになるため、 C++0x で追加された decltype という式の型を表現するキーワードを使うと
と書けるようになります。 従来の関数定義の記法だと、f も t もスコープに入っていないので
とは書けません。
Re:おまえらもっと C++0x の話しようぜ (スコア:2, オフトピック)
dodongaです。
とあったので、K&Rと判断しちゃいました；
疑問ですが、
リンカ側は問題ないのでしょうか。
# 純粋に疑問なだけです^^。
閑話休題
Re:おまえらもっと C++0x の話しようぜ (スコア:1)
コンパイル時のみの変更で、関数の型が変わるわけではないので問題は無いと思います。
Re:おまえらもっと C++0x の話しようぜ (スコア:2)
dodongaです。
タレコミに書いたHerb Sutter 氏のブログ記事の翻訳を書いていた方のペ～ジを張っておきます。
http://d.hatena.ne.jp/ntnek/20110326 [hatena.ne.jp]
閑話休題
FAQ (スコア:0)
>現状で、読みやすい C++0x に関する文書としては Bjarne Stroustrup の FAQ、およびその日本語訳であろうか
リンクが両方404なんですが私だけでしょうか。
Re:FAQ (スコア:2, 参考になる)
それぞれ、"~"部分が他の文字に置き換わってしまってるみたいですね。
http://www2.research.att.com/~bs/C++0xFAQ.html [att.com]
http://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja [ocn.ne.jp]
Re:FAQ (スコア:1)
リンクが両方404なんですが私だけでしょうか。
s/‾/~/
で見れました。
Re: (スコア:0, オフトピック)
まーたやってしまいました。ご指摘 thx です。修正しました。
Hiroki (REO) Kashiwazaki
Typo (スコア:0)
×最終国際企画案
◯最終国際規格案
Re: (スコア:0, オフトピック)
おっほい、ご指摘 thx です。修正しました。
Hiroki (REO) Kashiwazaki
Re: (スコア:0)
Re: (スコア:0, オフトピック)
ああっ、気付きませんでした。修正しました、ご指摘 thx 。
# そしてどんどんカルマが減っていく……。
Hiroki (REO) Kashiwazaki
Re: (スコア:0)
修正とカルマって？
Re: (スコア:0)
自分の修正コメをマイナスモデで沈めてるからでは。
Cのコード (スコア:0)
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)
一般的には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]