C++11やC++14は、すでにGCCやClangの最新の安定版で実用的に使えるようになっているが、なかなか現場で広く使われるようにはなっていないように見える。これはなぜか。やはり教育者の不足か。参考書がないのか。それもあるかもしれないが、最大の理由がある。
RHELが悪い。
RHEL 6のGCCのバージョンは4.4である。これは。C++11をまともにサポートしていない。GCC 4.4当時といえば、まだC++11がC++0xと呼ばれていた時代で、一部機能を当時のドラフトに基づいて実験的実装をしていた。正式な規格とはだいぶ異なっているだろうし、不具合もたくさんあるものと思われる。
次のRHELのバージョンは7であるが、これにはGCC 4.8が入るものと思われる。しかし、すでにGCCの安定版は4.9だ。GCC 4.8もC++11実装に不具合が色々あってあまりお勧めできない。これがあと何年も使われるのかと思うとげんなりする。
結局、LTSというのは本当に有益なのだろうかという疑問が湧いてきた。挙動が変わらないとはいっても、不具合もそのままなので、そのコストは支払わなければならない。そして、いずれはソフトウェアをアップデートせねばならず。5年10年もの積みかさなかった挙動の変更を一気に修正しなければならない。
とはいえ、C++の簡単な入門書は必要だと思うので、簡単に読めるC++の解説を今書いている。
ドワンゴ広告
この記事はドワンゴ勤務中に書かれた。
ドワンゴは本物のC++プログラマーを募集しています。
CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0
7 comments:
RHELをデスクトップで使っている人そんなに多いのだろうか？
RHEL7 は去年の6月に既にリリースされていて、GCC 4.8 で確定しています
あるコードはclang 3.4以上でコンパイルできるんですがgccではダメで、たまに新しいのが出ると試してます。とりあえず今gcc HEAD 5.0.0 20150225 でやってみてダメでした。つまりgccはダメってことで。
うちの会社でも今度C++を使用することになって、化石のようなC++03ではなくC++11を使用することを提案しましたが、「RHEL6で使用できない」ことを理由に却下されました。せめてboostの使用の許可を貰いたかったのですが、却下されました。tr1::shared_ptrの使用だけはどうにか許可してもらいました
これから製品の出荷まで（そしてその後も）autoやunique_ptrすら使用できない縛りプレイをしなければならないかと思うと鬱です。
RHEL6に無償でついてくるDeveloper Toolsetでgcc 4.9.1が使えますよ。メインの10年サポートと並行して3年サポートで新しいツールが使えるように頑張ってますのでよろしく。
昔、MSでデファクトがVisual Studio 6 だからいつまでたっても新しいC++が使えないと怒ってた人がいるの思い出した。古いVC使うの強制してるのはお前の会社であって、MSじゃないってって思ったものです。
Developer ToolsetについてはJeff Law, Matt Newsomeとかなり議論したので、補足できそうなので、ちょっと乱入して補足するです。
上でMoriwakaさんが言っているサポート期間の話はあくまでgccに対してバグ修正を行うかどうかの話で、RHELはどんなコンパイラで生成されたa.outであってもちゃんとサポートするよというポリシー。なので、Developer Toolsetを使う事によって自分が開発するプロダクトのライフサイクルが影響受けたりはしない。
彼らの説明によると、一番大きいのはRHELとバージョン番号がasyncになることで、どんどんアップデートが可能になること。MS製品でWindowsとVisual Studio のリリースが同期してないけど、特に困ってないよね。という感じの説明でした。
そういうわけでRHEL6であってもC++11使えるはずですよ。自社にヘンテコ開発規約がある人はご愁傷様だけど。
補足： CentOSでも同様の新バージョンgccあります
ソフトウェアの需要者（発注元など）がディフェンシブで、
今までのものが動くこと、安定して動くことを強く求めているからでしょう。
いくら提供していると云われても、epelだとかremiだとか突っ込めばあるものにしても、
デフォルトの完成状態をぶち壊す、また、管理しにくくなる、それを怖れているわけでしょうから。
（gcc だけではなく、phpなどにしたって、旧リリースでは,他所からぶっ込まないと上がりませんし）
レルに限ったことではなく
debian stable(or LTS)、派生のUbuntuのLTS等にしても、
バージョンアップの追随にはディフェンシブなのが仕様ですが、エンタープライズ仕様の典型がレルでシェアがあるから「レルのせい」と言われかねないわけなのでしょう。
ミクシィが昔、旧いリリースバージョンのFedora（だったか）を騙し騙しいじり倒して使い続けていたという話も、
未だにWinXPの企業があるという話も（なぜなら過去のソフトウェア資産が動かなくなるから）あるわけですし。
リリースアップグレードの負担と、ことによっては移植作業までも、必要ですから。
悪いのは、ソフトウェアを運用している人間のほうです。
だからあくまでもレルが「悪い」というのではなくて、レルが原因の一端だという「事実上の条件因果関係」はあるということでしょう。
ただついでに言うと、正直に言って怖いのは、先般の「GHOST」問題のように
upstreamは当たり前にfix済なのに、ディストリビューションが脆弱性を捕捉しておらずpatchしていないままという事態。
ローリングリリースといったやり方で、かつ、運用側にあえてアップデートに追随しつづける勇気がないと、
この点は本質的には解決困難ではないかと。
Post a Comment