80年代、Microsoft製のUNIXが存在していた POSIXサブシステムは2012年までサポートが続いた 現在のWindows 11では、Windows Subsystem for Linux（WSL）が動作するため、（それ自体はUNIXではないものの）UNIXからのアプリケーションを簡単に動作させることができる。 かつてMicrosoftは、x86版UNIXのライセンスを持っており、XENIXと呼ばれる製品を販売していた。また、Windows NTに「POSIXサブシステム」、のちに「Windows Service for UNIX（SFU）」と呼ばれる機能があった。そういうわけで、WindowsとUNIXは切れない“縁”があったのだ。 Windows NTのPOSIXサブシステムやその搭載理由などに関しては、過去記事（「Windows Subsystem for Linuxの中身
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 村上雅章 野崎裕子 2022-03-04 11:33 LinuxカーネルがCで記述されているというのは誰もが知るところだ。ただ、そのCがかなり昔のC、すなわち1989年の規格である「C89」だという事実については知らない人もいるかもしれない。C89は「ANSI X3.159-1989」、あるいは「ANSI C」としても知られている。Linus Torvalds氏は、そろそろC89に別れを告げる時だと判断し、Linuxカーネルの公式な開発言語を2011年規格の「C11」に移行しようとしている。 これは見かけほど大きな変更ではない。C89は現在でもほぼ普遍的にサポートされている。どのようなCコンパイラーでも以前の規格との後方互換性を備えているため、C89で記述されたプログラムのコンパイ
日本時間の2021年4月26日午前3時6分、Emacsのmasterブランチにfeature/native-compブランチがマージされました（コミット：Merge branch ‘feature/native-comp’ into into trunk）。これにより、HEADのEmacsをビルドすると、Native compilation機能を兼ね備えたネイティブコンパイルEmacs、通称Gcc Emacsが使えるようになりました。 ネイティブコンパイルEmacsの機能 # ネイティブコンパイルEmacs（以下、Gcc Emacsと呼びます）は、Andrea Corallo、Luca Nassi、Nicola Mancaの3名によるBringing GNU Emacs to Native Code という論文で詳細が説明されています。 簡単に説明すると、これまでのEmacsは、Elisp
C言語で配列の要素数を数えるイディオムってのがあって、 sizeof(array) / sizeof(array)なんだけど、配列名が長くなって、たとえば sizeof(var.that_has_an_array.as_a.member) / sizeof(var.that_has_an_array.as_a.member[0])とかになるとカオス。 なので、ベンダーによっては、 #define _countof(array) (sizeof(array) / sizeof(array[0]))みたいなマクロを提供していたりするんだけど、こうやって、何も考えずに使えるようにしていくと、配列ではなくポインタを引数に渡しちゃって、サイズ計算ミスって変な動作する懸念が増してくる。 なので、Twitterで C言語で、ある値がポインタなのか配列なのかを知る方法ってあるのかなぁ（gcc/clang拡
序 本書はプログラミングの経験はあるがC++は知らない読者を対象にしたC++を学ぶための本である。本書はすでに学んだことのみを使って次の知識を説明する手法で書かれた。C++コンパイラーをC++で書く場合、C++コンパイラーのソースコードをコンパイルする最初のC++コンパイラーをどうするかというブートストラップ問題がある。本書はいわばC++における知識のブートストラップを目指した本だ。これにより読者は本を先頭から読んでいけば、まだ学んでいない概念が突如として無説明のまま使われて混乱することなく読み進むことができるだろう。 C++知識のブートストラップを意識した入門書の執筆はなかなかに難しかった。ある機能Xを教えたいが、そのためには機能Yを知っていなければならず、機能Yを理解するためには機能Zの理解が必要といった具合に、C++の機能の依存関係の解決をしなければならなかったからだ。著者自身も苦し
Ruby Core Development 2019というタイトルでRubyKaigiのCFPにプロポーザルを書いたのだが、 もう一つ書いた方の話が採択されたのでその話はしなかった。 さて、今日はRubyコア*1の開発がSubversionからGitに移った節目でもあったので、そっちのトークで言いたかったことの一部を記事にしておこうと思う。 Subversion → Git 移行 [Misc #14632] 去年くらいから @hsbt さんが cgit というGitフロントエンドを使ってGitリポジトリの準備を始め Misc #14632、ついに今日正式にcgitの方がupstreamになった。平成の時代でSubversionでのtrunkのRubyコア開発は幕を閉じた。 この辺を進めているのは主に @hsbt さんな中、僕がこれを偉そうに書いたり今回のRubyKaigiで壇上でアナウンス
コンパイルの処理は大きく分けて下記の処理にわけられる。 プリプロセス コンパイル アセンブル リンク この記事では、C言語の Hello World を過程毎に追い、プログラムが出来上がるまでの流れを追う。 登場するファイル main.c - ソースファイル main.s - ソースファイルからコンパイルされたアセンブラソースファイル main.o - アセンブル後のオブジェクトファイル main - 出来上がったバイナリ ソースコード 普通の C 言語の Hello World. 下記コードを main.c として保存する。 #include <stdio.h> int main(){ printf("Hello world!\n"); return 0; } プリプロセス プリプロセスとは、マクロの展開や #include や #ifdef などのディレクティブの処理が行われることを指
いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire
僕は先日、「コンパイル時Cコンパイラ」なるプログラムをつくって、公開した。 「コンパイル時Cコンパイラ」とは、コンパイルするとC言語プログラムのコンパイルが行われるというようなC++プログラムである。 C++のコンパイル中に C言語プログラムのコンパイルを行う、 "コンパイル時Cコンパイラ"をつくりました #ELVMhttps://t.co/kKiLU3rLFX— うどん (@kw_udon_) 2016年11月18日 自分で書いておいてなんだが、「なんのこっちゃ」という感じではある。(ちゃんと記事中で説明する。) 実際、変なプログラムではあるのだが、とても嬉しいことに多くの人に面白がっていただき、予想だにしなかった大きな反響をいただいた。 Hacker Newsで1位になったり、LLVMの公式ブログで紹介されたり、果てはC++の作者であるBjarne Stroustrupにも言及されるに
三行で頼む コンパイラが斜め上の最適化をするようになったからnull安全ないと怖いよね 一行で終わっちゃった。 本文 最近、ツイッターを見ていると、プログラマの間でnull安全という言葉がバズっていますね。私も次のようなエントリを楽しく眺めていた訳です： null安全でない言語は、もはやレガシー言語だ null安全はいいぞ。だって、型安全はいいぞ。 null安全を誤解している人達へのメッセージ さてそんな中、少しだけ私の心に留まったエントリがこれです： null安全な言語は、本当にゼロコストか これを読んで、私がまず直感的に思ったのは、むしろもはやnull安全のない言語はダメかもしれないということでした。こう書くと、このエントリの内容を否定してると誤解されるかもしれませんが、全くそんなことはありません。このエントリの筆者さんもnull安全の有用性を否定しているわけではないですし、私も古いタ
エラーを引き起こすコメント行 とあるＣ言語のプログラムを Windows 上の Visual Studio 2008 で編集・作成し、完成したソースコードを Linux マシンにコピーし gcc でコンパイルしてデータ処理を実行という流れで作業を行っていました。 その際に、ある全角文字を含むコメント行が存在するとエラーが生じるという現象に遭遇しました。 このエラーを再現するプログラムは以下のようなものです。 #include <stdio.h> int main(void) { int n = 10; // n の値により分岐可能 if(n > 5){ printf("Large\n"); }else{ printf("Small\n"); } return 0; } このソースコードは、Visual Studio上では何の問題もなくコンパイル、実行できます。 しかしながら、Linux の
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,
GNU ProjectとGCC開発者は4月22日、「GNU Complier Collection（GCC）5.1」」を公開した。Cのデフォルトモードの変更、最適化エンジンの強化、JITコンパイラ対応など多数の機能が盛り込まれている。 2014年4月に公開されたGCC 4.9に続くもので、GCC 5系で最初のリリースとなる。変更点としては、まずCのデフォルトモードが-std=gnu89（GNU89）から-std=gnu11（ISO C11ベースのGNU11）に変更された。また、C++ランタイムライブラリlibstdc++ではデフォルトで新しいABIを利用するようになっている。古いABIのサポートも継続するデュアルライブラリとなり、「_GLIBCXX_USE_CXX11_ABI」パラメータで利用するABIを設定できる。libstdc++ではC++11のサポートが完全対応となった。また、C++
C++11/14の採用が進んでいないのはだいたいRHELのせい
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実装に不具合が色々あってあまりお勧めできない。これがあと何年も使わ
GNU EmacsのGrand Unified Debugger(gud.el)にLLVMデバッガ(LLDB)の基本的なサポートを追加する動きに対し、Richard M. Stallman氏が反対している。Stallman氏はGNUパッケージに対して組織的な攻撃が行われているようだと述べ、戦略的な反応をするようGNUプロジェクトに呼びかけている。メーリングリストでの彼の発言は、GDBなどとともにEmacsで利用可能なデバッガとして、LLDBをサポートするパッチの登場を受けたものだ。他のEmacsの開発者は、EmacsがWindowsやOS XをサポートしているのにBSDライセンスのコンパイラ/デバッガをサポートしない理由はないなどと述べ、RMSの発言をあまり重く受け止めてはいない。Emacsのメンテナーは見当違いの主張だと述べ、LLDBサポートをマージする決定に影響を与えるものではないとし
LLVM is a robust system, particularly well suited for developing new mid-level language-independent analyses and optimizations. Googleは1月5日(米国時間)、「LLVM Project Blog: Using clang for Chrome production builds on Linux」において、Linux向けのGoogle ChromeのビルドをGCC 4.6からLLVM Clangへ変更した理由を説明した。昨今、デフォルトコンパイラをGCCからClangへ変更するプロジェクトやプロダクトが増えている。 GoogleはGCCからClangへ移行した理由として、次の2つを挙げている。 Linuxを利用しているChromium開発者の多くがClang
gcc が出す以下の警告。消すのは簡単で EOF に改行を一つ入れれば良い。でもこれ何が悪いのか分からなかった。 warning: no newline at end of file コンパイラが出す警告だから絶対に何か意味があるはず。調べてみると意外にもテキストファイルの定義にたどり着いた。 ということで POSIX 的に行は改行で終了していて、テキストファイルは行の集合だからファイル末尾には必ず改行が来ると。 Text File / Line - odz buffer Definitions - 3.392 Text File Definitions - 3.205 Line つまり POSIX はテキストファイルにもちゃんと定義を定めていて、最後に改行が無いファイルはその定義に違反するから警告を出す。 There is also some confusion as to whethe
In this post, we’ll examine what __attribute__ directives are and how they can be used in development. The goal is to establish a value to using __attribute__ directives in any codebase and to provide a starting point with some directives that anyone can start using right away. What are __attribute__ directives? When should I use an __attribute__ directive? Recognizing the dangers of misusing an _
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【iOS,Android】信じがたい！ うっそ！ ゼロ除算の考察の行方！
