タグ付けされた質問 「c++11」

C ++標準では（私は新しいもので、それに気づいたが、それはすでにC ++ 03には存在しなかった）のように書かユニバーサル文字名を指定\uNNNNし、\UNNNNNNNNおよびUnicodeのコードポイントで文字を表しますNNNN/ NNNNNNNN。これは、特に明示的にUTF-8、UTF-16、およびUCS-4文字列リテラルも定義されているため、文字列リテラルで役立ちます。ただし、識別子には汎用文字リテラルも使用できます。その背後にある動機は何ですか？ 構文は明らかに完全に判読不能で、識別子はリンカ用にマングルされている可能性があり、とにかくシンボルを名前で取得する標準関数があったようではありません。それでは、なぜ誰もが実際にユニバーサル文字リテラルを含む識別子を使用するのでしょうか？ 編集：実際にはすでにC ++ 03に存在していたので、追加の質問は、それを使用したコードを実際に見たかどうかです。

11 c++  c++11 

次の単一リンクリストの実装を検討してください。 struct node { std::unique_ptr<node> next; ComplicatedDestructorClass data; } 次に、std::unique_ptr<node> headスコープ外になり、デストラクタが呼び出されるインスタンスの使用を停止するとします。 これは十分に大きなリストのスタックを爆破しますか？それは公正なコンパイラが（インラインかなり複雑な最適化を行いますと仮定することであるunique_ptr「内のデストラクタをnode私がしなければ以来、以下の（はるかに困難になっている、そして、s」は末尾再帰を使用）dataデストラクタがわかりにくくなりnext、のハードそれを作りますコンパイラーが再配列の可能性と末尾呼び出しの機会に気付くように） struct node { std::shared_ptr<node> next; ComplicatedDestructorClass data; } dataどういうわけかnodeそれへのポインタがある場合、それはテール再帰が不可能であることさえあるかもしれません（もちろん、私たちはそのようなカプセル化の違反を回避するよう努めるべきです）。 一般的に、そうでない場合、このリストを破棄するにはどうすればよいですか？共有ポインタにはrelease！がないため、リストを走査して「現在の」ノードを削除することはできません。唯一の方法は、カスタムの削除ツールを使用することです。

11 c++11  smart-pointer 

現在、マイクロコントローラー用のRTOSを書いています。全体がC ++ 11で書かれています-誰かが興味を持っていて、リポジトリへのリンクが一番下にある場合。 現在私は、スレッド間（または、割り込みハンドラーとスレッド間、または割り込みハンドラーと他の割り込みハンドラー間）でオブジェクトを受け渡すための単純なデータキューであるクラスを作成しています。通常、私は他のプロジェクトにあるいくつかの共通のAPIを追跡しようとすると、まだ私は持っている同時キューのいずれかの例が見つかりませんでしたemplace()機能とサポートタイムアウトを。 私の一般的な「問題」は、次の2つのインターフェースを決定できないことです。 （std::chrono::duration<Rep, Period>はテンプレートタイプです。わかりやすくするためにテンプレートのボイラープレートは省略しています） 最初のバージョン： template<typename T> class FifoQueue { public: ... template<typename... Args> int tryEmplaceFor(std::chrono::duration<Rep, Period>, Args&&... args); int tryPopFor(T&, std::chrono::duration<Rep, Period>); int tryPushFor(const T&, std::chrono::duration<Rep, Period>); int tryPushFor(T&&, std::chrono::duration<Rep, Period>); ... } 2番目のバージョン： template<typename T> class FifoQueue { public: ... template<typename... Args> int tryEmplaceFor(std::chrono::duration<Rep, Period>, …

10 c++  c++11  multithreading  api  queue 

AとBの2つのオブジェクトタイプがあるとします。これらのオブジェクト間の関係は多対多ですが、どちらも他方の所有者ではありません。 AインスタンスとBインスタンスの両方が接続を認識する必要があります。片道だけではありません。 だから、これを行うことができます： class A { ... private: std::vector<B *> Bs; } class B { private: std::vector<A *> As; } 私の質問は次のとおりです。接続を作成および破棄する関数をどこに配置すればよいですか。 A :: Attach（B）である必要があります。これにより、A :: BsおよびB :: Asベクトルが更新されますか？ または、B :: Attach（A）である必要があります。 それらのどちらも正しくないと感じています。コードの操作をやめて、1週間後に戻ってきた場合、A.Attach（B）とB.Attach（A）のどちらを実行するべきかを思い出すことができないと確信しています。 おそらくそれはこのような関数であるべきです： CreateConnection(A, B); ただし、グローバル関数を作成することは、クラスAとBのみを操作するための関数であることから、望ましくないように見えます。 別の質問：この問題/要件に頻繁に遭遇した場合、どうにかして一般的な解決策を作成できますか？おそらく、このタイプの関係を共有するクラスから派生したり、クラス内で使用できるTwoWayConnectionクラスですか？ この状況に対処するための良い方法は何ですか... 1対多の「CがDを所有する」状況をうまく処理する方法を私は知っていますが、これはトリッキーです。 編集：より明確にするために、この質問には所有権の問題は含まれていません。AとBの両方が他のオブジェクトZによって所有されており、Zはすべての所有権の問題を処理します。AとBの間の多対多のリンクを作成/削除する方法にのみ興味があります。

10 c++  c++11 

私の理解では、C ++ 11では、関数からローカル変数を値で返す場合、コンパイラーはその変数をr値参照として扱い、それを関数から「移動」して返すことができます（もちろん、RVO / NRVOは代わりに発生しません）。 私の質問は、これは既存のコードを壊すことができないのですか？ 次のコードを検討してください。 #include <iostream> #include <string> struct bar { bar(const std::string& str) : _str(str) {} bar(const bar&) = delete; bar(bar&& other) : _str(std::move(other._str)) {other._str = "Stolen";} void print() {std::cout << _str << std::endl;} std::string _str; }; struct foo { foo(bar& b) : _b(b) {} ~foo() …

10 c++  c++11 

これはSOの質問として始まりましたが、それはかなり型破りであり、Webサイト上の実際の説明に基づくと、質問には多くの概念的な重みがあるため、programmers.seに適している可能性があることに気付きました。 私はclang LibToolingを学習してきましたが、これは非常に強力なツールであり、コードの「ぎこちない」全体をフレンドリーな方法で、つまりセマンティックな方法で、推測することなく公開できます。clangがコードをコンパイルできる場合、clangはそのコード内のすべての単一文字のセマンティクスについて確実です。 ここで、少し前に戻ります。 C ++テンプレートのメタプログラミングに従事する場合（特に、恐ろしいマクロではあるが、テンプレートを超えて賢い領域に冒険する場合）には、多くの実用的な問題が発生します。正直なところ、私も含めて多くのプログラマーにとって、テンプレートの通常の使用法の多くは、やや恐ろしいものです。 良い例は、コンパイル時の文字列だと思います。これは、1年以上前の質問ですが、現時点でのC ++では、これが単なる人間にとって容易ではないことは明らかです。これらのオプションを見るだけでは吐き気を誘発するのに十分ではありませんが、それでも、私が自分のソフトウェアで使用している空想のアプリケーションに適合する魔法の、最大限に効率的なマシンコードを生成できるかどうか自信がありません。 正直言って、皆さん、文字列はかなりシンプルで基本的なものです。私たちの中には、特定の文字列が単純な方法でコーディングする場合よりも大幅に「組み込まれた」マシンコードを生成する便利な方法を求めているだけです。私たちのC ++コードで。 clangとLibToolingを入力します。これにより、ソースコードの抽象構文ツリー（AST）が公開され、シンプルなカスタムC ++アプリケーションRewriterが、ASTのすべての豊富なセマンティックオブジェクト指向モデルと一緒に、生のソースコードを（確実に）正しく正確に操作できるようになります。それは多くのものを扱います。マクロ展開について知っているので、それらのチェーンをたどることができます。はい、私はソースからソースへのコード変換または変換について話しています。 ここでの私の基本的な論点は、clangにより、C ++ソフトウェアの理想的なカスタムプリプロセッサステージとして機能する実行可能ファイルを作成できるようになり、これらのメタプログラミングステージをC ++で実装できるということです。このステージは、有効なC ++コードである入力を受け取り、より有効なC ++コードを出力として生成する必要があるという事実に制約されます。さらに、ビルドシステムが適用するその他の制約。 結局のところ、clangはコンパイラのフロントエンドであり、APIを使って独創的であるため、入力は少なくとも有効なC ++コードに非常に近い必要があります。使用する新しい構文を定義できるようにする準備があるかどうかはわかりませんが、これを正しく解析してclangプロジェクトに追加する方法を開発する必要があることは明らかです。これ以上期待することは、clangプロジェクトに範囲外の何かを含めることです。 問題ない。一部の何もしないマクロ関数がこのタスクを処理できると思います。 私が説明していることを確認する別の方法は、言語自体で利用できるより限定されたツールを使用して実装する代わりに、ソースコードのAST（clangとそのAPIのおかげ）を操作することにより、ランタイムC ++を使用してメタプログラミング構成を実装することです。これには、明らかなコンパイルパフォーマンスの利点もあります（テンプレートが多いヘッダーでは、使用頻度に比例してコンパイルが遅くなります。コンパイルされたものの多くは、慎重に照合され、リンカーによって破棄されます）。 ただし、これには、ビルドプロセスに追加の手順を1つまたは2つ追加するコストと、ツールの一部として（確かに）多少冗長なソフトウェア（ただし、少なくとも単純なランタイムC ++）を記述する必要があります。 。 それは全体像ではありません。コア言語の機能では非常に困難または不可能であるコードを生成することで、はるかに大きな機能空間を確保できると確信しています。C ++ではテンプレート、マクロ、またはその両方のクレイジーな組み合わせを記述できますが、clangツールでは、セマンティックコンテンツへのフルアクセスを持ちながら、実行時に C ++で実現できる方法でクラスと関数を変更できます。テンプレートとマクロ、その他すべてに加えて。 それで、なぜ誰もがまだこれをしていないのかと思っています。clangのこの機能は非常に新しく、clangのASTの巨大なクラス階層に誰も精通していないのでしょうか？それはそれではありえない。 おそらく、私はこれの難しさを少し過小評価しているだけですが、clangツールを使用して「コンパイル時の文字列操作」を行うことは、犯罪的にほぼ単純です。冗長ですが、非常に単純です。必要なのは、実際の実際のstd::string操作にマップする一連のno-opマクロ関数だけです。clangプラグインは、関連するすべてのno-opマクロ呼び出しをフェッチしてこれを実装し、文字列を使用して操作を実行します。このツールは、ビルドプロセスの一部として挿入されます。ビルド中に、これらのno-opマクロ関数呼び出しは自動的にその結果に評価され、プログラム内の単純な古いコンパイル時文字列として挿入されます。その後、プログラムは通常どおりコンパイルできます。実際、結果として得られるこのプログラムは、結果としてはるかに移植性が高くなり、C ++ 11をサポートする豪華な新しいコンパイラーを必要としません。

10 c++  c++11  meta-programming  clang 

インターフェイスと実装を分離したいクラス階層があります。私の解決策は、インターフェイスのハンドルクラス階層と実装の非パブリッククラス階層の2つの階層を持つことです。基本ハンドルクラスには実装へのポインターがあり、派生ハンドルクラスは、派生型のポインターにキャストします（関数を参照getPimpl()）。 これは、2つの派生クラスを持つ基本クラスの私のソリューションのスケッチです。より良い解決策はありますか？ ファイル「Base.h」： #include <memory> class Base { protected: class Impl; std::shared_ptr<Impl> pImpl; Base(Impl* pImpl) : pImpl{pImpl} {}; ... }; class Derived_1 final : public Base { protected: class Impl; inline Derived_1* getPimpl() const noexcept { return reinterpret_cast<Impl*>(pImpl.get()); } public: Derived_1(...); void func_1(...) const; ... }; class Derived_2 final : …

9 design  c++  c++11 

C ++アプリケーションを書いています。ほとんどのアプリケーションはデータ引用を読み書きする必要があり、これも例外ではありません。データモデルとシリアル化ロジックの高レベルデザインを作成しました。この質問は、これらの特定の目標を念頭に置いて、私のデザインのレビューを要求しています： 任意の形式（rawバイナリ、XML、JSONなど）でデータモデルを読み書きする簡単で柔軟な方法を提供する。al。データの形式は、シリアル化を要求しているコードと同様に、データ自体から分離する必要があります。 シリアル化が合理的に可能な限りエラーが発生しないようにするため。I / Oは、さまざまな理由で本質的にリスクが高くなります。私の設計では、失敗する方法が増えているのですか？もしそうなら、それらのリスクを軽減するために設計をどのようにリファクタリングできますか？ このプロジェクトはC ++を使用します。好きでも嫌いでも、言語には独自の方法があり、デザインはその言語に対抗するのではなく、その言語で機能することを目指しています。 最後に、プロジェクトはwxWidgetsの上に構築されます。より一般的なケースに適用できるソリューションを探していますが、この特定の実装はそのツールキットでうまく機能するはずです。 以下は、C ++で記述された非常に単純なクラスのセットであり、設計を示しています。これらは私がこれまでに部分的に書いた実際のクラスではなく、このコードは私が使用しているデザインを単に示しています。 まず、いくつかのサンプルDAO： #include <iostream> #include <map> #include <memory> #include <string> #include <vector> // One widget represents one record in the application. class Widget { public: using id_type = int; private: id_type id; }; // Container for widgets. Much more than …

9 design  c++  c++11 

Cassandraに似たデータベースサーバーを開発しています。 開発はCで始まりましたが、クラスがなければ非常に複雑になりました。 現在、私はすべてをC ++ 11に移植しましたが、まだ「モダンな」C ++を学習しており、多くのことについて疑問があります。 データベースはキー/値のペアで動作します。すべてのペアにはさらに多くの情報があります。いつが作成され、いつ期限切れになるか（期限切れでない場合は0）。各ペアは不変です。 キーはC文字列、値はvoid *ですが、少なくとも今のところ、値をC文字列として操作しています。 抽象IListクラスがあります。3つのクラスから継承 VectorList -C動的配列-std :: vectorに似ていますが、 realloc LinkList -チェックとパフォーマンス比較のために作成 SkipList -最終的に使用されるクラス。 将来はRed Black木も作ろうと思います。 それぞれIListに、キーでソートされた、0個以上のペアへのポインターが含まれています。 IList長くなりすぎた場合は、特殊ファイルとしてディスクに保存できます。この特殊ファイルは一種ですread only list。 キーを検索する必要がある場合は、 最初にメモリ内IListが検索されます（SkipList、SkipListまたはLinkList）。 次に、日付でソートされたファイルに検索が送信されます （最新のファイルが最初、最も古いファイル-最後）。 これらのファイルはすべてメモリにmmapされます。 何も見つからない場合、キーは見つかりません。 私はIList物事の実装に疑いはありません。 現在私を困惑させているのは以下の通りです： ペアは異なるサイズであり、それらはによって割り当てられnew()、それらをstd::shared_ptr指し示しています。 class Pair{ public: // several methods... private: struct Blob; std::shared_ptr<const Blob> _blob; }; struct Pair::Blob{ uint64_t …

9 c++  c++11  pointers  smart-pointer 

void Animation::playAnimation() const { static const int index = 0; const std::string& animationFileName = m_animationContainer.getAnimationName(index); static const int zOrder = -1; static bool isLooping = false; AnimationBank::play(animationFileName, zOrder, isLooping); } 定数ローカル変数を次のように定義するメリットはありますstaticか？またはそれは不必要であり、悪い習慣ですらあります。

9 c++  c++11  c++14 

pimplの問題の1つは、それを使用するとパフォーマンスが低下することです（追加のメモリ割り当て、不連続なデータメンバー、追加の間接参照など）。pimplのすべての利点が得られないという犠牲を払ってこれらのパフォーマンスのペナルティを回避する、pimplイディオムのバリエーションを提案したいと思います。アイデアは、クラス自体にすべてのプライベートデータメンバーを残し、プライベートメソッドのみをpimplクラスに移動することです。基本的なpimplと比較した場合の利点は、メモリが連続している（追加の間接参照がない）ことです。pimplをまったく使用しない場合と比較した場合の利点は次のとおりです。 プライベート関数を非表示にします。 これらのすべての関数が内部リンケージを持ち、コンパイラーがより積極的に最適化できるように構造化できます。 したがって、私の考えは、pimplをクラス自体から継承させることです（私は少し奇妙に聞こえますが、我慢してください）。次のようになります。 Ahファイル： class A { A(); void DoSomething(); protected: //All private stuff have to be protected now int mData1; int mData2; //Not even a mention of a PImpl in the header file :) }; A.cppファイル： #define PCALL (static_cast<PImpl*>(this)) namespace //anonymous - guarantees internal linkage { struct PImpl …

9 design-patterns  performance  optimization  c++11 

私はUTF-8イテレーターアダプターに取り組んでいます。つまり、イテレータをaに、charまたはunsigned charシーケンスをイテレータからシーケンスに変換するアダプタを意味しchar32_tます。ここでの私の仕事は、オンラインで見つけたこのイテレータに触発されました。 ただし、独自の実装を開始するときに標準を調べたところ、C ++がイテレータに課す要件に準拠しながら、このようなアダプタを実装することはできないようです。 たとえば、InputIterator要件を満たすUTF-8イテレータを作成できますか？はい。ただし、指定されたイテレータ自体がInputIteratorではない場合に限ります。どうして？ InputIteratorは、同じイテレータを複数回逆参照する機能を必要とするためです。それらがすべて等しい場合、そのイテレータの複数のコピーを逆参照することもできます。 もちろん、UTF-8イテレーターアダプターを逆参照するには、基本イテレーターの逆参照と、場合によっては増分を行う必要があります。そして、そのイテレーターがInputIteratorである場合、元の値をインクリメントした後に戻すことはできません。また、コピーが機能する必要があるという事実char32_tは、以前にデコードされた値を表すをローカルに保存できないことを意味します。あなたはこれを行うことができたでしょう： auto it = ... auto it2 = it; //Copies an empty `char32_t`. *it; //Accesses base iterator, storing `it.ch`. *it; //Doesn't access the base iterator; simply returns `it.ch`. *it2; //Cannot access `it.ch`, so must access base iterator. わかりました。InputIteratorsは使用できません。しかし、ForwardIteratorはどうでしょうか？UTF-8文字シーケンスでForwardIteratorを適応できるForwardIteratorアダプターを作成することは可能ですか？ またはを生成するに*itは操作が必要なため、これも問題です。InputIteratorsはに変換可能である何かを吐き出すことができますが、[forward.iterators] /1.3実際の参照を提供するために必要とされます。value_type&const value_type&value_typeForwardIterator Xが可変イテレータである場合、referenceはへの参照Tです。Xが定数イテレータの場合、referenceはへの参照ですconst T ここでの唯一の手段は、そのようなすべてのイテレータがを持ち運ぶchar32_tことです。これは、その参照用のストレージを提供するためだけに存在します。その場合でも、イテレータインスタンスがインクリメントされ、逆参照されるたびに、その値を更新する必要があります。これは古い参照を事実上無効にし、標準はそれを明示的に許可していません（無効化はイテレータが破棄された場合、またはコンテナがそうした場合にのみ発生します）。 …

8 c++  c++11  unicode  utf-8 

特に明記しない限り、C ++のすべてのオブジェクトは変更可能ですか？ PythonとJavaScriptでは、文字列、タプル、ユニコードを変更できません。C ++に不変なものがあるかどうか、またはすべてのオブジェクトが変更可能であるかどうかを疑問に思っていましたconst。不変にするために型修飾子を使用する必要があります。

8 c++11  immutability 

私は、いくつかのボタンと小さなグラフィックディスプレイでユーザーとインターフェイスする組み込みシステムに取り組んでいます。 余談ですが、私は組み込みシステムを使用しているので、動的なメモリ割り当てをできるだけ回避したいと思います。std :: vectorのようなものは利用できません。 次のように、クラシックなネストされたメニュー構造を使用して構成メニューを実装する必要があります。 Level A Node 1 -> Level B Node 1 -> Level C Node 1 -> Level B Node 2 -> Level B Node 3 Level A Node 2 Level A Node 3 ここでの最善のアプローチについてはよくわかりません。複合パターンを使用するなど、このようなものにアプローチするいくつかの方法について読みました。しかし、私はいつも「紙の上」では良さそうに見えても、実装するのは面倒そうなものにぶつかります。 私の一般的な考えはMenuNode、初期化時にそのサブノードと親ノードについて知っているクラスを持つことです。Menuクラスは、ノードナビゲーションおよび処理を扱うことができます。明らかに、すべてMenuNodeが次のような特定の動作を実行/実装する必要があります。 Menu何を表示したいかを報告します（実際のレイアウト/配置はの問題ではありませんMenuNode）。 ユーザー入力に反応する（値を増減する/ボタンを押すなど） 関心のある実際の値にアクセスする（ApplicationSettingsクラスに属している） これを実装する最良の方法は何でしょうか？ （抽象的な）MenuNode基本クラスを使用して、すべてのメニューノード項目のサブクラスを作成します。初期化中に、ApplicationSettings必要になる可能性のある他の依存関係へのポインタを提供できます。どういうわけか、それぞれが一度だけインスタンス化される10個の派生クラスを作成するのは間違っていると感じています。 MenuNodeすべてのノードに同じクラスを使用し、関数を解放するコールバックを通じて機能を実装します。私が読んだことから、そのかなり一般的なものは、自由な関数をオブジェクトと「結合」することです。しかし、それは物事を複雑にしてしまうような気がします。ReportButtonPress（）などのメンバーごとに、初期化中に実際の実装のコールバックを提供する必要があります。 ここで見落としているものがあると思います。

8 design  c++  c++11  embedded-systems 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 CおよびC ++アプリケーションに関する最新の傾向、および最新とは最新の年を意味するため、がstd::allocator実際よりも頻繁に使用されることを期待していました。 現代のアプリケーションは通常、マルチスレッド化されているか、それらの形式で並行性があり、特にゲームやマルチメディアアプリケーションなどの一部の分野では、大量のメモリを管理します。そのため、通常の高額な割り当て/割り当て解除のコストが上昇し、古いアプリケーションよりもパフォーマンスに影響を与えます。 しかし、std::allocators によるこの種のメモリ管理は一般的ではないため、私が知っている1つのライブラリを数えることすらできません。つまり、標準化されたメモリ管理方法に関する理論的根拠を使用しています。 std::allocator人気がないのには本当の理由がありますか？技術的な理由？

8 c++  memory  c++11  allocation