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
10 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していないままという事態。
ローリングリリースといったやり方で、かつ、運用側にあえてアップデートに追随しつづける勇気がないと、
この点は本質的には解決困難ではないかと。
脆弱性対応のアップデートはRHELはおそらく数あるディストリビューションの中でももっともまじめに対応しています。ベースのバージョンを維持しつつ問題修正をバックポートしています。これはupstreamが既にメンテナンスをやめてしまったバージョンであっても同様です。
重要な問題についての更新パッケージは可能な限りすばやく提供していますのでご適用よろしくお願いいたします。
> RHEL6に無償でついてくるDeveloper Toolsetでgcc 4.9.1が使えますよ。
使ったことないので下の資料を軽く読んだだけの印象ですが，Developer Toolset を使うと，何を動的リンクして何を静的リンクするかが結構複雑に変化したりしませんかね?
http://www.redhat.com/summit/2012/pdf/2012-DevDay-How-To-Toolset-Newsome.pdf#page=26
| What about newer features? C++11 library contents?
| - Newer features in gcc-4.7 than in gcc-4.1/4.4 in RHEL5/6
| - These parts statically linked for you into your application
とりあえず Chromium あたりを Developer Toolset でビルドしてみて，全テストが通るところまで持って行けると以下のバグを閉じられるので，成功したという人がいらっしゃいましたらお知らせください．
https://code.google.com/p/chromium/issues/detail?id=227320
> MS製品でWindowsとVisual Studio のリリースが同期してないけど、特に困ってないよね。という感じの説明でした。
概ねのことに対処法があるので，その意味では困っていないです．が，開発者側に溜まっているノウハウの総量も結構な規模で，特に困っていないという感覚は a priori ではないかも．
そもそもたどってきた歴史が大分違うと思うんですよね．
- Windows では昔からバイナリ配布が一般的だった
- Windows では多くの場合開発者自身がパッケージングを行う
- Windows では，ABI の異なる C++ コンパイラで生成された DLL が同一プロセス内で動くという状況が昔からあたりまえだった
こういう世界で生き残っている人にとっての「特に困ってない」という感じかと．
AndroidのNDKアプリとかだと，C++のランタイムライブラリは静的リンクするのが事実上の標準になっていて良いですね．最近はフラットパッケージング派に一票入れるようにしています．
「C++11/14が、2015年2月時点で世に浸透していない主な理由がRHEL」と主張した根拠は何?
思い込み?
世にある多くのC++の実行・開発環境がRed Hatとは、到底思えんが...。
当時すでに Ubuntu含むDebian系 が台頭してたし、無論 Windows だってバリバリ幅を利かせ続けてるように思う。
Post a Comment