2023年に特にお世話になったC++ライブラリ8選 - Qiita
たぶん2023年一番お世話になったライブラリです。 2022年まではsimdjsonをよく使っていたのですが、新規プロジェクトはGlazeばかり使っています。 開発が活発だし、ISSUEへの対応が速いのもありがたいです。 良い点 SIMDを利用していないのにsimdjsonやyyjsonと遜色ない速度で動作する 構造体やクラスだけでなくSTLコンテナもJSONとの直接読み書きができる 中間データに独自バイナリ形式を利用してさらに高速化できる いまいちな点 長い文字列が多いJSONデータの読み込みではSIMDを使っているライブラリに対して不利になる 最後のフィールドのカンマやコメントの読み込みに対応していない ストリーム的な処理はない(と思う) 代替ライブラリ 似たようなアプローチでSIMDを使ってさらに速いJsonifierというライブラリがあります。 純粋な速度を求める場合にはこちらを使
C++の自明なメソッドが暗黙に定義されるか場合分け | Netsphere Laboratories
(2017年6月) 新規作成。 C++ では、互換性の観点と開発の便宜のため, 暗黙にコンストラクタ (構築子)、代入演算子、デストラクタ (破壊子) が定義される。自明 (trivial) な特殊メンバ関数と呼ばれる。 開発者が陽に (明示的に) これらのメンバ関数を定義した場合、自明なメソッドは定義されない。が、ややこしいことに, 単に対応するメンバ以外にも削除されるものがある。 表としてまとまったものが見当たらなかったので、作ってみた。 特殊メンバ関数とコンパイラによる暗黙宣言 - yohhoyの日記 や, コンストラクタが暗黙に宣言されるとき、されないとき があったが、残念なことに、2017年6月現在, 誤りが含まれている。 下の表は、一番左の列のメンバを陽に定義した場合に、2列目以降のメンバが自明か削除されるかを示す。trivial は自明なメンバが暗黙に定義され、deleted
［C++］地に足のついた範囲for文 - 地面を見下ろす少年の足蹴にされる私
この記事はC++ Advent Calendar 2022の5日目の記事です。 問題です。次のコードには未定義動作が少なくとも1つ含まれています。それは何でしょう？ #include <vector> #include <string> // どこかで定義されているとして auto f() -> std::vector<std::string>; int main() { for (auto&& str : f()) { std::cout << str << '\n'; } for (auto&& c : f().at(0)) { std::cout << c << ' '; } } 以下、この記事ではここのf()をたびたび再利用しますが、宣言は再掲しません。 答え なぜ？ その他の例 C++23における解決 紆余曲折 参考文献 答え #include <vector> #include
［C++］後から触られないグローバルRAIIラッパー - 地面を見下ろす少年の足蹴にされる私
C言語のライブラリにたまにある、最初にグローバル状態を~init()で確保して、それを最後に~release()で解放するというインターフェースについて、C++から使うときはRAIIで自動化したい衝動に駆られます。そのとき問題となるのは、プログラムの最初で初期化したらあとはプログラム終了時まで誰にも触ってほしくない、という気持ちをどうやって実現するのか、という事です。 グローバルRAIIラッパー 型を隠そう！ 初期化処理を分ける+コピー禁止 後から構築を禁止する さらなる懸念 参考文献 グローバルRAIIラッパー 単純にRAIIに従った、次のようなクラスを考えることができます。 #include <iostream> // グローバル状態初期化/解放関数とする void init() { std::cout << "init()\n"; } void release() { std::co
右辺値参照(&&) ユニバーサル参照の強み
rvalue referenceが導入される前夜のC++を考えてみます。 その頃存在したreferenceはこんにちのlvalue referenceのことでした。 const lvalue referenceはlvalue以外にもrvalueも束縛できました。 さて、rvalueですが、最終的に変数に代入するか変数を初期化するかのいずれかに用いることが基本的には多いため、「一時的なもの」という共通認識が醸造されていました。 ここで新たに次のような社会的合意を行いました。それは「rvalueは所有権をもたない」というものです。 所有権を持たないならば対象オブジェクトをいかに書き換えようとも文句は言われない。つまりここで、rvalue referenceで受け取ったものは自由にいじくり回していい、という社会的合意を行うわけです。 さて、「rvalueは所有権をもたない」を前提にさらに新たな社
無料になったIntel compilerをCentOS8にインストールしてみる - Qiita
インテルのoneAPIのニュースとかは見ている方も多いかと思いますが、この流れで一番大きなインパクトは今まで高嶺の花だったIntel compilerが2021年になってから実質的に無料になってしまったということです。こうでもしないとNVIDIA1には対抗できないってことなんでしょうけど、このディープラーニングの思わぬ副産物に対して従来型HPCユーザーも恩恵にあずからずにいるわけにはいかないでしょう。 とりあえずCentOS8へのyum (dnf)を使ったインストールはとても簡単だったので、手順を紹介することにします。とりあえず本家のガイドはこちらから。やるのはyumのリポジトリを作ってinstallコマンドを打つだけです（root権限で行います）。 yumでBase kitを入れる /etc/yum.repos.d/oneAPI.repoを以下の内容で作ります [oneAPI] name
C++でコマンドラインパーサを書いた - Qiita
C++14で使えるコマンドラインパーサnonsugarを書きました。せっかく書いたので晒します。 動機 C++で使えるコマンドラインパーサとして有名どころにBoost.Program_optionsがありますが、ライブラリのビルド・リンクが必要なのが面倒です。 ヘッダオンリーのライブラリも探せばありますが(このへんとか)、個人的な好みとしてさらに次の2点を求めたいです。 ユーザーが非constな変数を定義しなくてよい オプションが引数を取る場合、引数の型の指定は1回だけでよい(オプションの定義時と、引数の取得時の両方で型を指定する必要がない) そんなわけで自分で書きました。あとoptparse-declarativeとか見て、サブコマンドを簡単に定義できるのかっこいいと思ったので真似しました。 特徴 シングルヘッダ char以外の文字型をサポート サブコマンドをサポート オプションの引数と
［C++］inline名前空間の使途 - 地面を見下ろす少年の足蹴にされる私
inline名前空間はC++11から追加された機能で、その中にあるものは透過的に（名前空間がないかのように）アクセスすることができます。一見使いどころがなく見られがちですが、うまく使えばとても便利に活用することができます。 1. using namespaceの範囲を限定する 2. APIのバージョニング 3. ABIのバージョニング リンクエラーにする ABI互換性を確保する 4. 名前の衝突を回避する 参考文献 1. using namespaceの範囲を限定する これは標準ライブラリではユーザー定義リテラルの定義と利用でよく利用されます。 例えば、std::string_viewを簡易利用するためのsvリテラルは次のように宣言されています。 namespace std { // string_view本体 template <class CharT, class Traits = c
C++ のパッケージマネージャーの選択メモ( conan vs. vcpkg vs. Hunter on Windows and Ubuntu ): C++ 実装がサブプロジェクトとして内包されるクロスプラットフォームアプリのリポジトリーの場合 - C++ ときどき ごはん、わりとてぃーぶれいく☆
タイトルが少しややこしいので最初に整理します。 このメモは: C++ のパッケージマネージャーの選択のはなし ただし: アプリはクロスプラットフォーム ( このメモでの具体例は Windows-10 & Ubuntu-19.04 ) アプリ全体(=このメモでは「ソリューション」とします)はいくつかの構成部品(=このメモでは「プロジェクト」とします)に分けて作られる プロジェクトの1つ以上に C++ を採用したい そのプロジェクト単位で C++ のライブラリーを管理できるパッケージマネージャーを導入したい → どうするのが楽そうかな のメモです。 選択肢と大雑把な検討 conan https://conan.io/ クロスプラットフォーム対応の C++ のパッケージマネージャーが欲しいの悩みに答えてくれる定番。 CMake でごにょごにょする vcpkg https://github.com
bool operator==(const T&, const T&)と、クラス内でbool operator==(const T& other) constを定義する違いはなんですか？
以下のコードのように、 メンバにbool operator==(const T&) constを定義する グローバルにbool operator==(const T&, const T&)を定義する この２つの違いは何でしょうか？ どちらを使うべきでしょうか？ code: #include <iostream> struct A{ int x; bool operator==(const A& other) const { std::cout << __PRETTY_FUNCTION__ << std::endl; return x == other.x; } }; bool operator==(const A& a, const A& b){ std::cout << __PRETTY_FUNCTION__ << std::endl; return a.x == b.x; } int
以下のrange-based forは危険でしょうか。
1#include <iostream> 2#include <fstream> 3#include <string> 4#include <vector> 5 6using namespace std; 7 8auto retVec(vector<string> original) 9{ 10 return original; 11} 12 13struct str 14{ 15 vector<string> _vec 16 { 17 "first", 18 "second", 19 "third" 20 }; 21public: 22 auto get_vec() { return _vec; }; 23}; 24 25int main() 26{ 27 for (auto e : str().get_vec()) // 危険? 28 { 29 cout << e << endl; 3
C++のenumの値を文字列にできるライブラリnameofがすごい - Qiita
はじめに 2019/7/10追記 NAMEOF_TYPEの例が0.8.0以降のバージョンで動かない問題を修正しました (Thanks! @tyu_ru_cppさん) C++だと「enumで定義した名前を文字列にしたい」というときに困ることがたまによくあります。他の言語だとToStringメソッドを使って文字列にできたりするのですが、C++だとそうはいきません。 Qtを使うと独自の黒魔術によって比較的楽に取得することができるのですけども、Qtを使わないピュアなC++な環境だとどーすんだろっていう感じです。 そこで、Siv3dの作者さんである@Reputelessさんが、まさにそのenumから文字列の変換ができるライブラリについて呟いておられまして、その機能と実装方法に感銘を受けたので、ここで紹介したいと思います。 C++ で enum の値を追加の記述無しで文字列にできるライブラリだ (MS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mapbox/earcut.hpp: Fast, header-only polygon triangulation
namespace ra :: How to Write C++ Library
Learn Contemporary C++ | Concise&Visual Examples
GitHub - catchorg/Catch2: A modern, C++-native, test framework for unit-tests, TDD and BDD - using C++14, C++17 and later (C++11 support is in v2.x branch, and C++03 on the Catch1.x branch)
GitHub - filipdutescu/modern-cpp-template: A template for modern C++ projects using CMake, Clang-Format, CI, unit testing and more, with support for downstream inclusion.
GitHub - marzer/tomlplusplus: Header-only TOML config file parser and serializer for C++17.
Standard C++
4つのauto、4つのC++規格 - Qiita
