C++ / Boostの新たな非営利団体The C++ Alliance - Faith and Brave - C++で遊ぼう
The Future of Boost (From Vinnie Falco) (2023-05-08 15:46:03) - Boost developers' mailing list Boost C++ Librariesのコンサルティング会社BoostProがなくなって以来、Boostはリーダー不在でふわふわした状態でした。 Boost.Beast作者のVinnie Falco氏が創設した新しい非営利団体The C++ Allianceでは、Boostを復権させるようBoostの基礎部分を刷新し、C++全般を支援していくことを主な目的としています。 この団体では、Boost.Asio作者のChristopher Kohlhoff氏を雇用し、フルタイムでオープンソース活動をできるようにしています。ほかにもスタッフエンジニアとして、Boostのリリースマネージャを長く続けているMars
インクルードするディレクトリをマクロ定数として持つ - Faith and Brave - C++で遊ぼう
とある事情から「インクルードするディレクトリが長いので何度も書きたくない」という状況になり、インクルードするディレクトリをマクロ定数に持って、インクルードするファイル名と連結してインクルードしたい、ということがありました。 そんなときの対応は、このようになりました： // BOOST_PP_STRINGIZEと同等 // トークンを文字列化する #define PP_XSTR(M) #M #define PP_STR(x) PP_XSTR(x) // インクルードするディレクトリ。 // 最後が / になってはならない (トークンとして使えない文字、というエラーになる) #define MY_LIB_PATH aaa/bbb/ccc // aaa/bbb/ccc/ddd.hをインクルードする #include PP_STR(MY_LIB_PATH/ddd.h) int main() {}
C++1z クラステンプレートのテンプレート引数推論 - Faith and Brave - C++で遊ぼう
C++1zでは、クラステンプレートのテンプレート引数が推論されるようになります。 例として、冗長なコードになりがちなstd::lock_guardクラスを使用した以下のコードは、 std::mutex m1; void f() { std::lock_guard<std::mutex> lk(m); } C++1zでは以下のようにstd::lock_guardクラスのテンプレート引数を省略して書けるようになります： std::mutex m; void f() { std::lock_guard lk(m); } この場合、mの型からstd::lock_guardクラスのテンプレート引数の型が推論されます。 C++1zでは、コンストラクタの引数からクラステンプレートのテンプレート引数が推論されます。std::lock_guardクラスの場合、先程のコンストラクタは以下のような宣言になってい
C++1z 古くなった機能を非推奨化 - Faith and Brave - C++で遊ぼう
C++1zから、標準ライブラリのいくつかの機能が非推奨となります。非推奨となった機能は将来のバージョンで削除される可能性がありますのでご注意ください。 std::iteratorクラス 自作イテレータを作るときに基本クラスとして使用するstd::iteratorクラスですが、これを使ってもイテレータを定義するのはあまり簡単になりませんでした。 このクラスを使用することによって問題がより複雑になってしまうケースもありましたので、非推奨となります。 Boost.Iteratorのようなイテレータを簡単に定義するための新たな仕組みは提供されませんので、標準ライブラリの範囲では、イテレータは最初から最後まで自分で定義することになります。 std::allocatorクラスのいくつかのメンバと、std::allocator<void> C++11からアロケータの中間インタフェースとデフォルト実装を提
C++1z インクルードするファイルが存在するかを確認する__has_include - Faith and Brave - C++で遊ぼう
C++1zから、インクルードするファイルが存在するかを確認するプリプロセッサ機能が追加されます。 __has_include式の引数として、ダブルクォーテーションで囲まれたインクルードファイル名、山カッコで囲まれたインクルードファイル名、もしくはプリプロセッサトークン名を指定することで、プリプロセス時にそのファイルが存在するかを#if／#elifで確認できます。 // <optional>ヘッダが存在していたらインクルードする #if __has_include(<optional>) #include <optional> #endif // "optional"ヘッダが存在していたらインクルードする #if __has_include("optional") #include "optional" #endif #define OPTIONAL_HEADER <optional> //
C++1z 浮動小数点数の16進数リテラル - Faith and Brave - C++で遊ぼう
C++1zから、浮動小数点数リテラルを16進数で表記できるようになります。 たとえば、IEEE 754で定められている、単精度浮動小数点数の正の正規化数のうち最小の値である2-126は、10進数表現では1.17549e-38fですが、16進数で表記すれば0x1.0p-126fのように書きやすくなります。 #include <iostream> #include <limits> int main() { std::cout << std::numeric_limits<float>::min() << std::endl; // ライブラリ機能で最小値を取得 std::cout << 0x1.0p-126f << std::endl; // リテラルで最小値を直接表記する std::cout << std::hexfloat << 0x1.0p-126f << std::endl; //
Gitで、事前にUnicodeの結合を行う - Faith and Brave - C++で遊ぼう
WindowsとMacでリポジトリを共有していると、日本語ファイル名の問題が出てきます。「ボタン.png」のようなファイルがあった場合、Windowsのファイルシステムでは「ボ」はひとつのコードポイントとして扱われますが、Macのファイルシステムでは「ホ」と「゛」が分解されます。 これは、Unicodeの結合文字に対する正規化の扱いが、OSのファイルシステムごとに異なるということです。 これによって、Gitを使ってWindowsで「ボタン.png」をコミットし、Macでそのコミットを持ってくると、「ボタン.png」を削除して「ホ゛タン.png」を追加するような動作になるのです。 この問題を解決するために、Mac OSでのGit実装には、core.precomposeUnicodeという設定があります。configファイルで以下のようになっていた場合、 [core] … precompose
C++14でのreturnとreturn (…)の違い - Faith and Brave - C++で遊ぼう
C++14で導入されるdecltype(auto)を使うと、returnとreturn (…)で戻り値の型が変わる。前者は値、後者は参照となる。 decltype(auto) f() { static int value = 3; return value; } decltype(auto) g() { static int value = 3; return (value); } int main() { int f_result = f(); int& g_result = g(); } 参照 C++11/14 and return( … ) vs return - StackOverflow C++14 通常の関数の戻り値型を推論
Boost.Containerにrealloc相当の機能が入る予定 - Faith and Brave - C++で遊ぼう
extended realloc - std-proposals これはrealloc()を拡張したい、というトピックですが、その中でBoost.Container作者のIonさんが「realloc()に相当する機能はBoost.Containerの1.56.0向けにすでに実装したよ」とおっしゃっていました。 std::vectorでは、push_back()で要素をどんどん追加していき、キャパシティが不足したら全要素が収まる新しい領域を確保します。realloc()相当の機能がアロケータにあれば、このような状況では領域を伸長すれば効率がよくなります。 realloc相当の機能に関する提案 アロケータにrealloc()相当の機能を追加する提案は現在、2つあります。 N2045 Improving STL Allocators N3495 inplace realloc 今回、Boost.
C++14の言語拡張まとめ - Faith and Brave - C++で遊ぼう
C++14は、C++11に対するマイナーアップデートです。仕様のバグ修正や、C++11の比較的小さめな機能不足を補うバージョンになっています。 細かすぎる変更はさすがに書きませんが、ある程度大きめの変更を以下にまとめます。 この内容は、正式に策定されるまでに変更される可能性があります。 コア言語 2進数リテラル 変数テンプレート 通常の関数の戻り値型を推論 ジェネリックラムダ 一般化されたラムダキャプチャ constexpr関数の制限緩和 どこからともなく現れる結果の規定(前半, 後半) [[deprecated]]属性 数値リテラルの桁区切り文字 サイズ付きのデアロケーション initializer-listによるaggregate初期化の制約緩和 ロックフリーの定義 シグナルハンドラでできることの制限緩和と明確化 ライブラリ make_unique() コンパイル時整数シーケンス tu
Boost.Lockfree ロックフリーキューの制限 - Faith and Brave - C++で遊ぼう
Boost 1.53.0時点のロックフリーキューは、要素型Tがtrivially copyable(memcpy可能な型)であることを要求します。そのため、ユーザー定義型の多くはロックフリーキューに格納できません。 #include <boost/lockfree/queue.hpp> int main() { boost::lockfree::queue<std::string> que(3); // エラー！ } In file included from main.cpp:3:0: boost_1_53_0/boost/lockfree/queue.hpp: In instantiation of 'class boost::lockfree::queue<std::basic_string<char> >': main.cpp:7:41: required from here bo
boost::string_ref - Faith and Brave - C++で遊ぼう
部分文字列に対する操作で、以下のような処理をよく書くと思います。 #include <string> std::string extract_part(const std::string& str) { return str.substr(2, 3); } int main() { if (extract_part("ABCDEFG").front() == 'C') { ... } } std::stringのメンバ関数を使いたいからchar配列からstd::stringに変換し、部分文字列を得るためにsubstr()メンバ関数を使っています。 しかしそのためにstd::stringの一時オブジェクトができてしまうので、効率はよくありません。 Boost 1.53.0から、このような場合に使用するstring_refというクラスが導入されました。これは以下のように使用します。 #incl
アトミック操作の戻り値 - Faith and Brave - C++で遊ぼう
C++11標準のアトミックライブラリでは、std::atomicというクラスが定義されています。 このクラスには、operator=、+=、-=のような演算子が定義されていますが、セオリーとは少し外れた設計になっているので、紹介したいと思います。 operator=は通常、以下のようなシグニチャで定義します。 template <class T> class MyClass { public: ... MyClass& operator=(T x); }; 通常は戻り値として、代入後の、自分自身のオブジェクトを返します。 しかし、atomicクラスはそうなっていません。atomicクラスの場合は、以下のようなシグニチャで定義されます。 template <class T> class atomic { public: ... T operator=(T x); }; atomicクラスの代
Boostをサポート環境外で動かす - Faith and Brave - C++で遊ぼう
このエントリは、C++ Advent Calendar 2012の参加記事です。 Boost C++ Librariesは多くの環境をサポートしていますが、Boostでも手の届かない環境があります。それは、公開されていない開発環境です。たとえば、ゲームコンソールの開発環境は公開されていないので、ワークアラウンドを自分で書くことはできても、それを公開することはできません。 そういった環境で「Boost使えない！」と言って終わってしまうケースをたまに見ますが、Boostは多くの環境をサポートするために機能ごとのワークアラウンドを提供しているので、自分で設定を書けばサポート環境外でもBoostが使えます。 この記事は、クローズドなサポート外環境への設定を書く方法と、サポート環境とサポート外環境を含めたマルチプラットフォーム化のノウハウを紹介します。 環境を知り、環境を入力する Boostでは、環
Boost.Asio postとdispatchの違い - Faith and Brave - C++で遊ぼう
Boost.Asioのio_serviceには、post()とdispatch()というほぼ同じことをする関数が用意されています。 以下のブログでわかりやすく解説されていたので、それを見ていくことにします。 To post or to dispatch? - This Thread まず、io_serviceを複数スレッドで動作させます。 それと、最初にメインスレッドのIDを出力しておきます。 std::cout << boost::this_thread::get_id() << std::endl; asio::io_service io_service; asio::io_service::work work(io_service); boost::thread_group group; const int count = 3; for (int i = 0; i < count;
Boost.Asio バッファの消費 - Faith and Brave - C++で遊ぼう
Boost.Asioで送受信／読み書き、とくに受信／読み込みを行う場合には、「バッファの消費」という考え方に気をつける必要があります。 以下のようなケースを考えてみます。 これは延々と受信を繰り返すだけの単純なプログラムです。 #include <iostream> #include <string> #include <boost/asio.hpp> #include <boost/bind.hpp> namespace asio = boost::asio; using asio::ip::tcp; class Client { asio::io_service& io_service_; tcp::socket socket_; asio::streambuf receive_buffer_; public: Client(asio::io_service& io_service)
Boost.Asio resolver iteratorを引数にとる接続関数 - Faith and Brave - C++で遊ぼう
Boost 1.47.0のBoost.Asioから、名前解決の結果であるresolver iteratorを引数にとるフリー関数版のconnect()とasync_connect()が提供されます。 これを使えば、名前解決して接続、という流れがとても書きやすくなります。 #include <boost/asio.hpp> #include <boost/bind.hpp> #include <iostream> namespace asio = boost::asio; using asio::ip::tcp; class Client { asio::io_service& io_service_; tcp::socket socket_; public: Client(asio::io_service& io_service) : io_service_(io_service), so
Boost.Geometry 四角形の内外判定 - Faith and Brave - C++で遊ぼう
Boost.Geometryには、2次元上の点を表現するpoint_xyコンセプトと、左上の点と右下の点のペアとして表現されるboxコンセプトがあり、この2つをwithinアルゴリズムに適用することで、四角形の内外判定が簡単にできます。 #include <iostream> #include <boost/geometry/geometry.hpp> namespace bg = boost::geometry; typedef bg::model::d2::point_xy<double> point_type; typedef bg::model::box<point_type> box_type; int main() { const point_type top_left(0, 0); const point_type bottom_right(3, 3); const box_
.mmソースファイル内でBoost.Spirit.Qiを使う - Faith and Brave - C++で遊ぼう
Boost.Spirit.Qiの内部でnilという名前のクラスが使われているので、Objective-C++の文脈(.mm拡張子のソースファイルや、.mmでインクルードされる.h)でこれを使おうとすると、Objective-Cのnilキーワードと衝突してコンパイルエラーになります。 このため、Boost.Spirit.Qiを使うには、.cpp拡張子のソースファイルを作ってC++の文脈で使わなければなりません。 Objective-C++の文脈でBoost.Spirit.Qiを使いたい場合には、Boost.Spirit.Qiの内部で使われているnilの名前を外部から無理矢理書き換えることで、nilとの衝突を回避することができます。 以下がその方法です。 // 一旦nilを消して #if defined(nil) #undef nil #endif // Spirit内のnilに別名を付けて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C++17がISOから発行されました - Faith and Brave - C++で遊ぼう
