2018-11のC++ドラフトの主要な変更
N4792 C++20のドラフトが更新された。今回も強めの変更が入っている。 まずconstexprが大幅に強化された。 p1002r1.pdf Allowing dynamic_cast, polymorphic typeid in Constant Expressions C++20での最終的な目標は、std::vectorやstd::stringをconstexpr対応させることだ。そのために従来ならば実行時処理であった様々な機能がconstexprに対応している。今回の変更では、try/catchブロックやdynamic_cast/typeidがconstexprに対応した。また、unionの有効なメンバーの変更もconstexprに対応した。 try/catchブロックはコンパイル時評価される場合、単に無視される。 dyanmic_cast/typeidは本当にconstexpr
DNAの読み取りについてプログラマーが誤解していること
世の中にはDNAの読み取りを使った技術が実用されすぎている。DNAを使った生物の共通祖先の判定、人間の出アフリカ以降の移動の推定、特定の病気にかかりやすい遺伝子を持つかの判定、親子鑑定、刑事裁判におけるDNA鑑定などなど。 あまりにもDNAの読み取りを使った技術が実用化されすぎているため、世間ではDNAの読み取りは簡単なものだと考えている。プログラマーとて例外ではない。 大抵のプログラマーはヒトDNAの読み取りを以下のように考えている。 「一本の長い磁気テープを先頭から末尾までシーケンシャルにリードする」 より現実的に例えると以下のようになる。 長さ30kmの長大な磁気テープをだいたい長さ1cmのテープ片に切断する 上記1cmのテープ片を数百本複製する 上記複製した数百本の1cmテープ片をマイクロメートル単位のテープ片にズタズタに切り裂いて混ぜ合わせる 上記混ぜ合わせたマイクロメートル単位
GDBがC++コード注入をサポート
C++ Support Added To GCC's libcc1, Benefiting GDB - Phoronix C++ support in libcc1: A comprehensive update – RHD Blog 最新のGCC 7では、GDBがC++のコード注入をサポートするようになった。 GDBは、デバッグ中のプログラムにC言語のコードをその場でコンパイルしてコード注入して実行する機能を持っている。これにC++が対応した。 この機能はlibcc1.soを通じてGDBとGCCが強調動作することによって実現されている機能だ。 CとC++は似ている言語ではあるが、名前空間など名前検索のルールが異なるので、シンボル名を探すにもGDBにC++の名前検索を実装しなければならない。また、テンプレートにも特別な対応が必要だ。
Appleのマーケティングに騙されてはいけない
Appleがアメリカで容疑者のコンピューターの暗号解除に協力するよう裁判所命令を出されたかどで、Appleは顧客のプライバシーとセキュリティを脅かす命令だとして反対する公開声明をだしている。世間はAppleの顧客のプライバシーとセキュリティを守るようにみえる姿勢を賞賛しているようだ。 しかし騙されてはいけない。これはAppleのマーケティング戦略に過ぎない。Appleは顧客のプライバシーとセキュリティを守る技術的な最善の努力を一切果たしていないので、プライバシーとセキュリティを気にかける人間はApple製品を使ってはならないのはもちろんである。 そもそも、Appleは国家政府に秘密裏に協力していた前科がある。今更顧客のプライバシーを守る云々などと言い出したのは、アメリカ政府による監視の実態を告発した真のアメリカの愛国者Snowdenの登場以降である。顧客のプライバシーとセキュリティをないが
GCC 6にインデントミスの警告機能が追加
GCC 6にインデントミス警告の機能が追加された。ドキュメントのコミットログは以下の通り。 gcc.gnu.or g Git - gcc.git/blobdiff - gcc/doc/invoke.texi このインデントミスの警告機能は、-Wmisleading-indentationオプションで有効にできる。 if ( condition ) foo() ; bar() ; // 警告 具体的に説明すると、この機能は、if, else, while, forの中の文がブロック文ではなく、かつ、文に続いて同じインデントのif, else, while, forではない文が続く場合に警告する。 例えば、以下のようなコードは、for文のオペランドとしての文に続いて同じインデントレベルの文が続くが、for文なので警告は出ない。 const std::size_t I = 10, J = 10,
最近のC++17事情
C++1z、あるいはC++17とも呼ばれている次のC++規格の、最近の事情はどうなっているのか。すでにドラフトに取り入れられた機能もあるので、現在の最新の状況を見ていこう。もうすでに紹介したものも含まれているが、おさらいとしてみていく。また、ここで解説する新機能は、いずれもすでにドラフト入りしているが、正式に規格制定される際に変わる可能性がある。 N3928: メッセージなしstatic_assert C++11で入ったstatic_assertは、必ず文字列リテラルを書かなければならなかった。 static_assert( INT_MAX >= 2147483647, "This code assumes at least 32-bit int." ) ; static_assert( true == true, "You're compiler is fundamentally wro
最近のC言語の配列
N4188を読んでいて、C言語の規格を参照する必要が出てきたので、C言語の規格を読んだのだが、最近のC言語の配列は、面白いことになっている。 以下はすべて最新のC規格で合法なコードである。 void f( char a[ * ] ) ; void g( char a[ static 100 ] ) ; void h( char a[ const volatile restrict ] ) ; void wtf( char a[ static const volatile restrict 1 ] ) ; これは、関数のプロトタイプ宣言でのみ許されている。 [*]は、サイズを指定しない可変長配列型である。関数のプロトタイプ宣言スコープの中でしか使えない。[]との違いは、完全形であることだ。 [static n]は、関数を呼び出した際の実引数は、少なくともn個の要素を持たなければならない。 v
C++でfinally
一部の言語には、finallyという機能がある。あるブロックスコープを抜ける時に、必ず実行される処理を記述することが出来る。 try { // 処理 } finally { // ブロック文を抜けた時に必ず実行される処理 } C++にfinallyがない理由は、特に専用の文法が必要なく、ライブラリで十分なためだ。デストラクターとlambda式を使えばよい。 class scoped_guard { std::function< void() > f ; public : explicit scoped_guard( std::function< void () > f ) : f(f) { } scoped_guard( scoped_guard const & ) = delete ; void operator = ( scoped_guard const & ) = delete ;
ValveがOpenGLデバッガー、VOGLを公開した
GNU/Linuxに不自由なソフトウェアを蔓延させる目的で活動してるValveが、VOGLという自社製のGNU/Linux上で動くOepnGLのデバッガーをGitHubで公開した ValveSoftware/vogl まだ開発段階で、ろくにドキュメントもないようだ。早期に公開するという姿勢は評価したい。残念ながら、彼らのソフトウェア流通プラットフォームは邪悪のDRMがかかった不自由ソフトウェアを蔓延させるものなのだが。 Anonymous said... SteamとDRMは関係ないでしょう Valve社に恨みでもあるんですか March 13, 2014 at 9:30 PM Anonymous said... え March 13, 2014 at 9:47 PM Anonymous said... http://steam.wikia.com/wiki/List_of_DRM-fre
ドワンゴに入社した
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11？ C++14？ なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ？ SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
bzrは死につつある。Emacsは移行しなければならない
bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
CRTPと仮想関数呼び出しの比較
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
技術屋にMac使いが多い理由ってなに？
技術屋にMac使いが多い理由ってなに？ : IT速報 答え：お手軽なUNIX互換環境だから。 今、個人が使うデスクトップやラップトップ用のOSとして、実用的なものに、GNU/Linux, Windows, Mac OS Xがある。読者の中には、FreeBSDも十分に実用的だと主張する者もいるかもしれないが、少数派だろう。 もちろん、サーバーや組込み用途には、その用途に合わせて別のOSが使われている。しかし、プログラマー個人が使うコンピューター用のOSは、圧倒的にMac OS Xである。これはとても残念なことだ。なぜならば、Macは不自由なソフトウェアで、しかもその動作するコンピューターまで、技術的な理由がなく制限されているからだ。 UNIX互換環境を必要とする理由としては、既存のPOSIX互換環境向けに書かれた有用なツールがとても多く、プログラマーはなんとしてもそのツールを使いたいのだ。
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
C++11参考書の公開：C++11の文法と機能
C++11の参考書をGitHubで公開する。 GitHub: EzoeRyou/cpp-book GitHubからzipでダウンロード GitHub Pagesでの閲覧：C++11の文法と機能 序 本書はC++11のコア言語の文法と機能を、標準規格書に従って解説したものである。正式なC++規格書として発行された後の、ひとつ後のドラフト規格、N3337 を参考にしている。ドラフト規格を参考にした理由は、正式なC++規格書は、個人での入手が煩わしいためである。読者に入手が困難な資料を元に記述された参考書は価値がない。そのため、読者が容易に入手できるドラフト規格のうち、正式なC++規格書とほとんどかわらないN3337を参考にした。 本書の対象読者は、C++を記述するものである。C++実装者ではない。そのため、サンプルコードを増やし、冗長な解説を増やし、C++コンパイラーを実装するための詳細な定義
Super Meat Boyの作者Tommy RefenesがSteamコントローラーを体験
Yzc2NjQ1MzQyNDU2MjMyMz - My time with the Steam Controller あのクソ難しい、往年の悪魔城ドラキュラやスーパーマリオブラザーズを彷彿とさせる、死んで覚えるプラットフォームゲーム、Super Meat Boyの作者の一人、Tommy Refenesが、ValveでSteam Controllerの試作機を体験した感想を書いている。 Steamコントローラーの体験 俺がSuper Meat Boyを開発していたとき、俺は正しいコントロールが、ゲームの可否を決めるのだということを分かっていた。俺は、ゲームのコントロールには、うるさい男だ。もし、ゲームのコントロールが悪ければそれまで、誰か作ったかとか内容とかはどうでもいい、俺はそんなものをプレイし続けることはない。俺はよく、Super Meat Boyの動きとか摩擦だとか空気抵抗の物理の計算
C++14にやってくる見た目に分かりやすい新機能
C++14のCDも公開され、いよいよC++14も形になってきた。いま書いている本はC++11だが、C++14はGCCとClangといった二大C++コンパイラーで数年のうちに実装されるだろうから、もうすぐ実際に使うことができる。 今回は、詳細な説明は省いて、サンプルコードで新機能を語りたいと思う。以下の新機能は、すでにドラフト入りしており、正式採用はまず間違いない機能である。ちなみに、コンパイルしていないので正しいかどうか検証していない。 2進数リテラル int bi = 0b11110000 ; // 10進数リテラルでは240 2進数の記述が直感的になる。 自動ストレージ上に確保される動的な長さの配列 void f( std::size_t size ) { int buf[size] ; // OK } もちろん、クラスの配列も可能だし、コンストラクターやデストラクターも正しく呼ばれる
デニス・リッチーによって書かれた最初のCコンパイラーがGitHubで公開
mortdeus/legacy-cc · GitHub デニス・リッチー(1941-2011)によって書かれた発展途中の初期のCコンパイラーのソースコードがGitHubで公開されている。ソースコード自体は、まだデニス・リッチー存命の頃から公開されていたが、この機会に紹介してみる。 ライセンスは許諾的で、このライセンス文を同梱すること、並びに、ソースコードから生成されたバイナリはラインセンス文を出力することとなっている。 追記：ライセンスに関してふと思った。このライセンスは名義が企業で、著作権を盾に同意を求めている。日本では、映画以外の団体の著作権の保護期間は公開後50年である。UNIXと付属するソフトウェアのソースコードは当時から公開されていた。ということは、1973年に制作されたこのCコンパイラーのソースコードは、日本国内では、2024年に著作権が切れるのだろうか。 詳しい経緯は、以下の
LLVM/Clangがぜってーサポートしねーと宣言しているLinuxカーネルに多用されているGCC拡張
[Phoronix] LLVM/Clang 3.3 Should Be Close To Building Linux Kernel LLVMLinux Bug 9254 – clang can't build iptables in Linux kernel: error: fields must have a constant size: 'variable length array in structure' extension will never be supported ClangでLinuxカーネルをビルドできる状況は、多くの勢力に望まれてきた。理由は様々だ。Clangはビルド時間が短い。静的解析による警告も優れている。ソースコードも綺麗だ。複数の独立した実装でコンパイルできるコードは、誤りを静的に発見しやすい移植性にも優れる。より優れたコピーレフトなライセンスであるGPLv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
