CとC++の違い： Basic Concepts編
京都C++勉強会の宣伝のために、CとC++の違いを、少しづつ解説することにした。 江添とボレロ村上の京都C++勉強会が、12月16日に行われる。これを書いている時点では、まだ空きがあるので、最新のC++14の新機能と、コンパイル時レイトレーシングを勉強したければ、ATNDで参加申し込みをせよ。 江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド C++はCの完全互換ではない。Cのあまり良くない部分は、変更して改良した。ここでは、そのような変更点のうち、互換性に特に問題のあるものを取り上げる。 tentative definitionの有無 C言語には、tentative definitionという機能があった。以下のようなコードが合法になる。 int i ; int i ; // well-formed in C, ill-formed in C++ C++にはOne Def
Clangで-std=c++1yがいまだに使いにくい事情
ClangがC++14の機能完全に到達したことはすでに述べた。これはつまり、最新版のClangで、-std=c++1yを指定すると、現在のC++のドラフト規格の、動く実装が手に入るということだ。 これは素晴らしいことだ。 しかし、いざ実際にUbuntu 13.10でClangのSVN HEADを自前ビルドして使ってみようとすると、以下のようなエラーが表示される。 /usr/include/c++/v1/cstdio:156:9: error: no member named 'gets' in the global namespace ヘッダーファイルを一切includeしなくても、このエラーは表示されてしまう。 この事情は・・・結構複雑なのだ。 C++14では、Cの標準ライブラリは、C11のものに合わせられた。C11の標準ライブラリでは、とうとうあの忌まわしき太古の呪いである、getsを
CiscoのH.264コーデックについて一言
どうも、あれは、Ciscoの提供するバイナリ（主要なプラットフォーム向けに提供されている）を使うときのみ、Ciscoが特許料を肩代わりするというものらしい。 ソースコードは公開されている。もちろん、ソースコードにはビルドスクリプトなども含まれる。当然ビルドできる。しかし、自前にビルドしたバイナリは、x264でエンコードしたりffmpegでデコードするのと同じだ。特許料の支払いを免除されたければ、Ciscoの公開するバイナリを使わなければならない。 つまり、CiscoはH.264の特許料免除と引き換えに、自前の得体の知れないバイナリを主要なプラットフォームにばらまく土壌を作り出そうとしているわけだ。はたしてそのバイナリは、公開されているソースコードからそのまま生成されたものであろうか。なにか悪意ある秘密の機能が含まれていないだろうか。 このことからも分かるように、もはや自由なソフトウェアは著
なぜGCCのCプリプロセッサーはlinuxという名前のマクロ名を定義するのか
Why does the C preprocessor interpret the word "linux" as the constant "1"? - Stack Overflow Why does the C preprocessor interpret the word “linux” as the constant “1”? | Hacker News 以下のCコードをコンパイルしようとするとエラーになる。 $ cat test.c #include <stdio.h> int main(void) { int linux = 5; return 0; } $ gcc test.c test.c: In function ‘main’: test.c:4:9: error: expected identifier or ‘(’ before numeric constant なぜ
初心者向けでFreeBSDベースのOS、JabirOS
http://jabirproject.org/ イラン産のJabirOSというものがある。これは、以前はUbuntuベースだったが、なんとFreeBSDベースに切り替えたそうだ。そのWebサイトに曰く（なぜかWebサイトのtitle要素がHomeになっていて、わけがわからないのでURLにした） Jabirプロジェクトは2012年にMuhammadreza HaghiriとReza Bagherzadehによって設立された。このプロジェクトは初心者向けでデスクトップ志向のオペレーティングシステムを目的としている。その後、Muhammad Esmaeiliがプロジェクトに加入した。そもそも、JabirOSはUbuntuベースのオペレーティングシステムだった。2013年、我々はLinuxからBSDファミリーに移行することを決定した。JabirOSはFreeBSDのforkとなったのだ。 新Ja
邪悪なSamsungのLinuxネイティブexFATのGPL違反問題だけは解消される。ただし問題山積みであきれ返るばかり
邪悪なSamsungのLinuxネイティブexFATのGPL違反問題だけは解消される。ただし問題山積みであきれ返るばかり [Phoronix] Samsung Properly Open-Sources exFAT File-System 少し前、邪悪なMicrosoftの特許汚染されたexFATをLinuxカーネルでネイティブにサポートするためのソースコードが、GitHub上で公開された。 問題は、そのソースコードは、邪悪なSamsungからの意図しないリークだったことだ。そのソースコードとは、邪悪なSamsungのプロプライエタリなタブレット製品で、exFATをサポートするために、バイナリブロブの形で配布されていたプログラムのソースコードだったのだ。 さらに問題をややこしくすることに、そのソースコードは、なんとLinuxカーネルのGPLシンボルを使っており、当然GPLで提供されるべきも
Shebangという謎な事実上業界標準について
Shebangとは、UNIXのシェルスクリプトの業界標準で、シェルスクリプトの一行目のコメントの、#!を意味する。sheが短母音か長母音か分からなかったので、英語ネイティブにたずねたところ、人によって意見が違う。短母音の方が多数派のようなので、一応シバンが近いものになるだろう。日本語版のWikipediaでも、シバンとしている。この機能には他にも多数の名前があるが、もっとも有名なのが、Shebangだそうだ。 その業界標準的な文法は、以下の通り（ただし、後述するように、この文字列の扱いについては違いがある） #! 文字列 [改行] 普通、実行権限のついたファイルは、標準のシェルで実行されるが、このShebangがある場合は、#!から改行までの間の文字列を、後述するバラバラな方法で解釈して、execで実行し、その際の引数には元のシェルスクリプトファイルへのパスが指定される。 問題は、このsh
LinuxカーネルのMLにおける悪口の励行についての議論勃発
Linuxカーネルのメーリングリストは、常に罵詈雑言に満ち溢れているが、そういうのは辞めて大人になろうという主張がSarah Sharp[1]によってなされた。なかなか面白い。 きっかけは、いたって日常的な罵倒混じりの議論に、Sarah Sharpが横槍を入れたところから始まった。 LKML: Sarah Sharp: Re: [ 00/19] 3.10.1-stable review On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org> wrote: * Linus Torvalds <torvalds@linux-foundation.org> wrote: On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote
MySQLの七年間修正されていないバグに七歳の誕生日ケーキが送られる
MySQL Bugs: #20786: mysqldump always includes AUTO_INCREMENT 2006年6月29日に報告されたMySQLのバグ#20786は、7年たった2013年6月29日になっても、なお修正されていない。そこで、このバグに対し七歳の誕生日ケーキが送られた。 バグの内容は、mysqldumpの出力が、--no-dataを指定しても、テーブル定義にAUTO_INCREMENT=xxxが含まれてしまうというものである。これはバックアップ目的にはふさわしいかもしれないが、開発目的のダンプにはふさわしくない。現状では、開発目的に使うには、ダンプ後のファイルを手動や、あるいはsedなどで書き換えなければならない。 期待される修正は、出力しないオプションを付け加えるか、--no-dataオプションが指定されたときは出力しないようにするというものだ。 変更自体
もし大工の採用面接がプログラマーのように行われていたら
If Carpenters Were Hired Like Programmers | DawO_od 面接官「なるほど、あなたは大工なのですね」 大工「そうです。私は大工として今までやってきています」 面接官「実務経験は何年ほどでしょうか？」 大工「10年です」 面接官「すばらしい。それはいい。さて、これから職場にふさわしいかどうか、いくつかの技術的な質問に答えてもらおうと思うのですが、よろしいでしょうか？」 大工「はい」 面接官「まず、弊社は茶色の家の建築が主な仕事内容でして。以前に茶色の建築の経験はおありで？」 大工「えーと、私は大工です。だから家は建てますよ。塗装の色の好みは人それぞれでしょう」 面接官「ええ、それはわかります。ですが、茶色経験は何年ほどでしょうか？」 大工「おいおい、分からんよ。建築したあと、どういう色で塗装されるかなんて私の知ったことじゃありません。たぶん、6ヶ
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年に著作権が切れるのだろうか。 詳しい経緯は、以下の
MPEG RVCからLLVMアセンブリを出力するJADE
江添亮 自由ソフトウェア主義者 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
本の虫: 記録からみるLinus TorvalsのC++観
On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Gitのソースコードを始めてみた時、2つのことが頭にひっかかった。 > 1. C++じゃなくて純粋なC。理由は不明。移植性とか言わないでよ。 > クソだ。 クソまみれなのはオメーの方だ。 C++は悲惨な言語だ。しかも、少なからぬ数のプログラマーが使っていて、完全無欠のどうしようもないクソを生成するのがめちゃめちゃ簡単になっているという点で、よけいに悲惨だ。マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 つまりだ：Cの選択は唯一のまともな選択なんだよ。Miles Baderがふざけて、「いやがらせによる追い返し目的」なんていってたが、実際のところ正しい。俺の出した結論では、プロジェクトにCよりC++を使いたがるプログラマーは、む
Mir上でうごくUnity NextのタブレットUIのデモ
江添亮 自由ソフトウェア主義者 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
KubuntuにおけるMir
Mir in Kubuntu | Martin's Blog Blue Systems社員でKDE開発者のMartin Gräßlinが、Mirについて書いている。 Jonathanのブログ記事にあるように、Mataro Sessions IIでKubuntuにおけるMirについて議論した。このことに関しては、あまり話したくない。しかし、自由ソフトウェア業界の流れからして、議論しなければならないし、我々の下流（KDEを利用する層）も、なぜ上流（KDE開発の本家）は、Mirを受け入れるのは妥当な選択ではないのかと判断したかについて知る必要がある。 これは、CanonicalがMirで生み出した多大な問題に焦点をあてるものだ。私はMirが選択肢に入らない理由として、単に、「Canonicalは糞だ」[1]と言うわけにはいかない。我々がMirと統合しない理由について、私は正当な技術的反論を打ち立
FedoraとUbuntuのLinuxカーネル設定の比較
jwboyer: Fedora and Ubuntu Kernel Config Comparison Red HatのJosh BoyerがFedoraとUbuntuのLinuxカーネル設定を比較している。 たまに、私は洞穴の中、つまりbugzillaから這い出てあたりを見回し、他のディストロのカーネルスペースがどうなっているのか調べる。今日、私はFedoraとUbuntuのカーネル設定の違いについて興味を持った。私は常々、カーネルは注目されるものの、ディストロの中では最も退屈なパッケージであると考えている。カーネルは動くべきであるし、良く動くべきであるし、それだけだ。ディストロを差別化するために存在するのではない。ディストロを動かすために存在するのだ。さて、私の説は正しいのか、あるいは設定の中に、あるディストロを別のディストロと差別化するための何かが含まれているのだろうか。さて、調べて
Linux Mintのno codec版で取り除かれているパッケージ
Linux Mintでは、ソフトウェア特許やDRMといった悪法のある日本やアメリカ向けに、一部の問題の有りそうなパッケージを削除したno codec版のISOイメージも用意されている。では、一体何が取り除かれているのか。 検索しても、取り除かれたパッケージの一覧が見つからなかった。とりあえず教えられたのが、Linux Mint 13の日本語ISOの時に、本家からのパッケージの差異を列挙したものだ。 [Linuxmint-jp-devel:58] Re: 日本語化されたISOの用意について。 なるほど、ほとんどのパッケージは、Ubuntuにも存在する。それも、Universeに存在するパッケージもある。 コーデックの名前通り、音声、動画フォーマットのエンコーダー、デコーダーが多い。 ただし、ひとつだけUbuntuのレポジトリにはないパッケージがある。w32codecsだ。Ubuntuのコミュ
VP9の完成が近い
江添亮 自由ソフトウェア主義者 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
例外中に例外を投げるとか二重例外はエラーという俗説について
いよいよC++の参考書の執筆も例外にまで到達した。例外は、規格の文面量だけで言えば短いが、詳細を解説するのは難しい。なにせ、まともに日本語で解説している本は皆無だからだ。ついでに、規格の文面のバグも発見した。これはすでに報告済みなので、次のC++規格では修正されるはずだ。 ちなみに、"C++ 例外"で検索して出てくる情報の大半が間違っているか、十分な詳細を解説していない。責任は規格違反な実装、特にMSVCにある。MSVCの挙動が全てだと信じる愚者が、規格を参照せずMSVCの挙動をもとに解説を書いているからだ。 たとえば、例外をハンドルしていない状態でオペランドのないthrow式を実行すると、std::terminateが呼ばれる。 int main() { throw ; // std::terminateが呼ばれる } あるC++解説サイトでは、何故かstd::bad_exception
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
