サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
toge.hatenablog.com
TL;DR 文字列から浮動小数点数に変換するならfastfloat使いましょう。 私が試せる環境で比較する限り、とても速いです。 細かいことが気になります C++でちょっとしたプログラムを書くときにいつも気になるのが 「文字列データから指定データ型への変換処理をどうやって効率的に書くか」 です。私だけかもしれませんが。 特に悩んでしまうのが「文字列→浮動小数点」です。 std::scanf, std::stringstreamを使うものは大抵すごく遅い std::strtodstd::stodはstd::stringへの変換が入るので避けたい std::from_charsは(libstdc++が)浮動小数点型に対応していない boost::sprit::qiが何故か速いのだけれどこのためにboost::sprit使うのは重い と色々制約が多いのです。どうにかならないものか。 fast_f
諸般の事情で社員寮に引っ越すことになりました。 この前更新費を払ったばっかりなのに・・・痛いな。 なによりも、当分の間週末は引越し準備になってしまいそうなのが、いやん。 id:toge:20060727#1154020692 7/27に嵌ってたことの原因が判明。まあ、あれだ、変なことするなら"-Wall"はつけろってことだ。 warning: dereferencing type-punned pointer will break strict-aliasing rules というwarningが出てたのね。さて"strict-aliasing"は"-O2"で有効になる"-fstrict-aliasing"のこと。 ということで、このwarningが出ているオブジェクトだけ"-fno-strict-aliasing"を指定すると・・・、gcc 4.x系でも問題なくなりました。 以下の参考資
Version 1.39.0 1.38の新機能を1回もいじらないうちに1.39が出てしまった。 まあ、今回の更新は私的には小さなものなので、まだ追従可能かな? うーん、昨日はさんざんメモリを消費して悩ませてくれたDisplayLinkManagerだけど、今日は60MByteぐらいで安定している。 でも60MBも使っている時点で異常だよな・・・。 まったくそのとおりの考え方をしていて、実際に使いまくっています。 その例: reflect.lua - reflectblade - シンプルなボートレースゲーム - Google Project Hosting LuaConstants.cpp - reflectblade - シンプルなボートレースゲーム - Google Project Hosting LuaUtil.cpp - reflectblade - シンプルなボートレースゲーム
なんか3人の方にブックマークして頂いたようなので、もう少しマシな情報を。 RapidXMLに簡単にXMLを処理させてみました。 お手頃なXMLのデータがなかったので、自分のはてなブックマークページをローカルに落として使いました。 程よくタグの綴じ漏れがあるデータだったのでRapidXMLの評価には返ってよかった。・・・でもimgとかmetaとかlinkとか閉じていないのはダメだと思う。 サンプルプログラムはこんな感じ。本家より少し変な事もやっているのでちと長くなってます。 あんまり深くは触ってないけど、TinyXMLよりもはRapidXMLの方が楽に書けると思う。 #include <iostream> #include <fstream> #include "rapidxml.hpp" int main(int argc, char* argv[]) { // check paramet
久しぶりにC++でXMLを扱おうと思い立ち、さて何を使ったものかなぁと考えたのです。 さすがに未だにTinyXMLってわけにもいかないだろう、POCOの中のXMLか、wmXMLか、はたまた無難にlibXMLか?・・・といろいろ探っていたのですが、どうもしっくりこないのと、導入するのにでかすぎるんですよね。 小さいツールを書くのでライブラリも小さくあってほしいなぁ、なんていうちょっとしたこだわり。 で、TinyXMLに匹敵するものはないかなぁと探していたら、同じことを考えていた人にぶちあたりました。XMLのC/C++実装 この中で「おおっ」と思ったのが、そこで紹介されているのがRapidXML。 ヘッダファイルのみで構成 TinyXMLの50倍以上速い libxmlでか過ぎ Boost極力使ってます とか、かなり私好みというか、数年前からのC++の潮流にあったライブラリ。 早速使ってみると、
少しは役に立つものを書いてみよう。 近頃調べているのは圧縮率はそこそこでいいから、高速に圧縮・解凍ができるライブラリ。 色々あるんだけど決定版と呼べるものがないのが厳しいところ。今のところ総合的に優秀なのはQuickLZで、うまくやれば速そうなのがlzturbo、ちょっと落ちる所にFastLZとLZFがいるって感じかな? 個人的には今のところLZFを捨てる理由がないので使い続けようかなと。 LZO かなり昔からある軽量圧縮ライブラリ。GPLなので私が使ったことは一度もなかったりする。 まだ開発が継続されていてびっくりしてしまった。近頃はLZO proなんていう商用製品も出しているみたい。 昔はオンリーワンのライブラリだったけど、他のライブラリとのベンチマークを見る限り、今となっては他のライブラリとどっこいどっこいの性能しかなくなってしまったように思う。 しかし安定した圧縮率と圧縮・解凍速度
id:higepon:20051229:1135837892 ひげぽんさんの日記より、メモリー周りの問題チェックを行ってくれるvalgrindを使ってみました。 MMXとかSSEとか使っていると実行に失敗してしまうので-marchとか-msse -mmmxとかしないほうが良いみたいです。 相変わらずOpenGLなプログラムだと馬鹿みたいにParam周りのメッセージが出まくる。こういうメッセージが鬱陶しい場合には、次のようなファイルを作って、--suppresions=hoge.supp みたいに渡すといいらしい。 { OpenGL_driver bug Memcheck:Cond obj:/usr/lib/libGL.so.1.0.8178 } しかしこの定義を細かく書くのが思いの他面倒臭い。まあ、今のところ --show-reachable=yes で出てくる reachable blo
まずい。 連休中、あまりに健全な生活を行っていたために、平日帰宅すると寝てしまいます。 ちっとも勉強が進みません。 まあ、健全な生活が送れてますけどね。 ぱぱっと実装完了。 DOMを使ったことがあるなら、簡単に利用出来ます。 いやぁこれは便利だわ。 敢えて文句を言えばC++のソースなのに#incldue とかしているのとか、ヘッダで無駄なファイルをインクルードしているのが気にいらんが。 せっかくの機能なのになかなか使われないみたいですね。便利なのに。 googleで"mudflap gcc"と指定してもあんまり情報がないのが残念です。 少しでも普及するように、以下のmudflap記事を適当に訳してみました。 http://gcc.gnu.org/wiki/Mudflap%20Pointer%20Debugging 続きを読む id:m107さんとかid:halo_w2さんが文字描画やってい
このページを最初にブックマークしてみませんか?
『toge's diary』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く