No.00 Introduction (2011-01-07 更新) No.01 namespace rel_ops, utility (2011-01-07 更新) No.02 std::move, utiliy (2011-01-16 更新) No.03 std::move_if_noexcept, utiliy (2011-01-17 更新) No.04 std::swap, utiliy (次回予定)
No.00 Introduction (2011-01-07 更新) No.01 namespace rel_ops, utility (2011-01-07 更新) No.02 std::move, utiliy (2011-01-16 更新) No.03 std::move_if_noexcept, utiliy (2011-01-17 更新) No.04 std::swap, utiliy (次回予定)
The Microsoft C/C++ compiler (MSVC) predefines certain preprocessor macros depending on the language (C or C++), the compilation target, and the chosen compiler options. MSVC supports the predefined preprocessor macros required by the ANSI/ISO C99, C11, and C17 standards, and the ISO C++14, C++17, and C++20 standards. The implementation also supports several more Microsoft-specific preprocessor ma
この記事は C++ Advent Calendar 2010 の参加記事です。詳細は以下。 C++ Advent Calendar jp 2010 : ATND 今日はクリスマスですし、みなさんお忙しいと思いますし、それに僕はあんまり変態的な事を書けませんので…。*1 そんな中であまりTwitter上であまり話が出てこない(気がする)boost.interprocessのほんの一機能について備忘録的にまとめてみました。 Memory Mapped Files? boost.interprocessは基本的に共有メモリの強力なラッパライブラリなのですが、その機能としてMemory Mapped Filesというものがあります。これはファイルをメモリとほぼ同じ感覚で操作するための機能です。ファイルを開いてそれに仮想的なアドレスを与え、あたかもメモリ上にあるデータにアクセスしてるかのような、まさ
C++初心者の私がC++をやめたくなった瞬間。 なにをいまさらな。 はじめに C++のstreamはとても良くできていて、これを用いたライブラリを作りたいのだけど、 本当に(主にパフォーマンス的な理由で)大丈夫なのとかそういう話。 初めにお断りしておきますが、以下の内容はすべてlinux+gcc4.3での話です。 streamは遅い ふつうにistreamからget()して、ostreamにputしてるとめちゃくちゃ遅い。 C言語のgetchar, putcharより10進数で1.5桁ぐらい遅いよ。 istream::readとかででかいブロック読めば大丈夫なのだけど、 細かい単位で読みたいことの方が多いよね。 そういうわけで、そういう場合にも速く転送することが可能なのかどうか調べてみる。 テストプログラム istreamの内容をostreamに転送するプログラムを6通り書いた。 その1:
2005-08-14 組み込み開発では、しばしば型の境界調整への配慮が必要になってきます。ところが、境界調整の要求サイズは完全に処理系に依存しますし、境界調整を調べるための専用かつ標準的な機能もないのが現状です。 確かに境界調整を調べるための専用の機能はありませんが、既存かつ標準の機能の組み合わせで調べるための方法はあります。残念ながら、この方法はCとC++では異なるものになってしまいます。この辺りはCとC++の微妙な非互換性に起因しているのです。 まずはCの場合についてです。これは<stddef.h>で定義されているマクロoffsetofを使うことで実現できます。 #define alignof(type) offsetof(struct { char a; type b; }, b) char型と調べようとする型のフィールドからなる構造体を使って、調べようとする型のオフセットを調べれば
http://d.hatena.ne.jp/Cryolite/20051021#p1 の問題に対する解答. まず大前提として,未初期化な領域に配置構文 new を用いてオブジェクトを構築する手法は潜在的な危険が多く,本当にそれが必要な場合以外は用いないという方針が基本であることを確認しておいてください. まず最初に自動変数として(スタック上に)確保した char の配列に任意のオブジェクトを構築する場合についてです. class MyClass { ..... }; int main() { char buf[sizeof(MyClass)]; MyClass *p = static_cast<MyClass *>(static_cast<void *>(buf)); ::new (p) MyClass(); ..... // #1 p->~MyClass(); }上のコードはアラインメン
Webアプリケーションを作るとき、HTMLを生成するテンプレートエンジンをよく使いますが、これはパラメータに応じて様々なコードを生成する自動生成ツールであると言えます。 mplexは、プログラムを生成するためのテンプレートエンジンです。 実は MessagePack-RPC for C++ の実装に使っています。似たような関数をたくさんオーバーロードするために活用しています。(そろそろ可変長templateを使いたいですねぇ) 昔はeRubyを使っていたのですが、HTML用のテンプレートエンジンはソースコードがあまりに読みにくくなるので自作しました。 mplexを使うと、普通のプログラムの中にRubyのコードを埋め込むことができます: // クラスを4つ生成 %4.times do |i| class Test[%i%] { public: %if i % 2 == 0 int even;
Boost.DateTimeが使いにくかったので、日時計算を目的とした簡単なDateTimeライブラリを書きました。 SHAND_DATE_TIME_CUSTOM_NOW_TIMEをdefineすることで、現在日時を返す関数を書き換えることができるようになるので、Testableです。 フォーマット指定は、strftimeを参考に、よく使うものだけを採用しました。 shand/date_time.hpp #ifndef SHAND_DATE_TIME_INCLUDE #define SHAND_DATE_TIME_INCLUDE #include <cstddef> #include <ctime> #include <map> #include <boost/xpressive/xpressive_static.hpp> #include <boost/xpressive/regex_a
C++AdventCalendarの記事です。 さて、 生配列使ってますか? tr1::array(boost::array) 使ってますか? 生配列使っていると答えた貴方、 →まず死ね。 はい、arrayが常識ですよね。 さて、とはいえ、 「テンプレートを使うと遅いしコードがでかいし」 「生配列が一番速いしコードが小さいし」 「なのでテンプレート禁止」 なんて話を聞くこともあるかと思いますが、 こういう事をいう人は大抵「テンプレートを書いたことがない」のに言ってます。 なぜか? こういう人が本当に心配しているのは「テンプレートが肥大化すること」じゃないのです。 「テンプレートが書けないし読めないのを認めたくないからです」 多くはCの老害だからですが、そういう人は放っておいてC++な人はきちんとテンプレートを使いましょう。 だって多くのテンプレートのコードは大きくもなければ非効率でもないか
はじめに 以前から SWIG を使った Python・C/C++の連携に興味がありましたが、Instant というモジュールを使えばもっとお手軽に出来ることを知り、ちょっと試してみました。 Instantとは Python から C/C++のコードを呼び出すためのモジュールです。 (Webサイト) http://heim.ifi.uio.no/~kent-and/software/Instant/doc/Instant.html Python と 他の言語を連携させるツール類は Instant 以外にも色々ありますが、Instant には次のような特徴があります。 Python のコード中に、インラインでC/C++をインラインで記述出来る。 WebサイトのTOPには、次のようなサンプルが載ってます。 from instant import inline add_func = inline(
Short Contents Copyright (C) 2008-2024 FSF Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. This is the top level of the libstdc++ documentation set. The documenta
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く