そろそろ食費にすら事欠くようになったのでバイトをすることにした。一日数時間の掃除だ。おそらく、C++本の執筆にはさほど影響しないだろう。 結局、結果からいえば、当初の目論見であった、貯金の続くうちに、全力でC++本を完成させるというのは、無理だったわけだ。やれやれ、最初から働きつつ執筆すべきだったのか。 C++本は、ようやくオーバーロード演算子まで進んだ。といっても、途中のBasic Conceptsに当たる部分は飛ばしたし、コピーとムーブも飛ばした。コピーとムーブはどう書けばわかりやすくなるのか分からない。純粋なコア言語機能だけ説明してもわかりにくいし、かといって、プログラミングテクニックまで説明するのは本書の範疇ではないように思う。コア言語に絞ってさえこの分量なのだから、最初の壮大な野望通り、標準ライブラリまで手を広げようと思ったら、いつまでかかるか分からない。 そもそも、一冊のまとま
Version 2006-05-24, by Eelis This software has been released into the Public Domain Table of contents Tutorial Changelog Header analogliterals.hpp 1. Tutorial (download as .cpp) // Note: The following is all standard-conforming C++, this is not a hypothetical language extension.#include "analogliterals.hpp" #include <cassert> int main () { using namespace analog_literals::symbols;// Consider: unsi
cppllとboostjpに送ったメールですが、こちらにも再掲します： == ついに ねんがんの 国際標準をてにいれたぞ!： C++0x、全会一致で承認される C++0xが満場一致で国際標準として承認されました。 やりました！ 日本からも全員が賛成票を出していました。 さて、C++11の仕様が固まってこれから大きな変更はないでしょうから、 そろそろC++11の解説サイトやリファレンスを整備していかなくてはいけません。 cppll, boostjpのコミュニティで集合知としてのリファレンスサイトを作っていきたいと考えています。 私の方でGoogle Sitesのcpprefjpを作成し進めているのですが、人手不足でなかなか進んでいない状況です。 cpprefjp - C++日本語リファレンス この活動に興味を持ち、コアメンバとなってくれる方を募集しています。 C++11が広く使われて欲しいと
2chのC++相談室で、色々と議論が巻き起こっているようだ。少なくとも一人は、規格を参照しているようである。C++の規格上の、overloadとoverrideとhidingについて、分かりやすくまとめてみた。オーバーロードとオーバーライドは、単に音訳した際に、日本人にとって音が非常に似ているという問題に過ぎないのだが。 同じ名前で、他のシグネチャの違う関数セットのことを、関数のオーバーロード（overload）という。 void f(int) ; void f(double) ; この例では、void f(int)とvoid f(double)は、オーバーロードされた関数のセットである。 Derived classがBase classと同じvirtual関数を宣言しているとき、Derived classのvirtual関数は、Base classの同virtual関数を、オーバーライド
「優れたPerlプログラマを見分ける27の質問」の日本語訳 - Islands in the byte stream, Javaプログラマであるかを見分ける10の質問 - やさしいデスマーチ を見ながら C++ だとこれくらいかなぁと取りあえず作ってみました．前半は単純な機能の説明，後半は実際にどのように使って（使い分けて）いくかについての質問になっています．選択基準としては，特に後半部分は，自分が観測できている C++ 界隈で論争になったトピックを中心に取り上げています． iterator の役割について説明せよ． *_cast およびCスタイルのキャストそれぞれについて概要を説明せよ． overload と override と hiding の違いについて説明せよ． const の機能について概要を説明せよ． 多重継承について概要を説明せよ． ポインタの使用方法について，メモリーリー
C++ Advent Calendar に参加してみました。 どうせ C++ の頭おかしい人達がいっぱい集まってるので、そっち方面はその辺の人に任せるとして、何かこう曖昧な話をだらだらと書いてみます。 コーディング規約について コーディング規約は、言語のコードをある特定の方向へと誘導することができます。まあこの特定の方向の先にあるのがひどいプロジェクトの成功だといいのですが、よくとんでもない方向へと突き進んでいることがあります。 何でそうなるのかって考えると、どの方向へ進もうとしているのかというのが明確にされていないということなんじゃないかと思うわけです。つまり、何を目的としてこのコーディング規約は作られたのか、誰に対してのコーディング規約なのかということです。 特定のプロジェクトを成功へ導くために作られたのか、多くのよくありそうなプロジェクトのためのひな形として作られたのか、バカ除けのた
組込環境というのは、メモリが数MBしかなくて（例えば4MB) プログラムのブートサイズにも限界がある環境の事です。 例外をコンパイラオプションでoffにする 「例外を使った方が安全です！！」 という言葉をはねのけて必ず「コンパイラのオプションで」offにする。 try、catch、throwを使わないということではない。 暗黙にコンパイラが例外のコードを生成しようとするのを停止させること。 例外にコードを使われると書くことができるコードが減ってしまいます。 最悪ブートができなくなります。エラーはassertでトラップしましょう。 特にC++の例外安全性を理解し、使いこなせる人は少ないので無闇にonにすべきではないです。 例外安全性を理解し、設計できる力のある人はほぼいません。 - RTTIをコンパイラオプションでoffにする 「dynamic_castの有用性が！！！」 という言葉をはねの
C++0x で提案されているユーザー定義のリテラルを使用すると以下のようなことができるようになる "Hello"s // std::string 101011100011b // binary literals 123km // unit is kilometers リテラルを定義するには、以下のような演算子を定義する X operator""suffix(const char*); X x = 1234suffix; // operator"suffix"("1234"); この場合、operator""suffixの引数は NULL 終端の文字列となる Variadic Templates を併用すると、リテラルを char 型の コンパイル時定数とすることができる template <char...> X operator""suffix(); X x = 1234suffix; /
C++ は JS ほどじゃないにせよ、誤解されてきた言語だと思います。いや、複雑だとかいうのは誤解ではなく紛うことなき真実なのですが、その複雑さがただパラノイアから来た複雑なだけのものではなく、一応の有用性を伴うものだ…っていやそれはわかってそうな気はするので、誤解というほどのことでもないわけですが、昨今に比べて、なんか有用そうなものである、という認識は低めだったように思います。 ただ今度は、なんか関数型な雰囲気らしーぜ、というだけの単語が一人歩き気味な気がします。なんかわからんけど C++ すげー、みたいな、一昔前の Haskell が得ていたようなイヤな地位をゲットしているような気がして、それはそれで別の種類の、ある種の誤解であるように思ったのでした。 というわけでマルチパラダイム言語 C++ について、関数型言語としての機能について僕の見方を。 まず絶対に意識して欲しい部分なのですが
SOFSはC++で書いてた。C++といえば、僕の趣味は、ときどき、C++の素晴らしさについて考えることなんだけど、そういう話。 まず、C++に触ったことないのに、どっかの誰かの受け売りで、「C++はキモくてヤバい」というような考えを抱いてる人がいたとすれば、それは、まあ、つまらない人生を送ってるよね、というような話なのである。 確かに、C++の素晴らしさは、大体にして時間の無駄なので、わざわざ時間を割いて勉強するものではないと思うのだけど、C++は、憎むべき点が山のようにあるのと同じように、愛すべき点も他の言語の愛すべき点を++したぐらいはあるのだ！ どっかのだれかの受け売りでC++に全く触らないのというのは、非常に正しいのだけど、間違っているのである！STL極めて、Boost極めて、その後で、「やっぱり、まともな構文とまともなコンパイル時間と、まともなエラー表示が欲しいわ」と、そこまで至
google-perftoolsというx86,x86_64,ppcなUNIX向けのプロファイラの(cpu-profiler部分)を、armなLinuxに対応させてみました。何かの役に立つかもしれないので、patchおよびpatch作成作業のメモを載せます。arm-v5tアーキテクチャ(ARM9系)向けの移植です。 Linux/ARM向けのソフトウェアのパフォーマンスを解析したいなぁと思うことがあったのですが、OProfileはカーネル入れ替えがめんどくさい、gprofはプロファイル専用のバイナリを作成するのがめんどくさい、プロプラな奴は興味ないということで移植しました。移植の方がめんどくさいだろという話もありますが。perftools自体の説明はこちらが便利です。あーそういえばAndroidもARMでしたっけ? パッチ http://binary.nahi.to/google-perfto
http://d.hatena.ne.jp/m-hiyama/20060317/1142559097 に共感を覚えつつ。 Ruby って Kernel#String とか定義してあるのね。 require 'complex' すると Kernel#Complex とかも組み込まれる、と。まぁ必要なクラスだけ定義するのが正解なんだろうけど、これって別に言語レベルでシンタックスシュガーにしてくれてもいいレベルな気もするなーと思った。あとついでにライブラリで実現できるようなものを作ってみた。 def method_missing(name, *args) if (name.to_s =~ /^[A-Z]/) Kernel.const_get(name).send(:new, *args) else super(*args) end end if __FILE__ == $0 p Time.new
1985年、AT&TのBjarne StroustrupがC++をこの世に送り出しました。その後C++は様々な拡張を繰り返しながら進化してきました。 1991年、ISOはC++の国際標準(standard C++)を定める作業を開始しました。標準C++の最終草案は1997年にISO C++標準化委員会に承認されました。 標準C++が規定するのは言語仕様だけなく、C++標準ライブラリも規格の中で明確に定められています。それまでC++のライブラリといえばiostreamぐらいのものでしたし、それもあくまで"事実上の標準"でしかありませんでした。 そしてそのC++標準ライブラリの一部として組み入れられたのがSTL(Standard Template Library)です。すなわちSTLは標準C++の仕様の一部ということです。 僕がSTLを知ったのは1995年、いくつかのコンパイラがtemplat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く