この記事は「Nim Advent Calendar 2021」の16日目の記事として登録させてもらっています。 C++のdynamic_cast C++にはdynamic_castというキャストがあり、これを使うと安全にダウンキャスト*1を行うことができます。 ここでいう「安全」とは、ダウンキャストの失敗を判断できるということです。 #include <stdio.h> class Base { public: virtual ~Base(){} }; class Derived : public Base {}; int main() { Derived* derived = new Derived; Base* base1 = derived; Base* base2 = new Base; printf( "dynamic_cast<Base*>(base1) = %p\n", dy
Results of the Grand C++ Error Explosion Competition 少し前に、C++のコンパイルエラーの長さを競うコンテストが開催されていました。 受賞のカテゴリは2つあり、ひとつめは最小コードで最大のコンパイルエラーを出した人、もうひとつは芸術的な評価による受賞です。 最小コードで最大のコンパイルエラー この部門で優勝したのはEd Hanwayさんという方で、ソースコード量に対して59億倍のコンパイルエラーメッセージを出力したそうです。 それには、自身を2回インクルードするという手法が使われていたそうです。 #include ".//.//.//.//jeh.cpp" #include "jeh.cpp" 次点として、インクルードに後方参照を使用した、7億9千万倍のコンパイルエラーを出力するコード： #include "set>.cpp" #incl
例えばこう、ディレクトリの名前とその中のファイル名を / でくぎって結合する関数を書くとします。引数が std::string でも使いたいし const char* でも使いたい、ということで、たいていは void JoinFilePathStr(const string& dir, const string& base, string* out) { out->clear(); out->append(dir); out->push_back('/'); out->append(base); }なんてのを書くんじゃないかと思います。この関数で問題になるのは const char* を渡すと不要な string object が一度できることで、敬虔な C++ 屋さんだと、 void JoinFilePathStr(const string& dir, const char* base,
こちらのスライド、発表自体を見てたので既に1回見ているのですが最近、たまたま見かけたのでもう1度見てみたら相変わらず面白かったので紹介。 C++の話（本当にあった怖い話） View more presentations from Isoparametric ! C++恐い!! スライドで紹介されてた書籍 C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series) 作者: ハーブサッター,アンドレイアレキサンドレスク,浜田光之,Herb Sutter,Andrei Alexandrescu,浜田真理出版社/メーカー: ピアソンエデュケーション発売日: 2005/10メディア: 単行本購入: 20人 クリック: 383回この商品を含むブログ (100件) を見るC++の設計と進化 作者: Bjarne Stroustr
れさぴょんはコンピュータ将棋の教育目的で書かれた、うさぴょんとは一応独立した、でも、うさぴょんのソースは大いに参考にした、そんなプログラムです。 名前は、「れっさーうさぴょん」の略です。 このソースは、VC++6.0向けです。VC++の6.0以降であればコンパイル可能だと思います。ただし、一応、他のコンパイラを意識して移植可能なように書いているので、ＢｏｒｌａｎｄＣ＋＋などでコンパイルすることもさほど難しくはないと思います。 2007年11月11日現在、以下のバグフィックス版をＣＳＡにライブラリ申請中です。 れさぴょんv3 ダウンロード ファイルはzip圧縮形式です。(ダウンロードサイズ 約35KB 展開後 約120KB) ファイルは、lzh圧縮形式です。（ダウンロードサイズ 約３２KB 展開後 約１２０KB） れさぴょん ダウンロード このバージョンが、正式にＣＳＡにライブラリとして登録
文字列操作の比較表: Ruby, Python, JavaScript, Perl, C++ Ruby, Python, JavaScript, Perl, C++ の文字列操作の比較表を作りました。配列操作の比較表の続編です。間違いなどがあったらご指摘いただけると助かります。 Ruby (String) Python (str) JavaScript (String) Perl C++ (std::string)
通りすがり (2009-09-16 18:09) > PHP以外の言語は「(略)」のに対し ここに挙げられている言語がWebアプリで使われる全ての言語ではない。 例えば、CやC++にはない。付け足せば、PHPやPerlなどのCモジュール内部で起こった不正な文字はスルーされうる。 よって、「Perl、Java、.NET、Ruby、PHPの中では」と書けば筋は通るが、「PHP以外では」は誤り。 そしてそんなことを、PHPの(脆弱性撲滅に注力している)開発者に言ったら、喧嘩を売られたと受け止められて当然。 PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14) というコメントが気になった。 C言語にある文字コード変換機能って言ったら mbtowc だと思うけど、mbtowc は無効なバイト列を受け取ると EILSEQ を返すことに
texturetool 独特のオプションを中心に、以下でその機能を詳しくご説明します。 圧縮率の選択 PVRTC 形式では、圧縮率は 1/8 か 1/16 に固定されており、 PNG や JPEG のように画像によって圧縮率が変化することはありません。これは主にハードウェアによる展開とランダムアクセスの効率を優先した結果でしょう。 どちらの圧縮率を使用するかはオプションで指定でき、 --bits-per-pixel-4 なら 1/8 、 --bits-per-pixel-2 なら 1/16 になります。指定がない場合はデフォルトで 1/8 が採用されます。とうぜん 1/8 の方が画質は良いので、画質とサイズのどちらを優先するかで選択してください。 圧縮誤差の処理方式の選択 圧縮率と同様に、圧縮誤差の処理方式も 2 種類から選べます。 RGB の各チャンネルに誤差を均等に分散する --cha
GUI grepツールの調査過程は一応一段落し、当初のもくろみ通り製作に入ろうとしています。 今は特に苦もなく使えそうなPython, C++, C#のどれを用いるか検討中。 大量のファイルへのアクセスと正規表現のマッチは割と重い処理になりそうなので、実際にコードを書いて比較しています。 まず生grep。find | xargs grep '...'。直接Cで書かれていることを考えると、最速の基準として考えて良さそうです。日英対訳文対応付けデータ [1]をデータセットとして実験していますが、1.1秒くらいで2000ファイル近くのスキャンが終わる。 次に、書きやすそうなところでPython (re)でやってみました。所詮LLだし、結果には全然期待していません。 ところがところが、何故かこれが滅茶苦茶速い。 特に最適化したコードの書き方でもないんですが、1.6秒くらいで終わる。殆どC同等の速さ
Google が Google Code でオープンソースとして公開しているソフトウェアの解説シリーズ(前回のエントリ)の第 4 回です。今回は Performance tools について紹介します。この Performance tools は、実際に Google 社内で広く使われており、特に、C++ でテンプレートを使用するマルチスレッドアプリケーションを開発する際に役立ちます。Linux 環境を主に対象としています。 Performance tools とは? C や C++ でプログラムの書いたことのある多くの人は、「プログラムを高速化したいけれど、どこが一番のボトルネックか分からない」とか、「メモリリークがあるようだけれど、どこで発生しているか分からない」といった問題で苦しめられた経験が一度くらいはあると思います。もちろん、こうした問題の解決策として、アドホックにプログラムをチ
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
現在大学1年生の人で3年後には NAIST に (というか松本研に) 来たいという人から「どんなプログラミング言語やっておくといいですか」と質問されたりするのだが、なかなか答えるのは難しい。自分は Perl → Python がメインでときどき C++/C# を使ったりするのだが、どれが一番いいかはなんとも言えないので、自然言語処理以外に転向する可能性も考えると、C とか C++ とか Java とか(授業でそちらをやるのであれば)を最初の武器に選んだ方がいいのでは、と思ってはいる。 そんなこんなで最近 Hal Daume III (機械学習を用いた自然言語処理では非常に有名な人) のブログで Language of Choice というタイムリーなエントリーが出ていたので、紹介すると、「それなりに大きな自然言語処理のプロジェクトでどのプログラミング言語を使うのか」というアンケート結果が出
雑記普段はPHPをメインとしてWebプログラムを楽しんでいるのですが、今年の初めくらいからゲームプログラムにも挑戦しています。言語はC++で、DirectX9プログラムをしています。昔いじったことのあるHSP*1と比べて遥かに難しくてびっくりするのですが、Webプログラムとはまた別の方向で楽しいです。ただ、特につらいなと思うのが、情報の少なさです。一応SDKのヘルプは充実しているのですが、情報が豊富なPHPと比べると色々なところで厳しさを感じます。そこで、今参考にしているサイトや書籍についてメモ代わりにまとめることにしました。もし、他にもいい本やサイトがあれば是非教えてください。 対象とするのはあくまでC++とDirectX9の組み合わせですが、ものによっては参考になると思います。反対に、C++向けじゃないけど参考になるものも載せています。C++の勉強ゲームプログラムをするためには、ある程
科学者とあたまを書いたひとだけれども、この名前どっかで聞いた事があるなと思ったら, 昨日劇団青年座の人の講演で聞いたのだった。 「フユヒコ」という劇団青年座の公演が明日NHKで放送されるらしいです。冬彦ってのは寺田寅彦のペンネームらしい。 http://cgi4.nhk.or.jp/hensei/program/p.cgi?area=001&date=2008-12-12&ch=31&eid=9950 おもしろそうだから観てみようかな。 ところで小柴先生が同じような事を言っていたのを思い出した。このインタビューは面白い。 一流の理論家は、「自分の理論では、ここまでは使えるけれど、これから先は分からない」という適用限界をいつも意識している。ところが二流の理論家というのは、自分が名前を覚えた、あるいは、使った理論で何でもやれると思ってしまう。二流の理論家に困らされるのは、新しい実験計画が出てき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く