Compatibility with the C++ Standard Google has developed many abstractions that either match or closely match features incorporated into C++14, C++17, and beyond. Using the Abseil versions of these abstractions allows you to access these features now, even if your code is not yet ready for life in a post C++11 world.
静的ライブラリのリンク時にundefined referenceエラーが出る(gcc) 概要 gccでリンク時にundefined referenceエラーが出る場合がある。 通常はオブジェクトやライブラリの指定忘れが原因であるが、 静的ライブラリをリンクする順番に間違いがあって出る場合もある (自分でMakefileを書く場合にこのミスをすることが多い) リンクの順番には依存性があり、あるオブジェクトが静的 ライブラリ内の関数を呼び出すときには呼び出される側の ライブラリは「後で」リンクする必要がある。 例えば foo.o が静的ライブラリ libfoo.a 内の関数を使用している、つまり foo.o → libfoo.a という依存関係があるとき、 g++ -o foo libfoo.a foo.o とするとundefined referenceエラーが出る。従って g++ -o fo
を作りました。 http://github.com/tanakh/cmdline 何か コマンドライン引き数の解析を助けるライブラリです。同じ目的のライブラリに、Cの標準関数であるgetoptやgoogleのgflagsなどがありますが、cmdlineは適当に使えてそこそこ便利というのを目指しています。getoptは使いにくいし、usageも自分で書く必要がある。gflagsはライブラリをインストールしたり、リンクしたりちょっと大掛かり。cmdlineは、1ヘッダファイルで、コピーするだけで使えて、修正BSDライセンスで公開しているので、自由にプログラムに取り込んでいただけます。 コードサンプル #include "cmdline.h" int main(int argc, char *argv[]) { cmdline::parser p; p.add("hoge", 'h', "hog
目的 筆者の専門分野でもあり、最近は色んなネットワークのライブラリーーcurl、photonのようなーーが多いので、手作りのクライアントやサーバも少なくなっています。 そのために問題が生じてもどのような問題なのか分からず、ライブラリーのパッチをいつまでも待たないといけなくなったり、効率の悪い回避策を入れたりすることになります。 しかしながら、オープンソースが今のように発展していない一昔は、こういうライブラリは自前で作ってきたものです。 ライブラリーを使うのに慣れている現在のエンジニアさんには難しく思えるのかも知れませんが、実際にポイントを押さえていれば、そこまで難しいものではありません。 この連載によって、基本的なソケット通信のやり方を覚え、実戦で応用ができるならばいいと思っています。 対象 ・ソケットプログラミングに興味のある方 ・Photonなどのネットワークフレームワークやライブラリ
前回は非同期処理についてまとめたが、 今回は並行(concurrent)処理中の同期が必要な処理をC++11で実行するために必要な知識をまとめていく。 ThreadPoolを実装するために必要な知識として、 mutexによるロック 条件変数の使い方 をまとめる。 ThreadPoolはまた次回に持ち越しである。 mutexを用いたロック: std::unique_lock or std::lock_guard ? スレッド間でもプロセス間でも相互排他処理、 つまりある操作を同時に実行するスレッド/プロセスが一つである事を保証する必要がある場合がある。 このような排他的に実行する必要のある処理をクリティカルセッションと呼ぶ。 相互排他処理を実現するための同期機構としてmutexというものがある。 Wikipediaによれば相互排他(MUTual EXclusion)の省略形が語源だそうだ。
概要 std::bindは、関数の引数を束縛したオブジェクトを作成できます。 bind時に引数を束縛しない場合には、std::placeholdersを指定します。 ヘッダファイル #include <iostream> #include <functional> void f1() { std::cout << __PRETTY_FUNCTION__ << std::endl; } void f2(int x) { std::cout << __PRETTY_FUNCTION__ << " " << x << std::endl; } void f3(int x, int y) { std::cout << __PRETTY_FUNCTION__ << " " << x << " " << y << std::endl; } int main(int argc, char const*
鉄則2: シグナルハンドラで行ってよい処理を知ろう sigaction関数で登録したシグナルハンドラで行ってよい処理は非常に限定されている 次の３つの処理だけが許されている 自動変数の操作 “volatile sig_atomic_t” 型の大域変数の操作 「非同期シグナルセーフ」関数の呼び出し これ以外の処理を記述しないこと！ 説明： シグナル受信時に何らかの処理を行うためには、シグナルハンドラと呼ばれる関数を用意し、それをsigaction関数でシグナル名と紐付けておけばOKです。しかし、シグナルハンドラ内で行ってよい処理は、上記の通り非常に限定されています。これを把握しないまま奔放なコードを書くと次のような現象が起き得ます： 問題1: プログラムがデッドロックする危険がある タイミングに依存する、再現困難なバグの原因となる デッドロックの発生が典型例だが、それ以外にも関数の戻り値不正
局所的に「スレッド開始を遅延させる」ネタが盛り上がっていたので、C++とBoostライブラリを用いた色々な実装方法をまとめてみました。 この記事で対象とするのは、下記コードにある2つの要件を満たす実装方法です。 (1) スレッドを管理するオブジェクトXのコンストラクト時ではなく、その後の任意タイミングで新スレッド処理を開始する。 (2) オブジェクトXのデストラクト時に、上記(1)の別スレッドがまだ実行中ならそのスレッド処理完了を待機する。 class X { // threadオブジェクトを保持するメンバ変数 void do_() { /* 別スレッド処理 */ } public: ~X() { // (2) 別スレッドがまだ実行中なら完了を待機する } void start() { // (1) 新しいスレッドを開始して関数do_を実行する } }; int main() { X x;
C++ で Worker Thread パターン
Worker Thread とは一般に生成、破棄コストの高いスレッドをプールして使い回すためのパターンで Thread Pool とも呼ばれます。 Worker Thread パターンは Producer-Consumter パターンに基づいており、キューで受け渡されるのがデータではなく実行可能な仕事を表現したオブジェクトである点が特徴です。 以下の例で Runnable は仕事の基底クラスであり、std::shared_ptr<Runnable> のキューを介してプールされているスレッドに仕事を依頼します。 クライアントは Runnable のサブクラスを作成し、インスタンスをスレッドプールに add する事で自分でスレッドをハンドルする事無く非同期に仕事を実行させる事ができます。 This file contains bidirectional Unicode text that ma
Relevant questions: About C++11: C++11: std::thread pooled? Will async(launch::async) in C++11 make thread pools obsolete for avoiding expensive thread creation? About Boost: C++ boost thread reusing threads boost::thread and creating a pool of them! How do I get a pool of threads to send tasks to, without creating and deleting them over and over again? This means persistent threads to resynchroni
勉強会での発表 先日Sapporo.cppとCLR/Hの合同勉強会を開催し、 僕はC++11のスレッドについて紹介をしました。 規格書で読むC++11のスレッド from Kohsuke Yuasa この発表では、C++11で導入されたスレッドライブラリの中から、 thread mutex/lock future/promise condition_variable について、それぞれがどんなものかを紹介し、また、それらの機能を使用して簡単なタスクライブラリを作ったという話をしました。 実際のセッションでは、発表時間が足りなくなってしまい、ちゃんとこのhwm.taskを紹介できなかったので、ちょっと残念だったのと、 あと、当日発表したときは未完成なところや微妙なところがもあり、それからもう少し手を加えたりしたので、改めてこのブログで紹介したいと思います。 hwm.task GitHub -
singletonなんてタグがあるくらい、みんな大好きシングルトン。 ところで、あなたのシングルトンは本当にそんな実装で大丈夫ですか？ 今回は、単純なようで奥が深い、シングルトンの実装について考えてみます。 シングルトンとは GoFによって定義されたデザインパターンのひとつ。 Singleton パターン 実装方法 シングルトンの実装方法は、大きく分けて2通り存在します。 ローカル静的オブジェクトによる実装 動的割り当てによる実装 ローカル静的オブジェクトによる実装 class Foo { private: Foo() = default; ~Foo() = default; public: Foo(const Foo&) = delete; Foo& operator=(const Foo&) = delete; Foo(Foo&&) = delete; Foo& operator=(F
Bjarne StroustrupによるC++のスタイルとテクニックに関するFAQ オリジナル: Bjarne Stroustrup's C++ Style and Technique FAQ ここにまとめられているのは、私がよく尋ねられるC++のスタイルとテクニックに 関する質問です。もしよりよい質問や回答に対するコメントがあれば、遠慮なく私に メール(bs@research.att.com)でお知らせください。なお、ホームページを改善する ために、私はあまり時間を割けないということを心に留めておいてください。 より一般的な質問は、一般的なFAQを 参照してください。 用語や概念については、C++用語解説を 参照してください。 この文書の内容は、質問と回答をまとめただけのものであるということに注意して ください。よい教科書にみられるような、注意深く選ばれた例題と解説の代わりになる もので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
